module: restore and warn on require('.') usage with NODE_PATH by silverwind · Pull Request #1363 · nodejs/node

silverwind · 2015-04-07T14:42:31Z

require('.'), like require('./') did not use module search paths, which inself is probably alright, as it is unexpected that . would refer to anything outside PWD.

It appears some users (#1356) were relying on unintended (and in my eyes bugged) behaviour when NODE_PATH contains a index.js, and surprisingly, require('.')did resolve to that module (which it probably never should have done).

This patch fixes the case of require('.') + NODE_PATH by letting require('.') look up the search paths. require('.') still works as expected when NODE_PATH doesn't contain a index.js.

If both NODE_PATH and PWD contain index.js, PWD is preferred (as it comes first in the array of search paths), which I think is the more sane way to fix that conflict, as it doesn't encourage relying on undefined behaviour.

rlidwka · 2015-04-07T14:48:34Z

Deprecation warning + note to remove this quirk in 2.0 maybe?

silverwind · 2015-04-07T14:52:20Z

@rlidwka you mean NODE_PATH deprecation? What are the alternatives (cc: @rvagg)?

rlidwka · 2015-04-07T15:04:15Z

I mean, if . points to something else than cwd, we could ask user not to do that.

Looking at the code, this suggestion might be too complex though. :(

silverwind · 2015-04-07T15:24:37Z

Looking into adding a warning.

Few more notes:

This also searches node_modules and other default paths on require('.'). Probably not intended, but that's how it worked before.
I would've liked to add a test, but as NODE_PATH is only read once during startup, I can't modify it during a test without restarting the process on each change.

silverwind · 2015-04-07T17:45:32Z

One more blocking issue I've noticed: path.resolve('.') does resolve differently when doing a process.chdir(). require shouldn't do that.

It seems the suitable __dirname isn't defined inside internal modules. Any suggestions on how to obtain the current script's directory (process.env.PWD, but cross-platform)?

rlidwka · 2015-04-07T18:07:56Z

Any suggestions on how to obtain the current script's directory (process.env.PWD, but cross-platform)?

Is process.cwd() available from there?

bnoordhuis · 2015-04-07T18:12:08Z

Note that process.cwd() can fail with ENOENT if the working directory has been unlinked.

silverwind · 2015-04-07T18:17:24Z

process.cwd() is unsuitable as it changes with process.chdir(). I need something static.

Edit: I think I have an idea how to solve it. Hold on.

silverwind · 2015-04-07T21:43:09Z

Updated with a better way of obtaining PWD, which is also resilient to process.cwd().

Not sure the fallback to path.resolve is really necessary, but there is this codepath, which can lead to parent = undefined, so I left it there.

Also added a warning if . did not resolve to PWD, but I'm not sure if that's the best case of action as we only have one other warning like this in the codebase.

silverwind · 2015-04-08T21:49:19Z

Will look into changing that console.error to util.deprecate.

silverwind · 2015-04-09T13:50:56Z

Any advice on how to use util.deprecate in this case? It seems util.deprecate is tuned for deprecating functions. In this case, I'd like to print a single warning if this condition is met.

just a thought, and perhaps this is too much of a hack but:
varnoopDeprecateRequireDotFile=util.deprecate(function(){},'message here')...if(request==='.'&&i>0)noopDeprecateRequireDotFile();

I'd be fine with something like that, but in the long term, we probably need something like util.warnOnce(msg). These probably shouldn't be public methods either.

silverwind · 2015-04-11T15:16:22Z

Updated warning with suggested usage of module.deprecate. I've tested enough to be sure this won't cause any regression. All it does is to allow '.' to resolve outside the module dir. It does so by putting the equivalent of __dirname in first position of the module search paths, so these look somthing like this:

['.',/* NODE_PATH entries */,'node_modules','.node_libraries']

If we hit a index in that array except the first, we warn once. Note that require('.') will prefer a module in __dirname over one in PATH. This is the only difference to the previous unintended workings of require('.').

Please review @iojs/collaborators

rvagg · 2015-04-15T05:50:52Z

the use of a template string seems unnecessary here

also, "did resolve" could be just "resolved"

rvagg · 2015-04-15T05:53:16Z

lgtm, perhaps could do with a test though? we may want to at least flag it in the tests as functionality that's being used in the wild--not having that covered is why we got into this position in the first place

silverwind · 2015-04-15T13:48:55Z

Agreed. I first thought doing a test wasn't easily possible because NODE_ENV was only read once at startup, but i've just discovered I can call module._initPaths(); to reinitialze paths.

silverwind · 2015-04-16T17:52:31Z

Nits fixed and test added, please have a final look.

Fishrock123 · 2015-04-16T19:39:18Z

will be deprecated soon.
sounds like it already is deprecated?

How about "will be removed soon" ?

"is deprecated" should be fine, or "is deprecated and will be removed"

silverwind · 2015-04-16T21:04:25Z

@Fishrock123 fixed the message. Adding semver-minor to satisfy semver deprecation requirements.

chrisdickinson · 2015-04-16T21:10:48Z

Feel free to merge this at will.

silverwind · 2015-04-16T21:28:30Z

@Fishrock123 LGTY?

Fishrock123 · 2015-04-16T21:39:10Z

yeah LGTM

This commit restores the functionality of adding a module's path to NODE_PATH and requiring it with require('.'). As NODE_PATH was never intended to be used as a pointer to a module directory (but instead, to a directory containing directories of modules), this feature is also being deprecated in turn, to be removed at a later point in time. PR-URL: #1363Fixes: #1356 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Rod Vagg <rod@vagg.org>

silverwind · 2015-04-16T23:14:14Z

Landed in #1363

I'll follow up with the removal commit for 2.0 shortly.

Notable Changes: * build: Support for building io.js as a static library (Marat Abdullin) #1341 * deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389 * npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448 * src: allow multiple arguments to be passed to process.nextTick (Trevor Norris) #1077 * module: interaction of require('.') with NODE_PATH has been restored and deprecated. This functionality will be removed at a later point. (Roman Reiss) #1363

Notable Changes: * build: Support for building io.js as a static library (Marat Abdullin) #1341 * deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389 * npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448 * src: allow multiple arguments to be passed to process.nextTick (Trevor Norris) #1077 * module: the interaction of require('.') with NODE_PATH has been restored and deprecated. This functionality will be removed at a later point. (Roman Reiss) #1363

Notable Changes: * build: revert vcbuild.bat changes * changes inherited from v1.8.0: * build: Support for building io.js as a static library (Marat Abdullin) #1341 * npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448 * deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389 * src: allow multiple arguments to be passed to process.nextTick (Trevor Norris) #1077 * module: the interaction of require('.') with NODE_PATH has been restored and deprecated. This functionality will be removed at a later point. (Roman Reiss) #1363

module: search NODE_PATH in require('.')
685d6e5

silverwind added the module Issues and PRs related to the module subsystem. label Apr 7, 2015

Better module dir detection, add warning
712e75c

silverwind force-pushed the require-dot-with-nodepath branch from 97b60c4 to 712e75cCompare April 7, 2015 21:33

silverwind mentioned this pull request Apr 8, 2015
io.js TC Meeting 2015-04-08 #1369
Closed

silverwind reviewed Apr 9, 2015
View reviewed changes

chrisdickinson mentioned this pull request Apr 9, 2015
Reversion Policy nodejs/dev-policy#48
Closed

silverwind changed the title ~~module: search NODE_PATH in require('.')~~module: restore and warn on require('.') usage with NODE_PATHApr 11, 2015

Warn once through util.deprecate, refactor
9a2e885

silverwind force-pushed the require-dot-with-nodepath branch from ef2f039 to 9a2e885Compare April 11, 2015 15:18

rvagg reviewed Apr 15, 2015
View reviewed changes

silverwind added 2 commits April 16, 2015 18:41

Move dot tests to own file
affc1f5

Fix test and nits
5e84210

Fishrock123 reviewed Apr 16, 2015
View reviewed changes

Fishrock123 added this to the 1.8.0 milestone Apr 16, 2015

Fix deprecation message
7a73480

silverwind added the semver-minor PRs that contain new features and should be released in the next minor version. label Apr 16, 2015

silverwind mentioned this pull request Apr 16, 2015
Release proposal: 1.8.0 #1436
Closed

silverwind closed this Apr 16, 2015

This was referenced Apr 17, 2015
module: remove require('.') with NODE_PATH compatibilty #1452
Closed
module: fix style #1453
Closed

silverwind mentioned this pull request Jul 7, 2015
Listing breaking changes experienced in io.js (help wanted) #2080
Closed

silverwind mentioned this pull request May 2, 2016
module: remove require('.') with NODE_PATH compat #3384
Closed

ChALkeR mentioned this pull request May 2, 2016
API stability level «Locked» is inaccurate #6528
Closed

ChALkeR mentioned this pull request Feb 8, 2017
Changing Definition of "Locked" for Stability Index in API Docs #11200
Closed

tniessen added the deprecations Issues and PRs related to deprecations. label Sep 7, 2018

Uh oh!

Uh oh!

Conversation

silverwind commented Apr 7, 2015

Uh oh!

rlidwka commented Apr 7, 2015

Uh oh!

silverwind commented Apr 7, 2015

Uh oh!

rlidwka commented Apr 7, 2015

Uh oh!

silverwind commented Apr 7, 2015

Uh oh!

silverwind commented Apr 7, 2015

Uh oh!

rlidwka commented Apr 7, 2015

Uh oh!

bnoordhuis commented Apr 7, 2015

Uh oh!

silverwind commented Apr 7, 2015

Uh oh!

silverwind commented Apr 7, 2015

Uh oh!

silverwind commented Apr 8, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

silverwind commented Apr 11, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rvagg commented Apr 15, 2015

Uh oh!

silverwind commented Apr 15, 2015

Uh oh!

silverwind commented Apr 16, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

silverwind commented Apr 16, 2015

Uh oh!

chrisdickinson commented Apr 16, 2015

Uh oh!

silverwind commented Apr 16, 2015

Uh oh!

Fishrock123 commented Apr 16, 2015

Uh oh!

silverwind commented Apr 16, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants