tsify
tsify copied to clipboard
TypeStrong
Browserify's paths option does not seem to work with tsify
Browserify have an option to specify which paths to look through when a file is "required" (browserify({paths: ["./source/App"]})), but that doesn't seem to work with tsify.
It is very helpful when you want to avoid relative paths hell, as you can setup the base of your app as one of the starting points.
The alternative of putting your code in the node_modules folder seems both odd (considering the normal seperation of app code and dependencies) and requires you to commit node_modules to your repository.
And symlinks doesn't work on windows.
Just a quick 2 cents on this since something similar is implemented in ts-loader. You can implement resolveModuleNames to achieve this functionality. This code (roughly) first tries to resolve using webpack's resolve logic and only uses TS's built-in logic if webpack's fails. The trick would be hooking into browserify's lookup logic which I know nothing about.
I'm new to browserify (coming from requireJS), so I don't really know how easy it would be either. But thanks for the input.
@jbrantly That's cool. I'm assuming that any code that you write using the Webpack resolve logic will look broken to Intellisense, though? Since I don't know how your tooling could know about the resolve logic being swapped out.
This will take some work (especially going down the rabbit hole of Browserify's resolve logic) but it should be doable.
I'm assuming that any code that you write using the Webpack resolve logic will look broken to Intellisense
Yup. That's the major downside :frowning: BUT I'm hoping when https://github.com/Microsoft/TypeScript/issues/5039 gets implemented things will get a little better on the IDE front because you can duplicate some of your custom path mapping between what webpack/browserify understands and what TS understands. The previous sentence is worded awfully but hopefully you get my point.
Dang, that is a crazy complicated proposal.
What's giving me pause for implementing this (along with other similar features) is that for every "this feature is in Browserify, why doesn't it work with tsify" type issue, I can imagine an equally compelling "this feature is in tsify, why doesn't it work with my tooling" issue. And that's not something that tsify can fix.
I dunno, I guess it's just that to me it feels more "TypeScripty" to use its module resolution semantics instead of Browserify's. Especially considering that Browserify actually supports swapping out the module resolution logic entirely (it uses browser-resolve by default, but you can write your own and pass it in as options.resolve.)
It seems to me that a better end state would be a zero-configuration setup in which Browserify used TypeScript's module resolution directly (this could be implemented pretty simply)... At that point, assuming that the linked proposal is implemented, then you would have all of the benefits of configuring your paths in tsconfig, and none of the drawbacks of having to maintain your path configuration in two different places and formats.
It seems to me that a better end state would be a zero-configuration setup in which Browserify used TypeScript's module resolution directly
Very interesting. I'll have to keep that in mind as well. You make some good points.
FYI Microsoft/TypeScript#5039 was merged into the 2.0 branch earlier this year. Is anyone using TypeScript@next with the module resolution?
I also like the "use TypeScript module resolution" option. If you consider tsify part of the TypeScript tooling it would make sense that you configure TypeScript once and all of the tooling automatically follows that. However, it may be hard to conceive how some users may be modifying their browserify config already.
@aciccarello I've tried using the TS 2.0 module resolution (baseUrl in tsconfig.json). It works great when using the standalone compiler, but tsify doesn't seem to support the new TS branch yet (I mentioned the error in issue #149).
I've come up with a temporary solution for gulp:
https://gist.github.com/azarus/f369ee2ab0283ba0793b0ccf0e9ec590
Browserify & Gulp samples included.
so tsify does currently not support the paths option in tsconfig.json?
@SteffenAnders Browserify's paths option is not something I've spent time investigating. In any case, I don't believe that it's up to tsify to support it. TypeScript and Browserify both perform their own module resolution. It's possible that you might be able to align Browserify's configuration with TypeScript's so that they resolve modules in a similar manner, but this is not something I've looked into. There are some more comments on module resolution and the apportioning of responsibilities in this issue #160.
@cartant thanks for your response.
i have fixed this by using pathmodify (https://www.npmjs.com/package/pathmodify)
tsconfig.json
...
"paths": {
"config/*": ["typescript/src/config/*"],
"delivery/*": ["typescript/src/delivery/*"],
"tracking/*": ["typescript/src/tracking/*"],
"utils/*": ["typescript/src/utils/*"]
}
...
gulpfile.js
...
browserify = require("browserify"),
pathmodify = require('pathmodify'),
tsify = require("tsify"),
tsconfig = require("./tsconfig.json"),
...
config: {
...
pathmodify: (() => {
let config = {mods: []}, from, to, i;
// use "compilerOptions.paths" option from tsconfig
for (from in tsconfig.compilerOptions.paths) {
for (i = 0; i < tsconfig.compilerOptions.paths[from].length; i++) {
to = tsconfig.compilerOptions.paths[from][i];
// remove trailing "/*"
config.mods.push(pathmodify.mod.dir(from.slice(0, -2), to.slice(0, -2)));
}
}
return config;
})(),
...
}
...
browserify(config.browserify.options)
.plugin(pathmodify, config.pathmodify)
.plugin(tsify)
...
Any progress on this?
I've had to write my own script that transforms my tsconfig paths for use with aliasify.
May be useful to others: https://gist.github.com/JakeSidSmith/6664afbc933e4c07e5c679658be671bf
I spent an entire day tracking this issue down. Inside the https://github.com/TypeStrong/tsify#does-this-work-with section there's needs to be a blurb about compilerOptions.paths stating that it is not supported and there's no plan to support it.
@SteffenAnders thank you, I was able to use your code as a plugin to get this to work.
