Repository navigation
Support for TypeScript 2.0 Module resolution #160
Description
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. 👍
Activity
cartant commentedon Jul 14, 2016
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 commentedon Jul 14, 2016
Indeed I think this might be out of scope for
tsifyas browserify is responsible for doing the module resolution. All we do is a.tsto.jstrasform.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.jsfor any.tsfile that browserify asks us to tranform. (This is purely based on my code review ... @smrq is the brains behind this 🌹 ❤️)loilo commentedon Jul 15, 2016
@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.
baseUrlis replicable by Browserify's very ownpathsoption. I was also trying to emulate TypeScriptspathsbehaviour viaaliasifybut 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 commentedon Jul 15, 2016
@loilo It's the paths that are written into the
requirecalls 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 commentedon Jul 15, 2016
@cartant That's exactly what I meant - the paths you write into the TS
importstatements 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 commentedon Jul 15, 2016
@loilo No worries. Thanks.
cape-dev commentedon Oct 13, 2016
Is there any progress on this topic? I would love a flexibility aliasify is giving you with
.jsfiles.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 commentedon Oct 13, 2016
@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 commentedon Feb 7, 2017
I won't get into whether or not it's
tsify's responsibility to fix this, but I got it to work by detectingrequirestatement whose path did not begin with.or/and prepending thebaseUrlto them. With regular expressions, it took two lines of code.