I added a couple of libraries to my package.json file, but now I found out I no longer need them
Is there some command line parameter to pass to npm install to tell it to remove no longer needed packages? that is, those packages in node_modules that are no longer in package.json
Or shall I just remove the node_modules folder and run npm install once again... (I was hoping for a smarter solution)
--
I found out that npm ls correctly recognizes no longer needed libraries as extraneous
You can do npm prune to remove extraneous packages. Link to docs.
Related
I am new to React js, While using npm start after install the react not working,I tried every process but no use. Thanks in advance
Error
cricdost#0.1.0 start C:\xampp\htdocs\cd-web
react-scripts start
There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.
The react-scripts package provided by Create React App requires a dependency:
"webpack": "4.41.2"
Don't try to install it manually: your package manager does it automatically.
However, a different version of webpack was detected higher up in the tree:
C:\xampp\htdocs\node_modules\webpack (version: 4.39.2)
Manually installing incompatible versions is known to cause hard-to-debug issues.
If you would prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.
To fix the dependency tree, try following the steps below in the exact order:
Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
Delete node_modules in your project folder.
Remove "webpack" from dependencies and/or devDependencies in the package.json file in your project folder.
Run npm install or yarn, depending on the package manager you use.
In most cases, this should be enough to fix the problem.
If this has not helped, there are a few other things you can try:
If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
This may help because npm has known issues with package hoisting which may get resolved in future versions.
Check if C:\xampp\htdocs\node_modules\webpack is outside your project directory.
For example, you might have accidentally installed something in your home folder.
Try running npm ls webpack in your project folder.
This will tell you which other package (apart from the expected react-scripts) installed webpack.
If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That would permanently disable this preflight check in case you want to proceed anyway.
P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! cricdost#0.1.0 start: react-scripts start
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the cricdost#0.1.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\XSC-10261\AppData\Roaming\npm-cache_logs\2020-02-20T04_56_31_650Z-debug.log
I had faced the same error. The solution that I found is to do the step-6 as described in Error message. That is to delete "webpack" folder of node_module folder under your root projects directory. For example
Assume that you installed "npm install create-react-app" in D:\Projects folder.
And then you ran "npx create-react-app firstproject" in D:\Projects folder. So, your actual react project folder is "D:\Projects\firstproject".
So, what I want to tell is don't delete "webpack" folder in "D:\Projects\firstproject\node_module" directory. Instead, delete "webpack" folder in "D:\Projects\node_module" directory.
And then, you can run "npm start" command in your actual react project directory "D:\Projects\firstproject".
I hope, this will work for you.
I've recently upgraded to node8 (using nvm) and a weird things started to happen in one of the project I'm working on.
Node v8.11.1
Npm 5.6.0
I cd inside my project having a packages.json.
For dev purposes I wanted to remove some packages previously installed but I didn't want to modify my packages.json.
Whenever I run either npm uninstall package-name or npm install packages-name they both try to install all the missing packages listed in packages.json!
I am explicitly NOT passing the --save or --save-dev flag but still npm ignores that.
I think it might have to do with package-lock.json file?
Q: How to tell npm I do not want it to mess up with other packages or modify my packages.json?
So I installed some modules with npm and others I just copied and pasted into the node_modules folder. One module I had to hack.
Now when I perform npm install for a new module, it deletes some of the modules and overwrites the hacked one to its original state.
It feels like I didn't run npm init early enough in development to properly set my package.json file from the start and now when I do run npm init it only picks up some of the modules.
How can I get everything synced up again? Is there a way to take a node_modules folder and get npm to become familiar with all the modules again? Also, is there any way to prevent the hacked one from going back to its original state?
Thank you!
Here's an answer to a similar question
You can fork the repo of the "hacked" module and include the forked repo in your package.json file. As for the "copied" modules, you can either copy them outside your node_modules folder and import using relative paths, or install it as a local npm package.
I have a NodeJS project that was started long ago. It has many packages that were installed before I understood the --save flag. A few versions ago npm decided that it would delete packages that are not mentioned in package.json (an insane thing to do). This causes a terrible problem.
Now I understand --save and use it properly. However, I cannot figure out a way to update package.json with packages that are not listed.
Is there some way to cause npm or some other program to look at a project and add missing dependencies? I'd be happy enough if it completely recreated the dependency structure.
Suggestions?
UPDATE : npm 3.5+
Remove everything from package.json and run: npm init --yes.
This will recreate the package.json with dependencies, but not the devdependencies.
npm 3
If your're on Unix based systems, from inside your project root folder, with a package.json file already created (npm init, as you mentioned), run:
npm install $(ls node_modules/) --save
and it will reinstall the packages, and save them into package.json as dependencies
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.