npm@5 known issue tracking

[zkat]

I'm gonna use this issue as a central place for folks to find npm@5-specific issues/regressions. It'll also help the CLI team dedupe the various repeats we're getting so we can get a more realistic view of the state of things.

Fixed

NOTE: "Fixed" means a fix has landed in release-next and is available in the canary. It might not be in the latest released npm yet. You can install the canary with npm i -g npmc and use it with the separate npmc binary that gets installed. It won't affect your current npm installation.

• Missing dependencies after running npm install twice (Missing dependencies after running npm install a second time #16839)
• "401 Unauthorized/403 Forbidden" for private registries: _auth and toplevel username/password auth not working (npm5 Authentication Failure (E401) for 3rd Party Private Packages Registry #16528)
• Installing subdep as toplevel dep causes unmet deps (npm@5 installing a subdependency at root level causes unmet dependencies #16741)
• Deps with strange/broken semver ranges not handled the way they used to be (npm5 not installing a subdependency #16744)
• npm drops permissions to SUDO_UID for node_modules when installing as root (it should only do this for the cache) (npm gets permissions of node_modules all wrong #16766)
• Mystery issue with postinstall scripts and missing directories (Changes in npm5 break my optional dependencies workflow #16772)
• npm not getting proxy settings from userconfig (npm5 doesn't seem to use proxy and https-proxy in user .npmrc #16783)
• npm5 ignores os field when checking validity of install (npm@5 ignores "os": ["darwin"] on Windows #16810)
• Cannot read property 'type' of undefined coming from shrinkwrap.js (npm 5; "Cannot read property 'type' of undefined" #16812)
• npm5 fails to install correctly on Docker (Docker: Error: Cannot find module 'semver' #16807)
• Spurious extraneous packages after a successful install (npm5 extraneous packages reported #16820)
• Local binaries fail to get linked sometimes (npm@5.0.0 incorrect install issue #16837)
• strict-ssl and custom CA/cert stuff not working (npm@5.0.3: When proxied, strict-ssl=false or custom CAfile isn’t working #16868)
• Manual edits to package.json ignored (lock file doesn't seem to behave correctly with git-URL-based dependencies #16878)
• npm5 unable to install particular suspicious tarballs (npm@5 install error: ENOENT: no such file or directory #16882)
• The way npm sets user permissions makes Docker unhappy when using userns-remap (npm install fails in Docker container on system with Docker's userns-remap enabled #16892)
• npm uses tarball permissions instead of forcing its own like it used to (NPM5 Permissions Issue #16896)
• npm install sometimes fails to install some dependencies on a fresh install (npm i lost dependencies #16902)
• Other missing dependency corner cases (npm@5 - fresh install misses dependencies if private package AND preinstall script are used #16944)
• Forwarded git deps not working (npm 5 fails to install aframe; doesn't follow forwards #16954)
• npm i --production modifies package-lock.json (npm install --production modifies package-lock.json #16967)

Known Issues

• Installing local directory packages that have an npm-shrinkwrap.json in them fails (npm5 local install with shrinkwrap yields ENOENT -4058 #16601)
• Error: Argument #2 ... but got null (crash installing: "Error: Argument #2: Expected string or string but got null" #16665)
• Unable to publish directly from tarballs (Cannot read property algorithm of undefined) (npm5: Crash when publishing tarballs directly (formerly: Cannot read property 'algorithm' of undefined) #16723)
• Running npm install on a repo shrinkwrapped with npm@<5 yields different install (Successive npm installs resulting in slight differences in lockfile (npm@5) #16728)
• Unable to uninstall global packages if installed with npm@<5 (npm@5: Unable to uninstall global package after upgrading to npm 5 #16738)
• symlinked dependencies get their dependencies manipulated or blown away even when they're not in a subdirectory of the parent (npm 5 dedupes even in linked modules #16788)
• --save-dev is removing installed deps (npm install --save-dev is removing installed dependencies #16794)
• npm repo x fails if x is installed in the current dir (npm repo regression in npm@5 #16796)
• npm crashes in confusing way if package name is an empty string
  or if there's no package.json (npm5: npm install (with blank page name) crashes with Expected string but got null if blank package name #16816)
• Native build scripts running in the wrong order (npm 5 fails to install binary add-on that depends on another binary add-on #16824)
• cb() never called on npm outdated (npm5 npm outdated leads to crash with cb() never called #16825)
• npm reports error but fails to exit if requested version does not exist (npm 5 hangs if it encounters non existing version of a dependency in project.json #16827)
• Spurious argument being added to some lifecycle scripts (npm@5.0.0 adds npm_config_pack to the end of the script #16831)
• Attempting to upgrade npm5 yields EEXIST errors against previous npm source files, specially of npm was installed through something other than npm (Error upgrading from 5.0.0 to 5.0.1  #16833)
• npm unlink edits package.json (npm 5 unlink is editing package.json #16838) (hint: npm unlink is just an alias for npm rm ;) )
• npm outdated -g prints nothing (npm@5 outdated -g shows nothing #16840)
• npm install-test ignores package-lock=false config (npm 5: npm install-test ignores package-lock=false in npmrc #16843)
• npm broken after upgrade (Upgrade to NPM5 got error "Cannot find module 'delegates'" #16847)
• Somehow, invalid integrity strings can make it into package-lock.json (npm ERR! code EINTEGRITY (npm 5) #16861)
• Spurious warning due to notice loglevel (npm WARN : invalid config loglevel="notice" #16862)
• npm5 tries to install already-installed package that has private: true (npm 5 tries to install a private package that is already installed #16883)
• npm5 doesn't treat network timeouts the same (npm5 doesn't respect --fetch-retry-mintimeout and timeouts well before the expected timeout #16884)
• globally installing packages without a name seems to make npm uninstall itself (lol) (npm5 global install deletes itself in rare circumstance #16891)
• npm does not generate full lockfile unless a full install is run, first (npm5 save-dev doesn't install other dependencies or generate accurate lockfile #16893)
• npm update does not install missing devDeps (npm 5.0.0/5.0.1: npm update does not install missing dev dependencies #16901)
• Some folks seeing cb() never called! issues for regular installs, not just global uninstalls (cb() never called! #16904)
• npm exits before finishing output when run as a child process for some commands (Use of process.exit(...) in lib/utils/error-handler.js does not wait for STDIO to flush data #16932)
• scope registry not working in some cases (probably when installing off tarball URIs) (Cannot install package from scope registry #16933)
• sha1 used on first install, then sha512 (npm install produces different lockfiles on different computes #16938)
• npm not checking permissions before upgrading itself (NPM 5.0.0 to 5.0.2 update : npm command not found #16939)
• npm install-test runs tests twice when package-lock=false (npm v5: npm install-test runs test lifecycle twice when package-lock is false. #16940)
• npm gets hosed after upgrade (Error: Cannot find module 'core-util-is' in NPM 5.0.2 just after executing npm update #16947)
• project-local npm removes its own dependencies sometimes ([BUG] [v5] NPM uninstalls it's own dependency in local install. #16949)
• npm pretends to successfully remove non-existent global packages (Uninstalling a non-existant package does not result in failure #16956)
• Maximum callstack exceeded is back and full of vengeance (Unhandled rejection RangeError: Maximum call stack size exceededpreinstall: no script for preinstall #16968)
• npm link is weird right now ('npm link' unlinks after install of any package #16970)

[gigafied]

@zkat #16273

[steebchen]

Literally everyone I know who tried npm5 or uses node v8 had problems with the lockfile. On my CI environment one of my private modules won't be installed and on my staging servers gulp won't be installed –
when removing node_modules and npm installing locally (and reading from the lockfile), everything works fine. Same lockfile, same node version (8.0.0) and same npm version (5.0.3). This is really really frustrating, as npm5 ships with node v8. I really love npm and its ecosystem, but I never had more problems than right now.
I won't comment on the classic "Cannot find module 'semver'" issue or that I can't even develop with npm link anymore.
I think I have to manually install npm@4 on all my systems again..

[zkat]

@steebchen I don't know why it's broken on Docker. We're looking into it, but that's the main place where Cannot find module 'semver' seems to happen. I don't really know if that has anything to do with the package lock, but I doubt it.

npm5 was meant to be a big change. It rewrote a lot of core components of npm that were long overdue for a rewrite. This is what we needed to do in order to bring npm into the future, support the features people kept asking us about, and fix a bunch of old issues that required a rewrite in order to even fix.

And rewrites have a cost that we've always known about: instability. That's a reality of this sort of change, and the CLI team was very concerned about the effects it would have, specially on a tight enough timeline so we could land in node8 and people could take advantage of new features sooner. The conclusion was that a brief period of instability following release was an acceptable cost to pay for the huge benefits, both now and in the near future from features that are now possible. node8 has its own bugs, and it'll continue to stabilize.

I think it's generally good practice to stay away from bleeding edge releases if you can't handle breakage. This applies to all software, ever. The CLI team, all two of us, are working hard to get npm5 to a better place and there's already huge swaths of our userbase greatly benefitting from the tool right now. We're not gonna take that away. I recommend that if you find an issue and you can't work around it or you expect things to "just work" like they used to, you go ahead and revert to npm@4 until you have more confidence that npm5 will serve your needs smoothly. I don't think this is necessary for the majority of our users, but the userbase of npm is such that even a small % of users being affected by an issue turns into tens of thousands of people very quickly. That's just how that cookie crumbles.

Please do report stuff! We're working hard at this, and fixes go very quickly into our new canary. We've also got a faster release cadence. Note that a lot of the issues in the OP here have already been fixed, but I've been too busy triaging and fixing issues to comb through them and cross out the ones that already work. 👍

Cheers!

[mmc41]

@zkat Actually, "Cannot find module 'semver'" also happened for me after upgrading from npm 4 to 5 on Mac OS X (no Docker). Had to delete various npm folders to workaround it if I recall correctly.

[Priyansh]

Hello Folks,

I'm trying to install React Native through CLI command in Window OS, and I have npm version 5.0.3 and it is not supported yet for using React native. Any idea how to fix below bug : Is there any possible way to change npm version from 5 to 4 in order work on React Native?

Thanks in Advance

---

ERROR: npm 5 is not supported yet

---

It looks like you're using npm 5 which was recently released.

Create React Native App doesn't work with npm 5 yet, unfortunately. We
recommend using npm 4 or yarn until some bugs are resolved.

You can follow the known issues with npm 5 at:
#16991

---

[steebchen]

@Priyansh npm i npm@4 -g to use npm 4

[steebchen]

@mmc41 @zkat I don't use docker either so yeah it has nothing to do with that I suppose. I upgraded using Linux, got this error and I had to manually remove some folders too (not complaining, just providing information).

[kachkaev]

Also have an issue with npm5 inside GitLab CI. All works ok when there is no cache between the builds and so npm installs everything from scratch. When I enable cache like this:

# .gitlab-ci.yml
image: node:8

stages:
  - qa

qa:
  stage: qa
+  cache:
+    paths:
+      - node_modules
  script:
    - npm install
    - npm run test

here is what happens:

1. First build runs OK
2. Any consequent builds with exact the same package-lock.json also run OK and they are superquick (yay!)
3. Any minor change in package-lock.json creates this in the logs:

npm install

npm info lifecycle color-convert@1.9.0~preuninstall: color-convert@1.9.0
npm info lifecycle color-convert@1.9.0~uninstall: color-convert@1.9.0
npm info lifecycle color-convert@1.9.0~postuninstall: color-convert@1.9.0
# many more uninstall lifecycle events
# ...
# no re-install attempts for color-convert and other modules that were deleted
# despite still being in package-lock.json
# ...
removed 29 packages and updated 189 packages in 21.445s
npm info ok 

npm run test
# ...
Error: Cannot find module 'color-convert'
    at Function.Module._resolveFilename (module.js:485:15)

It feels like too many modules are uninstalled and not installed back again while npm tries to sync the contents of node_modules with the latest package-lock.json

Using node 8.1.0 / npm 5.0.3 (docker node:8). Hope this helps!

[ljharb]

Also #17269, which may be related to #16904.

[Alhadis]

support the features people kept asking us about

If perchance one of those features was a "leave my package.json file's damn indentation alone" request, well, congratulations! You're almost there. Seeing the file reformatted with tabs is a refreshing change, but I'd much prefer it not being reformatted at all.

It's pretty absurd for a package manager to be enforcing "consistent formatting" when we already have countless style-checkers, linters, and code reformatting tools whose sole purpose is handling this sort of ancillary taskwork.

Even ostensibly helpful stuff like this is making a blind assumption the user hasn't organised a keyword list by topic, or some other indiscernible/personal criteria running counter to alphabetical order.

[yyjdelete]

#17267 Another issue may lead to some Cannot find module issues.

[ben-page]

That list is massive. And I can't believe that some of this stuff wasn't caught by unit tests. Basic stuff like npm -g outdated and npm -g r package are not working. And the cannot find module issues make npm 5 unusable in many cases. These are not edge cases. Basic functionality is totally broken. Frankly, this would be a bad RC, let alone a stable release. I can't understand why was shipped with node 8.

Please, you should update npm 4 for node 8 and revert to bundling npm 4 for a while.

[naholyr]

👍 for not bundling a heavily bugged package manager in a LTS version of Node :/ This was a huge mistake for production users. But I think it's node-related more than npm-related, so → nodejs/node#13815

It would give more time to npm team to work around those issues painlessly. I hope such decision will be made for the sake of users, and for npm developers to decrease the pressure ;) Be sure we're grateful for all the work accomplished here!

[gaearon]

I think it's generally good practice to stay away from bleeding edge releases if you can't handle breakage.

As a tool maintainer, the problem for me is that npm@5 is what people get when they download "Current" release on https://nodejs.org with "Latest Features":

There is no wording there to suggest that Node 8 is unstable, or that it ships with a package manager that is bleeding edge.

I understand there are good reasons for shipping it, and that you can't influence Node.js website wording, but as a result beginners suffer.

For example, errors in facebook/create-react-app#2558 are inscrutable to anyone who doesn't have experience with debugging npm, but it happens today for every Windows user of webpack.

We could add a check in Create React App itself, and refuse to run on npm@5, but I'm worried this will be hostile. 😞

I'm curious what would be a better way to handle this in the transitionary period.

[brentvatne]

We could add a check in Create React App itself, and refuse to run on npm@5, but I'm worried this will seem hostile. 😞 I'm curious what would be a better way to handle this in the transitionary period.

I would also like some advice on this. Currently we actually have this check in Create React Native App because too many users were running into problems. It is very confusing for beginners to install the latest version of Node to try out a project, then learn that the default version of the package manager included with Node is not stable and be forced to downgrade.

[gaearon]

Anyway—I'm sorry for hijacking the thread. I now realize this issue might not be the best place to discuss this kind of meta concern. Let's keep this thread focused on known issues, and if there is interest, maybe we can discuss about the meta concern (what is best approach for tools relying on npm) in some other place.

[zkat]

I'm on vacation for a few more days (and have been for ~1.5 weeks) and Rebecca's been sick. We'll get back to y'all and I can only assume you'll see things getting fixed much faster once the whole team is back to full speed. Cheers!

[NasCorp]

Sorry, there is really 5 commits from 14'th of July. And no one of them is bugfix - only improvements.
🍆 👎

[jakeNiemiec]

Anyone fixing npm 5 problems? Do you want to make developers hate Node.js at all? 🍆 👎

@NickolasSh This is the price of open source. Being a project maintainer is a thankless job (thanks @zkat, @iarna & others 👍 ).

Check out the pulse page for a better idea of current activity.

[Alhadis]

@NickolasSh Quit whining, unless you're paying the developers to meet a certain deadline. We get that it's frustrating, but holy crap, you are seriously not gonna win friends or influence people by throwing shit at the developers as thanks for their continued hard work.

Keep it up guys, and ignore this whiny little shit. We know shit will get fixed eventually. =) 👍

EDIT: loooooool, NikolasSh 👍 d his own comments after they copped 5 👎 reactions.

[NasCorp]

@jakeNiemiec, thats what I found on npm page

npm, Inc. maintains the npm package manager for JavaScript and hosts the world’s largest software registry.

We offer very competitive salaries, meaningful equity, and generous health, dental, and vision benefits. We love it when you represent us at conferences.

As I understand @zkat and @iarna working in npm inc. and getting salary for maintaining npm.
And take a look at weekly activity 👎

@Alhadis, I just want to be sure that the developers understand the scale of the problem.
PS, Of course I 👍 d my own comments, and another plus I asked to put my friend. 🍆

[ljharb]

@NickolasSh there's plenty of work done in an engineering job that isn't "writing code", and not all of npm's code is public - but regardless, it's not for you to judge how well someone is earning their salary, since you're not their employer. Your comments and emoji choices are inappropriate, and the amazingly talented and hardworking npm developers don't deserve to be maligned just because things aren't proceeding the way you personally think they should be.

[jrop]

@zkat @iarna @ljharb there are tons of people who are benefiting from your work. Keep it up! You guys have your plates full and are doing an amazing job.

@NickolasSh dude you gotta chill! The beauty of open source is that anybody can contribute. However, right now all you are contributing is negative energy. Nobody likes a taskmaster.

[jakeNiemiec]

@BaktybekNurbakyt Don't expect any support:

The npm CLI project does not have designated LTS releases. The project only regularly does releases to the most recent major release.

These older versions of npm will continue to work with the registry.npmjs.org registry but may not support all of its latest features.

http://blog.npmjs.org/post/162451604515/the-npm-clis-long-term-support-lts-policy

[uniphil]

Looks like some more of these known issues have been fixed! 🎉 🚂

#16738
#16847
#16861
#16891

[kanika46shah]

Adding one more issue in the list of issued that need to be fixed #18352

[n3dst4]

Can I suggest that #18380 should also be added? That one's actually a regression in 5.4.0 as compared to 5.3.0 so not sure if it counts for this page.

[Mardoxx]

@NickolasSh bit unfair to say they don't contrib enough, one of them submitted a change that broke npm install in npm 5.4!

[iosdev-republicofapps]

npm@5 seems to totally break react native. Can't even use create-react-native-app. Yarn doesn't seem to work with nvm. I checked facebook/react-native#14767 but no help there ... Any ideas? :-) I'd be happy to help but I have no idea where to start. Could somebody give me a suggestion?

[iosdev-republicofapps]

I have react native running with npm 4.6.1, but as newcomer to both node and react native, it makes me a bit nervous to have to depend on a version of npm that's many versions behind the current stable version of npm. But it is working ... Let me know if I can help! :-) BTW, thanks for all you do making npm available for free - not meaning to be a whiner, just frustrated, that's all.

[mgol]

Yarn doesn't seem to work with nvm.

What do you mean? I'm using Yarn with nvm without problems, same for a few of my colleagues.

[zkat]

I'm gonna close this 'cause I really can't maintain this, which involves repeatedly going back and re-testing everything after every release. Managing incoming issues is hard enough as-is, and this was meant to be a temporary thing during the initial issue burst.

We're gonna keep working on fixing issues: if y'all feel like things have been slow, it's largely because it's conference season and the team's been getting dragged around to different engagements. Things should start chugging along soon again after that. :)

[Mardoxx]

Raises the question, why the hell push several releases (broken releases should I say) when no one is around to fix potential issues.... lol.

…

On 10 Sep 2017 2:38 pm, "Kat Marchán" ***@***.***> wrote: Closed #16991 <#16991>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16991 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOoMQHowR9OcWmwcaD03w5U3m9sPmEgks5sg-ZqgaJpZM4NwOpz> .

[luislobo]

@Mardoxx no one forces anyone to update. Eveyone has options: keep using the version that works for you, update to the latest and see if it works. Oh, and even fix the bugs you find!

[mmc41]

@luislobo Everyone has options ... but npm 5 comes along with the newest version of node when it is installed and beginners may not know how to update. I installed promptly downgraded when I found out the hard way that npm 5 was broken but I imagine that many newbies will give up or draw incorrect conclusions about the quality of the entire platform. So it is a bigger issue than just "shut up and fix the bugs" to the people that complain.

[medikoo]

True, biggest issue is that npm@5 was unfortunately bundled with node@8.

Still that's a bug on Node.js side. The good news is that lesson was learned, and it should not happen again. More care will be taken with next Node major releases. See: nodejs/node#13815

[luislobo]

@mmc41 I agree about it for new people. But, for experienced ones, I don't. It's pretty common having npm packages that does break stuff. That's one of the reasons why, in our production code, not a single package uses wildcards in version numbers. Been there too many times, with packages breaking a stable release, just because a new instance had to do npm install and a dependency dependency broke everything.
Anyway, I agree that things can be better tested. May be that can be improved. I just don't like coming here and blaming people, just like that, without taking action, and being at the same time rude or in a harsh language demanding it, just like if people owed any other the right to have stable and bugless code. This is Open Source. These things happen, the only way to fix it is get more people involved in coding, testing, etc.

[zkat]

I'm gonna lock this 'cause I keep getting pinged and I can't imagine this conversation going anywhere good the way it's happening.

Again: we're working on the fixes. I'm just not using this issue to track it anymore because it is not an effective medium for it. We're collecting blockers in other ways and prioritizing what we'll be fixing in the next couple of weeks/months according to that.

We're also working on new stuff, which is needed in order to help stabilize stuff -- npm is in a bit of an interim state while we move to this new model, and we're rewriting and refactoring a lot of its core. This will help us make npm more maintainable/testable/patchable, and ultimately more stable. But while all that stuff lands, we're going to have all this very fresh code, and we're going to be finding a lot of corner cases our very large community had grown used to -- and we'll have solutions for those.

My suggestion for folks is that if you can't upgrade: wait for it. npm@5 is a massive shift from older version and introduces a ton of new things and workflows. The CLI team decided to release npm5 when we did because it worked for us and for a number of people -- and the positive changes with npm5 are huge enough that there's a lot of people willing to use the bleeding edge and who have had a great experience with it. The work now is to extend those benefits to the rest of y'all <3.