There may be a problem with a package you are using, not npm itself. Sigh. Deep breath. Grunt. Okay - time to wipe the node_modules
and start again.
Reasons aside, for now, there are a few commands I seem to run almost daily to try to recover from errors. Kelly Vaughn got me thinking this morning about this.
if at first you don't succeed, try
— Kelly Vaughn 🐞 (@kvlly) April 22, 2019rm -rf node_modules && npm install
There are a few contributing factors to me running into issues with npm packages.
- I manage a lot of code, including some I touch infrequently enough where the packages get stale.
- I work in coffee shops and poor WiFi areas quite often (good WiFi one minute, poor the next)
- I have supported 1000+ developers using Node.js with npm
- Murphy's Law surrounds me
Maybe they don’t affect you - in which case - that’s great!
So what do I do when I see one of the issues with my npm packages? Especially the ones that claim there may be something wrong with one of the packages and not npm itself? I clear the node_modules
folder and try again.
rm -rf node_modules package-lock.json
npm install
And to do it with flair, I created a bash alias to run these commands.
npm-wipe
npm i
Why run it in two commands? Mostly because I like to see that the first one completed then go run npm install
manually. I have no good reason. You may prefer to run it all at once.
Bash Alias
Here is how I set up my bash alias on my macOS.
alias npm-wipe="rm -rf node_modules package-lock.json"
Hope this helps you out of a bind once in a while, too! Do you use this technique? If not, what do you do when npm errors bite you?
Top comments (25)
Would the
npm ci
command be of any help in this kind of scenarios? It wipes the modules folder before installation.I think
npm ci
is a great tool! Thanks for adding this thought!From what I read on the npm blog they said
This may be what you want, but sometimes the package lock is a problem too (in my experience).
So ... I think this can be a great solution, if that package lock is good to go. If not, then wipe
In my experience
npm ci
is very useful in very specific situations. Ironically, since you're blowing away the modules that were resolved you'll most likely end up with the same problem you had before if you try withnpm ci
since those modules are also resolved intopacakge-lock.json
.Those are great points. Thanks for adding
Why not switch your alias to include both commands
If the rm command returns an error it won't continue any commands after the &&
Thanks for the reply. As I said in the post above - I have no good reason other than i prefer to do it separately. That’s why I called that out - I 100% can see why some would rather do it in one command.
So - I guess I’m just odd. Lol.
oof, magic thinking and cargo cult dependency management. there's always a stack trace somewhere that will point out what went wrong, and it's helpful to at least look at that. you might still need a full reinstall to untangle the dependency tree, but at least you'll know what caused it in the first place.
and if it happens more than once or starts becoming a consistent problem, you know where to start digging.
I Have looked. often the error varies and even more often it’s due to missing files in multiple packages. I’ve found it more effective and efficient to wipe and install. Saves time and allows me to keep moving forward.
But of course your mileage may vary.
which sounds specific to your situation on a bad internet connection and not a great bit of advice to just push as a general solution. of your four points, i feel like only number 2 is a legit excuse to nuke
node_modules
so regularly.Yes, you are spot on that it is based on my experience. I've experienced this in support of 1000+ devs and I agree that's still a small sample size of the overall npm population.
+1 That's a good one to keep in the toolset!
On a slightly different use-case. One of my favorites is
npm prune
. Especially when working on large projects where you try a lot of different components.Sure by the time it's in the CI/CD pipeline it won't matter but it helps on my local machine -> remove the code bloat.
npm prune
is a great tool!thanks for sharing
Thanks for the tip. I'm new to npm and lean on nuking my node_modules whenever I find a problem. Adding an alias will certainly cut down on the amount of time I spend googling for the right commands to fix npm.
Glad to help - sometimes the best tips are the easiest and most useful ones :)
I found that deleting node_modules can be slow as hell, at least on Windows. So I usually first rename the directory, start deleting it in the background while simultaneously starting npm install.
I may be wrong - but is that because it’s moving to recycle bin? Could you do a permanent delete on windows still?
Nah, command line user here... Might be our corporate spyware though.🤔
This is exactly the reason why I switched to
yarn
I used yarn when npm didn't have package-lock by default. Now I don't see much difference between both package managers.
Yeah I thought so too, at first. Tried to switch back, but after a while I realise that npm still doing its thing. You steel need to
rm -rf node_modules
from time to time. I don't need to do this with yarn (only for exceptional cases), where is with npm I'm doing it like once a weekInteresting. I wonder if that’s happenstance or something deeper. I’ll poke around
why not try alternatives like pnpm?
I have been using it for a while (1yr aprox) it and I have been happy with it
It even makes you realize that libraries often use packages that are in the environment and don't even mark them as dependencies
pnpm.js.org/docs/en/faq.html#pnpm-...
Thanks John, this is one of those slap on the head moments when I say "why did I never think to create an alias for that"
But if you are in a poor wifi are, deleting your node_modules and installing them again wouldn't be counterproductive?
Usually the WiFi in these areas for me is good except short bursts of issues.
If they don’t work - they don’t work though :)