-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: NODE_PATH support in module resolution #8760
Comments
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. |
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, |
Note that path mappings do not work equivalently to |
This would be super helpful. I'm working on a network drive and using an external node_modules folder for speed. Setting it with |
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? |
/remove "Awaiting More Feedback" |
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? |
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 This issue is currently the blocker for TypeScript to just work like Python does for local scripting |
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?
The text was updated successfully, but these errors were encountered: