Skip to content
This repository has been archived by the owner. It is now read-only.

npm@5 known issue tracking #16991

zkat opened this issue Jun 5, 2017 · 50 comments

npm@5 known issue tracking #16991

zkat opened this issue Jun 5, 2017 · 50 comments


Copy link

@zkat zkat commented Jun 5, 2017

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.


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 (#16839)
  • "401 Unauthorized/403 Forbidden" for private registries: _auth and toplevel username/password auth not working (#16528)
  • Installing subdep as toplevel dep causes unmet deps (#16741)
  • Deps with strange/broken semver ranges not handled the way they used to be (#16744)
  • npm drops permissions to SUDO_UID for node_modules when installing as root (it should only do this for the cache) (#16766)
  • Mystery issue with postinstall scripts and missing directories (#16772)
  • npm not getting proxy settings from userconfig (#16783)
  • npm5 ignores os field when checking validity of install (#16810)
  • Cannot read property 'type' of undefined coming from shrinkwrap.js (#16812)
  • npm5 fails to install correctly on Docker (#16807)
  • Spurious extraneous packages after a successful install (#16820)
  • Local binaries fail to get linked sometimes (#16837)
  • strict-ssl and custom CA/cert stuff not working (#16868)
  • Manual edits to package.json ignored (#16878)
  • npm5 unable to install particular suspicious tarballs (#16882)
  • The way npm sets user permissions makes Docker unhappy when using userns-remap (#16892)
  • npm uses tarball permissions instead of forcing its own like it used to (#16896)
  • npm install sometimes fails to install some dependencies on a fresh install (#16902)
  • Other missing dependency corner cases (#16944)
  • Forwarded git deps not working (#16954)
  • npm i --production modifies package-lock.json (#16967)

Known Issues

  • Installing local directory packages that have an npm-shrinkwrap.json in them fails (#16601)
  • Error: Argument #2 ... but got null (#16665)
  • Unable to publish directly from tarballs (Cannot read property algorithm of undefined) (#16723)
  • Running npm install on a repo shrinkwrapped with npm@<5 yields different install (#16728)
  • Unable to uninstall global packages if installed with npm@<5 (#16738)
  • symlinked dependencies get their dependencies manipulated or blown away even when they're not in a subdirectory of the parent (#16788)
  • --save-dev is removing installed deps (#16794)
  • npm repo x fails if x is installed in the current dir (#16796)
  • npm crashes in confusing way if package name is an empty string
    or if there's no package.json (#16816)
  • Native build scripts running in the wrong order (#16824)
  • cb() never called on npm outdated (#16825)
  • npm reports error but fails to exit if requested version does not exist (#16827)
  • Spurious argument being added to some lifecycle scripts (#16831)
  • Attempting to upgrade npm5 yields EEXIST errors against previous npm source files, specially of npm was installed through something other than npm (#16833)
  • npm unlink edits package.json (#16838) (hint: npm unlink is just an alias for npm rm ;) )
  • npm outdated -g prints nothing (#16840)
  • npm install-test ignores package-lock=false config (#16843)
  • npm broken after upgrade (#16847)
  • Somehow, invalid integrity strings can make it into package-lock.json (#16861)
  • Spurious warning due to notice loglevel (#16862)
  • npm5 tries to install already-installed package that has private: true (#16883)
  • npm5 doesn't treat network timeouts the same (#16884)
  • globally installing packages without a name seems to make npm uninstall itself (lol) (#16891)
  • npm does not generate full lockfile unless a full install is run, first (#16893)
  • npm update does not install missing devDeps (#16901)
  • Some folks seeing cb() never called! issues for regular installs, not just global uninstalls (#16904)
  • npm exits before finishing output when run as a child process for some commands (#16932)
  • scope registry not working in some cases (probably when installing off tarball URIs) (#16933)
  • sha1 used on first install, then sha512 (#16938)
  • npm not checking permissions before upgrading itself (#16939)
  • npm install-test runs tests twice when package-lock=false (#16940)
  • npm gets hosed after upgrade (#16947)
  • project-local npm removes its own dependencies sometimes (#16949)
  • npm pretends to successfully remove non-existent global packages (#16956)
  • Maximum callstack exceeded is back and full of vengeance (#16968)
  • npm link is weird right now (#16970)
Copy link

@gigafied gigafied commented Jun 7, 2017

Copy link

@steebchen steebchen commented Jun 9, 2017

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..

Copy link
Contributor Author

@zkat zkat commented Jun 9, 2017

@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. 👍


Copy link

@mmc41 mmc41 commented Jun 10, 2017

@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.

Copy link

@Priyansh Priyansh commented Jun 12, 2017

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:

Copy link

@steebchen steebchen commented Jun 12, 2017

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

Copy link

@steebchen steebchen commented Jun 12, 2017

@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).

Copy link

@kachkaev kachkaev commented Jun 15, 2017

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

  - qa

  stage: qa
+  cache:
+    paths:
+      - node_modules
    - 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!

Copy link

@ljharb ljharb commented Jun 17, 2017

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

Copy link

@Alhadis Alhadis commented Jun 18, 2017

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.

Copy link

@yyjdelete yyjdelete commented Jun 19, 2017

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

Copy link

@ben-page ben-page commented Jun 19, 2017

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.

Copy link

@naholyr naholyr commented Jun 20, 2017

👍 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!

Copy link

@gaearon gaearon commented Jun 23, 2017

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 with "Latest Features":

screen shot 2017-06-23 at 5 23 16 pm

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.

Copy link

@brentvatne brentvatne commented Jun 24, 2017

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.

Copy link

@gaearon gaearon commented Jun 24, 2017

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.

Copy link
Contributor Author

@zkat zkat commented Jun 24, 2017

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!

Copy link

@NasCorp NasCorp commented Jul 25, 2017

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

Copy link

@jakeNiemiec jakeNiemiec commented Jul 25, 2017

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.

Copy link

@Alhadis Alhadis commented Jul 25, 2017

@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.

Irrelevant vegetable

Copy link

@NasCorp NasCorp commented Jul 25, 2017

@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. 🍆

Copy link

@ljharb ljharb commented Jul 25, 2017

@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.

Copy link

@jrop jrop commented Jul 25, 2017

@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.

Copy link

@jakeNiemiec jakeNiemiec commented Aug 10, 2017

@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 but may not support all of its latest features.

Copy link

@uniphil uniphil commented Aug 24, 2017

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


Copy link

@kanika46shah kanika46shah commented Aug 30, 2017

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

Copy link

@n3dst4 n3dst4 commented Sep 4, 2017

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.

Copy link

@Mardoxx Mardoxx commented Sep 4, 2017

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

Copy link

@iosdev-republicofapps iosdev-republicofapps commented Sep 7, 2017

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?

Copy link

@iosdev-republicofapps iosdev-republicofapps commented Sep 7, 2017

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.

Copy link

@mgol mgol commented Sep 7, 2017

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.

Copy link
Contributor Author

@zkat zkat commented Sep 10, 2017

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. :)

@zkat zkat closed this Sep 10, 2017
Copy link

@Mardoxx Mardoxx commented Sep 10, 2017

Copy link

@luislobo luislobo commented Sep 11, 2017

@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!

Copy link

@mmc41 mmc41 commented Sep 12, 2017

@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.

Copy link

@medikoo medikoo commented Sep 12, 2017

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

Copy link

@luislobo luislobo commented Sep 12, 2017

@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.

Copy link
Contributor Author

@zkat zkat commented Sep 13, 2017

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.

@npm npm locked and limited conversation to collaborators Sep 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.