I've been having issues linking scoped packages recently. I'm not sure if it was the upgrade to npm@3 or the other recent upgrade to msys2 (was using msysgit prior). I know msys2 / cygwin / etc. is unsupported but I'm stuck with it at work and seems like it could be a valid bug on other platforms unless I'm overlooking something.
Issue was it was throwing regarding Cannot read property '0' of undefined because lib/link.js was attempting to compare path.resolve(folder, '..') === npm.globalDir. Since its a scoped package I'm linking, it needed to traverse up two levels instead and was effectively comparing npm.globalDir + '@tixinc' === npm.globalDir.
Cannot read property '0' of undefined
path.resolve(folder, '..') === npm.globalDir
npm.globalDir + '@tixinc' === npm.globalDir
Here is pastebin of output from running npm link ../ext (where ext is private scoped module @tixinc/ext) - http://pastebin.com/raw.php?i=khHxFqzL
npm link ../ext
I was able to fix in this fork by adding a check to see if there is a private scoped module in the folder path, and if so, I run a second path.resolve to traverse up an extra level. Tested and working for me with a few different scoped package links. - master...cchamberlain:master
If this is msys2 specific I'm fine carrying on this fork since it's working for me, but if this can be of benefit I can squash the commits and cleanup the code for a pull request.
That's a 3.x bug for sure– I'll fix that for next weeks release! Thanks for catching this!
Awesome, I'm relieved it is not specific to my FrankensteinOS. =]
link: Fix linking of scoped modules
The fix for this landed in master with fdb360f and in 3.1.3.