Integrate TypeScript 2.9+ into deno

[kitsonk]

This is a work in progress PR to integrate 2.9 and later into deno.

It is currently using a special build of TypeScript which incorporates microsoft/TypeScript#24641 (refs: #117 and microsoft/TypeScript#24638). This address an issue where since TypeScript 2.9 there are some changes to some of the compiler utilities which assumes that ts.sys is always defined, which it currently isn't when deno is the host.

TypeScript 2.9 introduces 3 new features which all have value to deno, IMO:

• Symbols and calculated property names are included in the keyof type operator.
• Support for import() of types.
• Support for and strong typing of importing JSON locally.

Currently, the following problems are occuring:

• At runtime, TypeScript via deno is complaining that it cannot resolve type modules via import():

  deno/testdata/014_import_types.ts:1:26 - error TS2307: Cannot find module './subdir/mod3'.
  
  1 function logThing(thing: import("./subdir/mod3").Thing) {
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  Though at development time, in vscode, I am not receiving this error, and other modules via the import keyword are fine.
• When importing of a JSON file, the following occurs:

  $ deno testdata/015_import_json.ts
  /main.js:15736
                  throw _iteratorError;
                  ^
  Error: Debug Failure. File /Users/kkelly/github/deno/testdata/subdir/hello_world.json has unknown extension.
      at Object.extensionFromPath (../node_modules/typescript/lib/typescript.js:4659:48)
      at ../node_modules/typescript/lib/typescript.js:78603:46
      at Array.map (<anonymous>)
      at resolveModuleNamesWorker (../node_modules/typescript/lib/typescript.js:78597:195)
      at resolveModuleNamesReusingOldState (../node_modules/typescript/lib/typescript.js:78783:24)
      at processImportedModules (../node_modules/typescript/lib/typescript.js:79982:35)
      at findSourceFile (../node_modules/typescript/lib/typescript.js:79873:17)
      at ../node_modules/typescript/lib/typescript.js:79743:85
      at getSourceFileFromReferenceWorker (../node_modules/typescript/lib/typescript.js:79710:34)
      at processSourceFile (../node_modules/typescript/lib/typescript.js:79743:13)
  

  Which I am not sure what the problem is, except that maybe that TypeScript has flipped into a browser mode at runtime instead of expecting some modules to be resolved by the host, and then runs into this issue of not directly supporting it. At design time, with a properly configured compiler flags (--resolveJsonModule and --esModuleInterop) tsservices does not report any errors and can resolve the module.

[kitsonk]

It appears I didn't understand module resolution in deno. It always expects fully qualified module names, including extensions. So updating the test case to import ./subdir/mod3.d.ts worked.

As a side note though, in IDE's powered by TypeScript services, TypeScript supports two forms of module resolution, in which both do not expect module IDs to include extensions, which means in IDEs, this always errors and you do not get the intellisense and type help from imports. I can understand the desire for safety by specifying the full file name, but I think it will be a challenge ongoing, unless the TypeScript team considers a new literal module resolution mode.

Still trying to figure out why the importing of JSON isn't working, but it seems to be the internals of TypeScript at the moment in thinking it is a source code module, but I need to understand how it dealing with resolving JSON files in the first place.

[kitsonk]

With resolving the loading of JSON files, the compiler host function of resolveModuleNames can return an array of either ResolvedModule or ResolvedModuleFull. The latter includes the extension and package ID. The ResolvedModule is there to maintain legacy support but it is recommended that ResolvedModuleFull be returned when possible.

When the support for loading JSON was added, it was assumed the host would identify it and the legacy code support for identifying these as JSON was not included. I currently have it at least loading the message, but need to deal with the compileAndRun which is just trying to directly run the JSON, versus parsing it.

[kitsonk]

I have added functionality now, that when the module ID ends in .json, that when trying to execute the module, it wraps it in an AMD define which exports the parsed JSON string as its default export. That means the following now can work under deno with TypeScript 2.9+ and operates in a type safe way:

import helloWorld from "./subdir/hello_world.json";

function logHelloWorld(item: typeof helloWorld) {
    console.log(helloWorld);
}

logHelloWorld(helloWorld);

[matiasinsaurralde]

esModuleInterop has been really helpful for some of my tests 👍

[kitsonk]

It will be at least 6 weeks until 3.0.0 and as Ryan has asked to keep the noise down a bit, which I respect, I will close this. When deno gets a little bit further down the line, this could be revisited, and the importing of JSON added. I would be glad to do the work once TS 3 is here and Ryan thinks it is the right thing to do. I won't delete my branch though if anyone is curious.