Suggestion: NODE_PATH support in module resolution

[cguinnup]

I'm working on a large project in which we'd like to use Typescript. We use disparate directories for our JS source, relying on our NODE_PATH environment var to pull them all together. However, Typescript does not use NODE_PATH in its module resolution.

I realize that our setup differs from the typical Node project, and may be considered an edge case. However, if I were to submit a pull request that added NODE_PATH support, would it be approved?

[mhegazy]

local node packages are preferred to global ones; moreover Node is moving away from this in their ES6 module implementation. so i doubt we will be supporting this.

My recommendation is to use path mapping (https://github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module%20Resolution.md#path-mapping) or npm link.

[cguinnup]

It may be prudent to avoid recommending npm link for now. I found it has a number of bugs that no one is working on: https://github.com/npm/npm/issues?q=is%3Aopen+milestone%3A%22understandable+links%22+no%3Aassignee

Hope 2.0 releases soon, that path mapping sounds like exactly what we need. :)

Though late to the party, fwiw I would like to add as follows just in case this issue/suggestion is revisited.

I started out with a foray[1] into TypeScript about 10 days or so ago (having a medium-sized code base with Babel infrastructure). The easiest route to get going with TypeScript was to hack things with 'declare var xxx: any' just to satisfy tsc in the interim, but, being a stickler for strictness, I wasn't too happy to go along with that tactic for too long.

So getting all the typings together and trying to factor out common typings between various projects I soon hit upon the module resolution issue for type definition modules in similar vein to pizza2code's disparate directories issue. In the heat of the moment I reached for the NODE_PATH spanner only to find out that it didn't work. Had it worked (and fortunately it didn't) chances are that I would have continued to use it and moved on.

In retrospect, I'm immensely pleased that NODE_PATH did not work as, aside from anything else, I feel that (shell) environment variables are on a lowly par with global variables in programs generally.

Now that 2.0 is more-or-less out, I hope that path mapping solves pizza2code's problem as well as mine. Sudden death is never too quick for global and environment variables alike.

RIP NODE_PATH.

[1] Meaning the 2nd definition of 'foray' in Merriam-Webster, http://www.merriam-webster.com/dictionary/foray,
that being "an attempt to do something especially for the first time". Definitely not meaning the 1st definition, "a sudden invasion or attack [into enemy territory]" ;-)

[OliverJAsh]

Note that path mappings do not work equivalently to NODE_PATH. NODE_PATH is used as a fallback after looking in node_modules, whereas path mappings are used before looking in node_modules.

[samuela]

This would be super helpful. I'm working on a network drive and using an external node_modules folder for speed. Setting it with NODE_PATH seems much cleaner and would probably be less buggy than using paths and typeRoots.

[brandonros]

Not that path mappings do not work equivalently to NODE_PATH. NODE_PATH is used as a fallback after looking in node_modules, whereas path mappings are used before looking in node_modules.

That sounds like a bug to me. That means projects that have a non-normal NODE_PATH currently aren't supported by the Typescript compiler?