npm global folder ~/.npm-packages triggers env.modulePath

[guybedford]

I'm not sure if this is a feature or a bug but it came up in jspm/jspm-cli#1338.

The issue is that when the global npm install folder is a local user path, this is setting env.modulePath, which is normally not set when running the global version.

Let me know if I'm missing something here but perhaps liftoff can determine if the module is resolving to one of the global folders in https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders and not set env.modulePath in these cases?

[phated]

I'm going to look to @tkellen on the "bug or feature" part.

If it's a bug we need to fix, maybe we can use https://www.npmjs.com/package/global-modules or https://www.npmjs.com/package/global-paths - @guybedford could you have the users running into this get the output from those modules so we can see if they report correctly?

[guybedford]

Good to hear from you @phated, and thanks for the quick response.

I was unable to replicate this again in my own tests, so please don't spend any time digging into this just yet - will report back with more info when we have looked into it again a bit further.

[tkellen]

If you can replicate this, it's definitely a bug. You might have an easier time isolating it with http://github.com/js-cli/js-hacker

[guybedford]

Thanks, I'm still struggling to get that replication from the original issue, but will keep you posted.

[guybedford]

I still haven't got a replication on this, but a user just posted they are getting this with a NODE_PATH of C:\Users<username>\AppData\Roaming\npm\node_modules.

[tkellen]

Thanks for the update @guybedford! unfortunately, I still need a viable reproduction of this to investigate :(

[staxmanade]

Hey All,

I think I'm getting this issue - as JSPM init wouldn't work for me... let me know if I can help to provide details to help diagnose.

I'm on Windows 10 - running inside PowerShell console.

node --version
v4.2.3

npm --version
2.14.7

the liftoff modulePath is set to C:\Users\jason\AppData\Roaming\npm\jspm.

As a local work-around I hacked JSPM with the following change to get it to resolve the global node_module/jspm folder.

   if (env.modulePath) {
+    if (/^win/.test(process.platform)) {
+      require(path.resolve(env.modulePath, '../node_modules/jspm/cli'));
+    } else {
-    require(path.resolve(env.modulePath, '../cli'));
+      require(path.resolve(env.modulePath, '../cli'));
+    }
   }

haha - I don't know why I did the /^win/.test since it's only my local windows version - guess I'm used to trying to hack cross-platform js.

[nlwillia]

Same issue as jspm-cli#1338 here... My NODE_PATH was set to C:\Users\<username>\AppData\Roaming\npm\node_modules (maybe from a previous install of Node? I just did a clean install to v5.6.0) and as a result liftoff was populating env.modulePath which caused jspm to conclude that the global version was local. Much head-scratching ensued as I unsuccessfully tried to follow the jspm getting started guide and understand how locking down a local version would make any difference since it already seemed to think it was local. Clearing NODE_PATH got me back on track, but I'd have had no clue to do that had I not dug into how jspm was initializing itself and found this issue. I don't know whose problem this ultimately is, but it would be nice if either the global location in my NODE_PATH had been recognized and ignored (for the purpose of identifying local vs. global) or if something would have recognized that the global location was incorrectly listed there and warned about it causing problems.