My webpack project has a new error:
Browserslist: caniuse-lite is outdated. Please run next command npm update caniuse-lite browserslist
Which I haven't solved yet, but the underlying problem is: I don't have caniuse-lite in my package.json - so where is it?
btw: running that command makes no difference.
It's obviously a dependency or a dependency of a dependency, ad infinitum...
npmjs caniuse-lite lists 80 dependent packages.
Is there a way to search the dependency graph of packages to easily find what package in my package.json file is the parent that somewhere along the line depends on caniuse-lite?
You can easily check that by following way.
Checkout more here : https://docs.npmjs.com/cli/ls
npm ls contextify
app-name#0.0.1 /home/zorbash/some-project
└─┬ d3#3.3.6
└─┬ jsdom#0.5.7
└── contextify#0.1.15
Related
I am participating in building a webapp that used to use node-sass. We migrated to sass in the meantime but we have still node-sass in our package-lock.json. I want to fix that.
In the beginning, we had something like this
$ npm ls node-sass
cookbook#0.9.13 /home/private/Documents/Projekte/nextcloud-apps/nextcloud-app-dev/volumes/custom_apps/cookbook
├── node-sass#7.0.1
└─┬ sass-loader#13.0.2
└── node-sass#7.0.1 deduped
OK, lets remove the dependency by calling npm uninstall node-sass. The result is
$ npm ls node-sass
cookbook#0.9.13 /home/private/Documents/Projekte/nextcloud-apps/nextcloud-app-dev/volumes/custom_apps/cookbook
└─┬ sass-loader#13.0.2
└── node-sass#7.0.1
I do not get the reason, why sass-loader is still depending on node-sass. OK, let's have a closer look:
$ npm why node-sass
node-sass#7.0.1 optional peer
node_modules/node-sass
peerOptional node-sass#"^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" from sass-loader#13.0.2
node_modules/sass-loader
sass-loader#"^13.0.2" from the root project
peer sass-loader#"^13.0.1" from #nextcloud/webpack-vue-config#5.3.0
node_modules/#nextcloud/webpack-vue-config
dev #nextcloud/webpack-vue-config#"^5.0.0" from the root project
Now I am a bit surprised. The package node-sass is only installed as a peer dependency. So, why is it installed at all? I thought the idea of peer dependencies is to allow for the root project to select the version in use.
Also, it is only optional. So, it should be able to remove it (eventually there might be a warning during removal but nothing serious).
I am not working on the #nextcloud/webpack-vue-config package. It is a mere dev dependency of the webapp. So, NPM should not install the node-sass as a dev dependency on any of my dependencies.
How can I remove the node-sass package from my project's package-lock.json? It is still anchored in the package-lock.json and thus installed on each build.
I could use the --no-optional CLI option of npm to skip over all optional dependencies. I do not want to do that. The "problem" with this is that the GitHub dependency checker will not consider the node-sass module as skipped and continue complaining. Also, other optional dependencies might be skipped as well, although we would like to have them.
I ran into this with node-sass and sass-loader the other day.
Easy solve for me was to remove #nextcloud/webpack-vue-config from my package.json, do an npm install then put it back and rerun npm install
that was enough to get the internals reset to make node-sass go away.
For one of the globally installed npm packages I use, one of the dependencies received a minor version upgrade that unfortunately introduces breaking changes. In the below output, amplify-codegen version 2.28.1 was installed. When executing the command previously, amplify-codegen 2.28.0 would be installed.
npm i -g #aws-amplify/cli#6.4.0
npm list -g amplify-codegen
└─┬ #aws-amplify/cli#6.4.0
├── amplify-codegen#2.28.1
├─┬ amplify-provider-awscloudformation#4.65.0
│ └── amplify-codegen#2.28.1 deduped
Here the problem is that, despite the update from 2.28.0 to 2.28.1 being a minor version update, it introduces changes that break our project. So we would like to revert the update, and ensure that when installing #aws-amplify/cli#6.4.0, the 2.28.0 version of amplify-codegen is installed.
For a locally installed package, this could be easily resolved with a yarn.lock or the "overrides" option in the package.json. However, for globally installed packages, I'm struggling to find a solution, as there's no equivalent of a yarn.lock or package.json for globally installed npm packages.
I'm running into an issue with my npm mirror.
It appears to be lagging behind. Currently, my Jenkins build fails, because it does not see scheduler#^0.20.2, which was published about 20 hours ago.
Weirdly enough, npm ls scheduler returns empty, so I'm not sure what package is requesting it, but I need to, at least for now, somehow specify scheduler#^0.20.1 to be used in my project.
Is there a way to do this? I want to ensure that whichever package it is that depends on scheduler#^0.20.2 will have only scheduler#^0.20.1 available to it.
I just run
$ npm install scheduler#0.20.1
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN nm#1.0.0 No description
npm WARN nm#1.0.0 No repository field.
+ scheduler#0.20.1
added 4 packages from 3 contributors and audited 4 packages in 2.939s
found 0 vulnerabilities
then check
$ npm ls
nm#1.0.0 /home/daniil/
└─┬ scheduler#0.20.1
├─┬ loose-envify#1.4.0
│ └── js-tokens#4.0.0
└── object-assign#4.1.1
Editing package.json would probably have worked when you need force deep-lying module version:
{
"scripts": {
"preinstall": "npx npm-force-resolutions"
},
"resolutions": {
"scheduler": "^0.20.1"
},
}
I solved this way potential vulnerabilities in my repo
I wanted to try grunt-babel, so I opened up a terminal in my Home folder and did npm install --save-dev grunt-babel babel-preset-es2015 according to the plugin's instructions.
I was doing this too hastily, and realized I should probably have done this in my new project folder where I am dabbling with ES6 code. I had not even done npm init in that folder nor in the Home folder from where I executed the install command.
When I do npm uninstall grunt-babel, the preset files are removed but 91 folders of different dependencies remain in the node_modules folder.
Can I simply remove the folder instead of running npm uninstall 91 times?
This guy asked a similar question but none of the answers address his subquestion of just removing the folder: how to uninstall npm modules in node js?
npm uninstall <name> removes the module from node_modules, but not package.json.
npm uninstall <name> --save to also delete the dependency from package.json.
npm rm <package_name> removes the packages when uninstall not working
npm prune <name> (see docs) for extraneous packages and packages that are not listed on the parent package's dependencies list.
If you don't want to uninstall one by one run
rm -rf node_modules && npm cache clean && npm install
It's a good way for being sure the packages you uninstall are no more in the packages json.
Now in 2021 npm uninstall <name> will also removed it from package.json
UPDATED answer (2020):
These are all aliases to uninstall:
remove, rm, r, un, unlink
And today there is no need for --save flag since it is the default. The same goes for install BTW.
Use npm list as a tool to understand your changes. I usually use the time to make a capture file like:
npm list >1307
do some change
npm list >1309
so then:
cat 13??
or an editor lets me see what npm thinks it did.
For uninstall, only packages on the root all size of 'whole package' get removed. Other then that, the command is politely ignored...
For example:
├── safe-stable-stringify#1.1.0
├── semver#6.3.0
├─┬ tableify#1.1.0
│ └─┬ optimist#0.6.1
│ ├── minimist#0.0.8 deduped
│ └── wordwrap#0.0.3
safe-stable-stringify is a removal candidate, but wordwrap is not. Think about it, this is entirely reasonable !
npm uninstall pkgtoyank -save
updates packages.json by removing it from there as well.
npm is very well designed to say the least. I usually hugely avoid directly poking under it in ./node_modules I will copy things out from there to look at them, but why yank on a leash of a BIG CAT and get bit. it works; use it as its intended....
I have a problem with Yeoman generators. They install just fine if I run "npm install [generator-name] -g". However when I try to run "yo [generator-name] yeoman can't seem to find the generator. Neither is it listed among my other generators if I just run "yo". I've tried a bunch of generators and the result is always the same.
After a bit of bit of investigation I found that the downloaded generator is placed in
/usr/local/lib/node_modules/
But my other generators are placed in
/usr/local/lib/share/npm/lib/node_modules/
Here is an image of how it looks on my machine http://i.imgur.com/DxWTYHb.png, I'm running OSX in case that matters. Looks like something is wrong to me - but I cannot figure it out.
Not sure if this helps, but brew doctor and $NODE_PATH return nothing while $PATH returns:
-bash:
/usr/local/share/npm/bin:
/Users/marcus/.rvm/gems/ruby-2.0.0-p247/bin:
/Users/marcus/.rvm/gems/ruby-2.0.0-p247#global/bin:
/Users/marcus/.rvm/rubies/ruby-2.0.0-p247/bin:
/Users/marcus/.rvm/bin:
/usr/bin:
/bin:
/usr/sbin:
/sbin:
/usr/local/bin:
/usr/local/git/bin: No such file or directory
UPDATE
I tried what Eddie Monge Jr suggested and now my angular generator works fine. However when I installed another generator (chrome-extension) yeoman insists that it's not installed/found.
When I run ls $(npm config get prefix)/lib/node_modules I get this:
bower generator-mocha
generator-angular grunt-cli
generator-chrome-extension npm
generator-karma yo
And npm list -g returns this (I cut out a lot of generic stuff)
/usr/local/lib
├─┬ bower#1.2.3
├─┬ generator-angular#0.4.0
│ └─┬ yeoman-generator#0.13.3
├─┬ generator-chrome-extension#0.2.3
│ └─┬ yeoman-generator#0.12.3
├─┬ generator-karma#0.5.0
│ └─┬ yeoman-generator#0.13.3
├─┬ generator-mocha#0.1.1
│ └─┬ yeoman-generator#0.10.5
├─┬ grunt-cli#0.1.9
├─┬ npm#1.3.5
└─┬ yo#1.0.0
The strange part for me is if I run yo --help I get a strange list of generators
[?] What would you like to do?
[ ] Run the Angular generator
[ ] Run the Foundation generator
[ ] Run the H5bp generator
[X] Run the Mocha generator
[ ] Run the Webapp generator
[ ] Run the Karma generator
[ ] Update your generators
[ ] Install a generator
[ ] Find some help
[ ] Get me out of here!
I tried installing Yeoman on an Ubuntu precise32 vagrant vm. I ran into the same problem: Yeoman did not find the generators I installed, although there were no errors during the installation of these generators. Files were in place and permissions seemed alright.
The above solutions didn't work for me.
I ran
yo doctor
to see what was wrong, and as it turned out, the following was the problem:
[Yeoman Doctor] Uh oh, I found potential errors on your machine
---------------
[Error] NPM root value is not in your NODE_PATH
[info]
NODE_PATH = /usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
NPM root = /home/vagrant/npm/lib/node_modules
[Fix] Append the NPM root value to your NODE_PATH variable
Add this line to your .bashrc
export NODE_PATH=$NODE_PATH:/home/vagrant/npm/lib/node_modules
Or run this command
echo "export NODE_PATH=$NODE_PATH:/home/vagrant/npm/lib/node_modules" >> ~/.bashrc && source ~/.bashrc
The fix suggested by the Yeoman Doctor worked as advertised.
I hit this issue and I'm hoping it will help someone.
I believe upgrading NPM caused this initial issue for me.
/usr/local/lib/node_modules
Was the location of a lot of my modules in the past. Since upgrading node at some point, the directory became
/usr/local/share/npm/lib/node_modules
When I would run new installations such as:
npm install -g grunt-cli
I since I run grunt from the command line it wouldn't 'find' it (that's because it wasn't in my new node_modules dir). I set up this up in my .bash_profile:
export PATH=$PATH:/usr/local/share/npm/bin
Now I am pointing to the new node_modules directory
So all the new npm modules I install find the right location: /usr/local/share/npm/lib/node_modules
But not yo
I ran a which yo and my path was
/usr/local/bin/yo
This binary was pointing to the OLD node_modules installation #
/usr/local/lib/node_modules
My solution was to do this
rm /usr/local/bin/yo
npm remove -g yo
The old reference to yo is gone for keeps, now I can do
npm install -g yo
This will add it to the new node_modules location
/usr/local/share/npm/lib/node_modules
and now the new 'yo' references the proper node_modules installation base
source ~/.bash_profile
then we can see yo is referenced from the proper spot
which yo
/usr/local/share/npm/bin/yo
all future generators will be placed in the proper node_modules directory and yo will be able to find them without a problem!
I uninstalled yeoman entirely, then re-installed it
npm remove -g yo
npm install -g yo
This fixed my problem with missing angular generators.
Sounds like your npm may be out of whack. Check where things are installed:
npm config get prefix
Is that where you expected the packages to install? Is that where they are currently installed?
To list whats in there:
ls $(npm config get prefix)/lib/node_modules
That will list out the globally installed npm packages.
npm list -g
Will list the currently installed things. Make sure yo and the generators are listed at the top level.
To remove the yo stuff and start over:
npm remove -g yo generator-* yeoman-generator
npm install -g yo generator-angular
That should fix things.