npm uninstall react-dates --save
still leaves a lot of traces in package-lock.json - airbnb-prop-types for e.g. How do I remove them? Additionally, if it is the case that it is some other package which uses them, how do I find out which one it is?
Related
I have an npm package resolve-url in my React Native project. The package is deprecated, and I'm not using it, so I want to remove it. However, after I run npm uninstall resolve-url to uninstall per npm's documentation, my project no longer runs with npm start!
How do I safely remove resolve-url?
How do I safely remove resolve-url?
It turns out that my project depended on resolve-url through another package, source-map-resolve.
Solution:
npm uninstall source-map-resolve
npm uninstall resolve-url
I deleted the newly created package-lock.json because my project used yarn.lock.
I cleaned up remaining references to source-map-resolve and resolve-url in my yarn.lock.
More info
When i install a package with npm install for my react-native project it automaticly removes another. How can I stop this from happening?
The problem is that you've added a git dep, possibly using a branch identifier like: git+https://..../you/your_project.git#your_branch but after resolution it's saved in package-lock.json not as #your_branch but as #sha_for_latest_commit_to_your_branch. When npm tries to resolve this difference it gets confused and removes what you've got currently.
You can get around the npm bug, while we wait for a fix to land, by copying that sha from package-lock.json into your package.json. You'll need to change the sha in package.json any time the dep gets more commit(s) pushed that you want in your project....
This would be annoying if you wanted it to automatically pick up changes to a frequently changing git dependency, but at least it would stop the uninstall behavior.. by Adam Tuttle ... cant see more in this link https://github.com/npm/npm/issues/17379
I'm having some issues uninstalling some of my global npm packages, in that they don't appear to be fully removing.
As an example, I've been trying to remove the beta Angular CLI package (as this package was renamed for its 1.0.0 release). Running npm uninstall -g angular-cli appears to work, however when I then run npm list -g --depth=0 the package appears to remain in the list, now with an error:
error: ENOENT: no such file or directory, open '/usr/local/lib/node_modules/angular-cli/package.json
It appears as though the package has not been fully removed - I'm not sure if this can be fixed using npm prune, or simply by going in and manually deleting any files that may be left over.
I've not had any success googling around the issue, however this could be because I'm not entirely sure what to search for, as evidenced by my not-so-eloquently worded title for this question.
If anyone has any thoughts, I'd be very grateful to hear them!
With the release of npm#5, it will now write a package-lock.json unless a npm-shrinkwrap.json already exists.
I installed npm#5 globally via:
npm install npm#5 -g
And now, if a npm-shrinkwrap.json is found during:
npm install
a warning will be printed:
npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion#1,
but npm-shrinkwrap.json was generated for lockfileVersion#0.
I'll try to do my best with it!
So my take-away is that I should replace the shrinkwrap with the package-lock.json.
Yet why is there a new format for it? What can the package-lock.json do that the npm-shrinkwrap.json cannot?
The files have exactly the same content, but there are a handful of differences in how npm handles them, most of which are noted on the docs pages for package-lock.json and npm-shrinkwrap.json:
package-lock.json is never published to npm, whereas npm-shrinkwrap is by default
package-lock.json files that are not in the top-level package are ignored, but shrinkwrap files belonging to dependencies are respected
npm-shrinkwrap.json is backwards-compatible with npm versions 2, 3, and 4, whereas package-lock.json is only recognized by npm 5+
You can convert an existing package-lock.json to an npm-shrinkwrap.json by running npm shrinkwrap.
Thus:
If you are not publishing your package to npm, the choice between these two files is of little consequence. You may wish to use package-lock.json because it is the default and its name is clearer to npm beginners; alternatively, you may wish to use npm-shrinkwrap.json for backwards compatibility with npm 2-4 if it is difficult for you to ensure everyone on your development team is on npm 5+. (Note that npm 5 was released on 25th May 2017; backwards compatibility will become less and less important the further we get from that date, as most people will eventually upgrade.)
If you are publishing your package to npm, you have a choice between:
using a package-lock.json to record exactly which versions of dependencies you installed, but allowing people installing your package to use any version of the dependencies that is compatible with the version ranges dictated by your package.json, or
using an npm-shrinkwrap.json to guarantee that everyone who installs your package gets exactly the same version of all dependencies
The official view described in the docs is that option 1 should be used for libraries (presumably in order to reduce the amount of package duplication caused when lots of a package's dependencies all depend on slightly different versions of the same secondary dependency), but that option 2 might be reasonable for executables that are going to be installed globally.
Explanation from NPM Developer:
The idea is definitely for package-lock.json to be the Latest and
Greatest in shrinkwrap technology, and npm-shrinkwrap.json to be
reserved for those precious few folks out there who care very much
about their libraries having an exact node_modules -- and for people
who want CI using npm#>=2 to install a particular tree without having
to bump its npm version.
The new lockfile ("package-lock.json") shares basically all of the
same code, the exact same format as npm-shrinkwrap (you can rename
them between one another!). It's also something the community seems to
understand: "it has a lockfile" seems to click so much faster with
people. Finally, having a new file meant that we could have relatively
low-risk backwards-compat with shrinkwrap without having to do weird
things like allow-publication mentioned in the parent post.
I think the idea was to have --save and shrinkwrap happen by default but avoid any potential issues with a shrinkwrap happening where it wasn't wanted. So, they just gave it a new file name to avoid any conflicts. Someone from npm explained it more thoroughly here:
https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/
The relevant quote:
npm publishes most files in your source directory by default, and
people have been publishing shrinkwraps for years. We didn't want to
break compatibility. With --save and shrinkwrap by default, there was
a great risk of it accidentally making it in and propagating through
the registry, and basically render our ability to update deps and
dedupe... null.
So we chose a new name. And we chose a new name kind of all of a
sudden. The new lockfile shares basically all of the same code, the
exact same format
package-lock.json versions are guaranteed with only npm ci (since npm install overwrites package-lock.json if there is a conflict with package.json).
npm-shrinkwrap.json versions are guaranteed with both npm ci and npm install.
In my Node.js project, I have a dependency on another local project. Oftentimes, I need to make a small change to the dependency and see how it affects my main project. In order to do this, I have to reinstall my dependency using npm.
I can use npm update to try to update my dependency, but this seems like it will only work if the version number has changed on the dependency. I don't want to have to change the version number on my dependency every time I change a line of code or two to make an experimental change in development.
I can rm -rf node_modules/; npm install to ensure that I get the latest versions of all of my dependencies. Downloading all of my non-local dependencies takes several minutes, breaking up my train of thought.
Is there a way to force npm to reinstall a single dependency, even if that dependency's version number hasn't changed?
When you run npm install, it will install any missing dependencies, so you can combine it with an uninstall like this:
npm uninstall some_module; npm install
With npm 5, uninstalled modules are removed from the package.json, so you should use:
npm uninstall some_module; npm install some_module
On npm v 6.14:
npm install module_name --force --no-save
You get a message stating:
npm WARN using --force I sure hope you know what you are doing.
And then it proceeds to uninstall and reinstall the package.
Note: if you don't specify the --no-save option, npm updates the package version on package.json to the highest version that is compatible with the existing SemVer rule.
If you do not want npm to update the package's version on package.json, keep the --no-save option.
Not the best answer, but just for information, you can run
npm ci
It is the same as npm install, but it will remove the existing node_modules folder, if any, and do a fresh install for all packages. This is useful if the files in node_modules have been changed for some reason and you want to revert them to their original state.