Support TypeScript 3.8

[kitsonk]

The release candidate for TypeScript 3.8 is available. I have a branch updating to TypeScript 3.8. The biggest feature we care about is that private fields and TLA are supported. We were ignoring the TLA errors, and should take advantage of the private fields, as V8 already supports them and they are the best way to ensure private data stays private.

There is one major problem, prettier can't handle private fields at the moment under TypeScript. The tracking issue is prettier/prettier#7263. That means putting private fields in causes prettier to throw when using ./tools/format.py --js. So until prettier updates, it would be hard for us to update.

I also wonder if SWC/dprint handle them as well (cc/ @dsherret) for deno fmt.

[nayeemrmn]

dprint TypeScript 3.8 Support milestone: https://github.com/dsherret/dprint/milestone/1

[kitsonk]

I suspect it will take a little while for prettier to support ECMAScript Private Fields in TypeScript, mostly because there are a few upstream dependencies and it isn't just an upgrade for them. That means we might want to land adoption of that later and not concurrently with TS 3.8. The main reason to land TS 3.8 as early as feasible is proper support for TLA, including in bundles.

[dsherret]

dprint-plugin-typescript 0.6.0 is now released with support for all the new TS 3.8 features... markdown support should come within the next few weeks.

[kitsonk]

I've got a branch working, but there was a change in behaviour in TypeScript 3.8. Previously, source maps generated by TypeScript utilised the fileName from the SourceFile. Now they appear to use the filename provided by CompilerHost.resolveModules(). The problem was that when we created the source file, when building the internal bundles, we would replace the file:// specifier which specific to the system it was built on with $deno$ so that stack traces would provide an internal identifier when code occurred there.

I am going to have to move the logic we have from CompilerHost.getSourceFile() to CompilerHost.resolveModules(), but that is what is taking a bit longer than a straight forward upgrade.

[ry]

@kitsonk cool - if I can be of any help just point me at a branch.