NODE_PATH deprecation (TC voted negative)

This came up a few times now, and has been suggested again in #1452 (comment)

What is the recommended alternative to NODE_PATH should we choose to remove it? There is probably a lot of misuse with NODE_PATH around, but is it really so bad that we want to drop it completely? How should we handle warnings?

It wasn't just suggested, it was decided, a few TC meetings ago.

Ack, I haven't been following that closely on this one. That leaves the question on alternatives open. Do we want users to only use local modules? Any other alternatives?

I think there are approximately 30 npm modules that duplicate this functionality. I see at least three at https://www.npmjs.com/search?q=require

And in general yes, you should be using either local modules or putting things in node_modules if you want to require them by name.

npm link is the appropriate replacement, although even that's suboptimal - basically just use local modules

Suppose we have a bunch of private modules all stored in one CVS repository.

With NODE_PATH the file structure looks like this:

application/
  bin/
    start.js
  node_modules/
    commander/
    express/
    /* other public modules */
  private_modules/
    CVS/
    companyname-mod/
    companyname-stuff/
    companyname-web/
    /* other private modules with prefix */

... and an application is started as NODE_PATH=./private_modules bin/start.js.

Now how is one supposed to run a project this way without using NODE_PATH?

Making symlinks from private_modules/* to node_modules/* isn't a good idea because somebody could add a new module to the repo, and it should be discovered automatically on cvs up.

Funny structures like putting everything to node_modules folder to abuse node.js module lookup system doesn't work well either.

NODE_PATH is the right tool for the job here, and I'm sure it has other uses as well.

I've changed my mind about NODE_PATH. It's been semi-deprecated for ages but we have been stupid enough to leave it in the documentation without so much as a deprecation notice.

As a result, it's in active use and people do useful things with it. See for example this recent reddit topic about scripting.

Breaking such use cases is not nice. I think NODE_PATH must stay.

As a result, it's in active use and people do useful things with it. See for example this recent reddit topic about scripting.

I'm loathe to admit it, but yeah, I think it's going to be around for a long time to come, especially given the google search results for the term.

I'd rather just remove the "require('.') with NODE_PATH" hack (#1452) and be done with it for the mean time.

Another use case: Docker dev environment.

Docker is not native for OS X/Windows, so, if you map your dev machine path to VM, node_modules will contain os-dependent files (Linux). In this case should be a way to store node modules somewhere else.
If I want to build my project using gulp, I want to provide simple docker command to build from scratch (without installed node, npm and so on). In this case my docker image can contain pre-installed node_modules and, so, should be a way to specify custom path.
For example, to install bower deps, I don't have to install bower/node/npm, I can just use docker run --rm -v $PWD/path/to/dir:/data develar/nodejs-bower. I am going to use NODE_PATH to store node_modules inside docker image instead of doing "npm install" runtime.

Maybe we should bring this up again at a tc meeting and reconsider our previous sentiments?

Yeah, please discuss it so we know how to process come 3.0.

for the record I'm not proposing deprecation of NODE_PATH and never have, I don't use it but it also doesn't get in the way and I recognise some people have novel uses for it, see last TC meeting for details of discussion about this

@rvagg

@rvagg I'm just responding to your RFC upthread, not making any assumptions about your own position on the change. ;)

I am -1 on removing NODE_PATH support. It's not hurting anyone, and it's a perfectly reasonable way to get certain things done. Ok, so it's maybe not the most elegant way possible, and it's abused. Who cares? People also do crazy stuff with throw and RegExps and global variables.

The point of Node is not to create the most elegant system possible. The point of Node is to make it easy for people to write software. Any changes that can only make it harder while providing no tangible benefits to people writing software are bad changes.

Compare this to require.paths, which did cause demonstrable harm when used, because it involved a very spooky action at a distance. Also, require.paths was removed several years ago, when we had less than 1/10 the userbase we do now.

This is JavaScript, not Haskell. Either purity serves the goal of creating software, or we throw purity overboard.

@isaacs

@isaacs, @othiym23, etc. please note this issue is now inappropriately named. The TC explicitly disagreed with deprecation and this is now simply a call to adjust documentation to discourage its usage rather than suggest it's an idiomatic way to use Node.

If you disagree with even changing documentation then please let us know.

I guess it may also be worthwhile discussing how this may eventually play out regarding es6 modules. (if we want differences. More of an NG topic though.)

@rvagg

@rvagg My comments on the documentation changes suggested by @smikes are enough, I think. I'm good otherwise.

@Fishrock123

@Fishrock123

I guess it may also be worthwhile discussing how this may eventually play out regarding es6 modules.

It's premature to do that, in the absence of a viable loader spec or even a candidate implementation of the static syntax in V8. It's also more or less completely unrelated to this issue.

@rvagg

@rvagg I'm super ok with updating the docs to discourage use of globals and environment variables, sure.

I made a rather forceful case for not deprecating NODE_PATH because I think this is a point of priorities and leadership that is important to make very clear. We should not be afraid to change stuff if it's a demonstrable improvement, but we should also not change stuff just to change stuff.

New version incorporating feedback:

NODE_PATH was originally created to support loading modules from varying paths before the current
module resolution algorithm was frozen.

NODE_PATH is still supported, but is less necessary now that the node ecosystem has settled on a convention for locating dependent modules. Sometimes deployments that rely on NODE_PATH show surprising behavior when people are unaware that NODE_PATH must be set. Sometimes a module's dependencies change, causing a different version (or even a different module) to be loaded as the NODE_PATH is searched.

@smikes

@smikes 👍

@smikes

@smikes That looks great

@smikes

@smikes 👍

Closing since we aren't deprecating.

Navigation Menu

Repository navigation

NODE_PATH deprecation (TC voted negative) #1627

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

NODE_PATH deprecation (TC voted negative) #1627

Description

Activity

domenic commented on May 5, 2015

silverwind commented on May 5, 2015

domenic commented on May 5, 2015

domenic commented on May 5, 2015

rvagg commented on May 5, 2015

rlidwka commented on May 7, 2015

bnoordhuis commented on May 7, 2015

chrisdickinson commented on May 7, 2015

Fishrock123 commented on May 12, 2015

develar commented on May 13, 2015

Fishrock123 commented on May 13, 2015

silverwind commented on May 13, 2015

6 remaining items

rvagg commented on May 14, 2015

othiym23 commented on May 14, 2015

isaacs commented on May 14, 2015

rvagg commented on May 14, 2015

Fishrock123 commented on May 14, 2015

othiym23 commented on May 14, 2015

othiym23 commented on May 14, 2015

isaacs commented on May 14, 2015

smikes commented on May 14, 2015

othiym23 commented on May 14, 2015

iarna commented on May 15, 2015

isaacs commented on May 15, 2015

Fishrock123 commented on May 15, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions