relative module paths resolve differently in REPL.

Version: v5.5.0
Platform: Darwin jdalton.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

npm init
# <init a package>
npm i lodash --save
touch lodash.js

In lodash.js

module.exports = {
  'VERSION': 'should be me'
};

Now in the REPL

console.log(require('./lodash').VERSION);
// => 4.6.1 instead of 'should be me'

Put the same code in a file

touch foo.js

In foo.js

console.log(require('./lodash').VERSION);

Then

node foo
# logs 'should be me'

It would work in the REPL if I changed the path from './lodash' to './lodash.js'.

@jdalton

@jdalton thanks for the report!

Operating system?

Locally - On 5.1.0 I see:

$ node
> require("./lodash.js").VERSION
'should be me'

Updating to 5.8 I get:

$ node
> require("./lodash.js").VERSION
'should be me'

So assuming it didn't break between 5.1 and 5.8 I suspect it might be OS related.

@benjamingr

@benjamingr

Operating system?

OSX 10.11.3

So assuming it didn't break between 5.1 and 5.8 I suspect it might be OS related.

The issue is require('./lodash') didn't work. You're doing require('./lodash.js').

Oh sorry, my bad. I see 4.6.1 and not 'should be me' too for that on windows.

Cool, so it repros on Windows and OSX.

require("module")._resolveFilename("./lodash") // returns the value in node_modules

Since _resolveLookupPaths returns:

[ './lodash',
  [ 'C:\\issue-5684\\node_modules',
    'C:\\node_modules',
    '.',
    'C:\\Users\\Benjamin\\.node_modules',
    'C:\\Users\\Benjamin\\.node_libraries',
    'C:\\Program Files (x86)\\lib\\node' ] ]

Which finds lodash if I do:

var paths = require("module")._resolveLookupPaths("./lodash")
require("module")._findPath("./lodash", paths[1]) // C:\\issue-5684\\node_modules\\lodash\\lodash.js

Which happens because of "hacky" code (terminology used) in repl.js. I have to leave now, but I'm at

node/lib/module.js

Lines 263 to 264 in 7c60328

    
           var mainPaths = ['.'].concat(modulePaths); 
        
           mainPaths = Module._nodeModulePaths('.').concat(mainPaths);

and I think the node_modules paths should be placed below the . and not above.

I'll keep debugging later - anyone feel free to pick this up.

to place the node_modules paths below the . and not above, the part of the _resolveLookupPaths should be like the following?

- var mainPaths = ['.'].concat(modulePaths);
- mainPaths = Module._nodeModulePaths('.').concat(mainPaths);
+ var mainPaths = Module._nodeModulePaths('.').concat(mainPaths);
+ mainPaths = ['.'].concat(modulePaths);

I think I have a working test... going to see if this fix makes things work

@thealphanerd

@thealphanerd anything near what I've done in #5689?

@phillipj

@phillipj the test is different. There is already a test-repl-require so I just bootstrapped on that.

Your test might be good to have as well, but the one I used is running in the repl itself. I'm going to push it to a fork, might make sense for you to cherry pick and add to your PR... I'll post it in there

module: prioritize current dir for local lookups

Navigation Menu

Repository navigation

relative module paths resolve differently in REPL. #5684

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	var mainPaths = ['.'].concat(modulePaths);
	mainPaths = Module._nodeModulePaths('.').concat(mainPaths);

relative module paths resolve differently in REPL. #5684

Description

Activity

benjamingr commented on Mar 13, 2016

jdalton commented on Mar 13, 2016

benjamingr commented on Mar 13, 2016

jdalton commented on Mar 13, 2016

benjamingr commented on Mar 13, 2016

watilde commented on Mar 13, 2016

MylesBorins commented on Mar 13, 2016

phillipj commented on Mar 13, 2016

MylesBorins commented on Mar 13, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions