search

microsoft / TypeScript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
https://www.typescriptlang.org
Apache License 2.0
100.63k stars 12.44k forks source link

Suggestion: NODE_PATH support in module resolution #8760

Open cguinnup opened 8 years ago

cguinnup commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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. :)

ghost commented 8 years ago

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 commented 7 years ago

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 commented 5 years ago

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 commented 4 years ago

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?

arash-bizcover commented 3 years ago

/remove "Awaiting More Feedback" /enough "Awaiting More Feedback"

singpolyma commented 2 years ago

Path mapping cannot be used when specifying source files at the command line, only when using "project mode" with tsc. Is there any way to emulate this behaviour for all tsc invocations?

kangalio commented 1 week ago

I'm trying to move from Python to TypeScript for local scripting. In Python, I could just install my arsenal of packages I always need globally, and importing them in the REPL or in scripts python myScript.py just works.

This issue is currently the blocker for TypeScript to just work like Python does for local scripting