Support for TypeScript 2.0 Module resolution

[loilo]

As you certainly know one of the big improvements with TypeScript 2.0 is the ability for developers to define their own path mappings and determine the path(s) where there modules are located. (More information here: What's new in TypeScript, the detailed proposal on GitHub).

The whole thing is done via the introduction of compilerOptions entries baseUrl, paths, and rootDirs. TypeScript 2.0 recognizes and handles them correctly but sadly (or rather by design) those paths are not rewritten to relative ones so tsify can't handle them at the moment.

It would be amazing to have those options taken into account for bundling. 👍

[cartant]

I am currently trying to find and fix whatever it is with the TypeScript 2.0.0 beta that breaks my tsify-based builds. Once I've done that, I can have a look to see what the JS output looks like when the new module resolution options are used, as that's all Browserify will care about.

[basarat]

Indeed I think this might be out of scope for tsify as browserify is responsible for doing the module resolution. All we do is a .ts to .js trasform.

Architecture notes:

We register ourselves a plugin. On load we resolve to some tsconfig.json and create a typescript Program. We keep this program in memory and use it to emit .js for any .ts file that browserify asks us to tranform. (This is purely based on my code review ... @smrq is the brains behind this 🌹 ❤️)

[loilo]

@cartant The output of TS 2.0 stays exactly the same as if those options weren't there. Those new options from tsconfig.json are really only ever evaluated by the TS compiler itself for TS-related but they do not affect the compiled output. That's the problem here.

@basarat Okay, that's a fair amount of really valuable information. ❤️
I'm afraid this actually is out of scope of tsify. Nevertheless it will probably break Browserify builds for people coming freshly to TS + tsify in the future so there should at least be a hint on that issue for them.

Yesterday I fiddled around a bit and was able to reproduce parts of this new specification outside of tsify. baseUrl is replicable by Browserify's very own paths option. I was also trying to emulate TypeScripts paths behaviour via aliasify but my first attempts failed, I may have to put some more time into it.

In case anything comes around and I'd be able to fully reproduce what the TypeScript 2.0 spec says I will post an update here.

[cartant]

@loilo It's the paths that are written into the require calls in the JS files that'd I'd be interested in. I will have a closer look at it when I'm finished getting the new beta to work for my builds. I'm spending a little bit of time on it each day. Whilst doing this, I'm compiling some notes on how things hang together within the plugin's implementation.

@basarat I'll submit a PR with some architectural notes - and some optimization strategies for avoiding repeated TypeScript compilations - when I'm done. I guess I'll add them to the CONTRIBUTING.md document.

[loilo]

@cartant That's exactly what I meant - the paths you write into the TS import statements are not touched no matter what the configurations say. (And that's, as I mentioned, by design.) Only TypeScript's features like type/error checking are affected but not the compilation result.

But you will see that on your own when it comes to that. 👍

[cartant]

@loilo No worries. Thanks.

[cape-dev]

Is there any progress on this topic? I would love a flexibility aliasify is giving you with .js files.

If not, I am planning to write a tool which might replace aliasify. My goal is to create a tool which is able to dynamically replace certain aliases in string arguments of configurable function calls (e.g. require, import, proxyquire, etc.) by traversing the ast's of the code files. The tool should not be coupled strictly with .ts files, but rather should be also extendable for CoffeeScript files or else.

EDIT: As I just read, it is not possible to modify the AST with the current public API (TS Issue #7580)

[cartant]

@kamekazemaster There isn't going to be anything code-related done with this issue, as the module resolution is up to browserify. It'll be necessary to have some browserify configuration that performs the same resolution that TypeScript uses.

I was planning - when I get the time - to have a look at this and include an example of such a configuration in the README. Last time I needed to do path-related stuff with browserfiy, I used pathmodify, so that would be the way I'd approach this issue - but I've not made it a priority.

[dawsonc623]

I won't get into whether or not it's tsify's responsibility to fix this, but I got it to work by detecting require statement whose path did not begin with . or / and prepending the baseUrl to them. With regular expressions, it took two lines of code.