In a team set up, usually, I have faced merge conflicts in package-lock.json and my quick fix has always been to delete the file and regenerate it with npm install. I have not seriously thought about the implication of this fix because it has not caused any perceivable problem before.
Is there a problem with deleting the file and having npm recreate it that way instead of resolving the conflicts manually?
Yes, it can and will affect all the project in really bad way.
if your team does not run npm install after each git pull you all are using different dependencies' versions. So it ends with "but it works for me!!" and "I don't understand why my code does not work for you"
even if all the team runs npm install it still does not mean everything is ok. at some moment you may find your project acts differently. in a part that you have not been changing for years. and after (probably, quite painful) debugging you will find it's because of 3rd level dependency has updated for next major version and this led some breaking changes.
Conclusion: don't ever delete package-lock.json.
Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.
In your case you better do next way:
fix conflicts in package.json
run npm install
As easy as it looks. The same to yarn - it fixes lockfile conflict on its own. The only requirement here to resolve all the conflicts in package.json beforehand if any.
Per docs npm will fix merge conflicts in package-lock.json for you.
[Upd from 2021] important! If you use some library already and npm/GitHub account of its maintainer is hacked. And new version with malicious code inside is released. And you have package-lock.json intact. You will be fine. If you drop it you are in trouble.
Yes it can have bad side effects, maybe not very often but for example you can have in package.json "moduleX": "^1.0.0" and you used to have "moduleX": "1.0.0" in package-lock.json.
By deleting package-lock.json and running npm install you could be updating to version 1.0.999 of moduleX without knowing about it and maybe they have created a bug or done a backwards breaking change (not following semantic versioning).
Anyway there is already a standard solution for it.
Fix the conflict inside package.json
Run: npm install --package-lock-only
Check out this link for more info:
https://docs.npmjs.com/cli/v6/configuring-npm/package-locks#resolving-lockfile-conflicts
I know it's an old question but for future seekers, you can also use npm-merge-driver which try to automatically resolve the npm related files' merge issues.
Just install it globally npx npm-merge-driver install --global. You can read more about it here npm-merge-driver
Edit: Just want to warn people, who are interested in using above package, that sometime it can behave erratically and difficult to remove. So although it is a useful tool, it still need some work.
Edit: This repository is now archived and read only.
npm i --force does the work for me
Related
I've got a task that involves writing a code and I carried it out quite easily. I need to submit my solution to GitHub – according to the plan, I forked a certain repository and even cloned it to my hard drive using VS code. However, I was also told to install NPM dependencies to that newly created folder.
There are many manuals on Internet, but almost no one of them explains how to do it in a comprehensible way. As a beginner, I often struggle with all these new keywords, commands, etc and I would like to make things somewhat clearer. Do you have an idea how to get through it?
If you have already installed npm, in project directory use command
npm install
You can start with npm init in your folder. Then package.json file will be created. you can add dependencies you want to add, and run npm install.
In the node_modules folder there is a prettier install (package.json says "version": "1.19.1",) that is overriding the .prettierrc in my project root.
When I delete that dir, formatting returns to normal.
But this is only temporary as npm i puts it back. Something has it as a dependency, even tho searching for "prettier" or 1.19.1 only returns the package-lock.json.
I have other projects that work correctly without a node_modules installation of prettier, but this github template had it.
How can I clear this up? Ideally, I want to only use the project level .prettierrc.
You can find out which package is the culprit by searching in your package-lock.json. Each package in there has a requires field which lists its dependencies. That way you can traverse the chain to find out which dependency is causing the install.
Once you found the package, you have several options to force a specific dependency. In your case, you would force the latest version of prettier-plugin-svelte to be installed. In your case it's probably best to use npm shrinkwrap. You first add the latest version of prettier-plugin-svelte to your package.json, then do npm i, then make sure that only the latest prettier-plugin-svelte appears in your node_modules, then run npm shrinkwrap. More info here: https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/
More info and alternatives on forcing versions for various tools (npm/yarn) can be found in this StackOverflow answer: How do I override nested NPM dependency versions?
I have a large react app in production and I'm wondering if its best to use fixed versions for my packages? I've heard that using the caret (^) is a good practice, but that seems to me that it would leave the application open to more bugs?
I've googled this issue quite a bit, and there seems to be a split between ^ and fixed versions. Is there a definitive answer somewhere in the (npm) docs on what approach to use?
During development you can choose whichever you're comfortable with, but I would recommend shrinkwrapping just before you begin testing the app, before going into production. Lock down the dependencies with:
npm shrinkwrap
This command repurposes package-lock.json into a publishable npm-shrinkwrap.json or simply creates a new one. The file created and updated by this command will then take precedence over any other existing or future package-lock.json files. For a detailed explanation of the design and purpose of package locks in npm, see npm-package-locks.
That way you can leave the dependencies declared in package.json as they are (tilde/caret), but the exact versions declared in npm-shrinkwrap.json will only ever be used when npm installing.
I've personally had a problem just before going into production, when a dependency declared with ~ (the stricter one) was updated and introduced a bug (which shouldn't happen for a patch/bug fix). It's only ever happened once, but I would't want to tempt fate.
You can always update your npm-shrinkwrap.json by first doing npm update <package_name> specifying the package that needs updating, then re-doing npm shrinkwrap to update the existing npm-shrinkwrap.json.
...and don't forget npm ci
I tried to install the package. But I saw this error.How to solve this problem ?
It means that there are 23 packages in your package.json (or dependencies of packages in your package.json) that have reported vulnerabilities. If you own the code base you could try to update the dependencies to newer versions and hope that the authors have released new versions with the vulnerabilities fixed. If you don't own the code then you should contact the person who does.
It means that there are packages in package-lock.json that have publicly-disclosed vulnerabilities in them.
How to correctly handle this will depend a lot of things. Easiest is probably to run npm audit fix which will fix all the ones that it can without introducing incompatible changes (as determined by semantic versioning, so it's far from a guarantee). That will update your package-lock.json in the process.
If there are vulnerabilities that cannot be fixed without introducing an potentially-incompatible change (again, as determined by semantic versioning), then you will have to do more than npm audit fix. Fortunately, npm audit fix usually gives you instructions. One thing it can't do for you, though, is test and fix any issues that result from the incompatible upgrades.
After the recent addition of npm audit (for auditing dependencies) I noticed a huge discrepancy between how many packages are added (installed in node_modules) and how many are audited by npm. Here's an example:
Here are my questions:
Am I correct that 281 is the total number of packages installed?
Why is npm auditing so many more packages than the ones in my project?
It makes sense to me that npm might have to go back out and audit other package versions if it finds a vulnerability, but in this case it found 0 vulnerabilities so why the additional work?
UPDATE:
I think there's a little confusion about top-level vs sub dependencies. Run the following commands to reproduce a similar discrepancy:
mkdir test-npm-count-discrepancy
cd test-npm-count-discrepancy
npm init
npm i standard-version
Notice that (at the time of writing this) 200+ dependencies are added (i.e. standard-version and all its sub dependencies) but 1000+ packages are audited. Just to re-iterate, the main question from above is "why is npm auditing more packages than what's actually installed?".
For the first question:
- the community, without a link to something like a dependency list or your package.json, wouldn't really be able to say so. However, if in your package file only has a few, then it still is normal most of the time. You may have installed 12 yourself, but NPM auto-installs most, if not all, dependencies for your app's dependencies for you. It helps things speed up your workflow.
For the second question:
- as mentioned in my response to the first question, it is auditing both the ones you installed and the ones that were installed automatically so that the ones you installed work properly.
For the third question:
- It always checks for vulnerabilities marked by developers so you can have the latest version which is, most of the time, the least buggy, the most functional, and most secure.
Edit:
The whole point of npm install is to update current dependencies and install new ones to the directory. The point of npm audit is to check for dependencies that have updates marked to fix security issues.
Edit 2:
I think I've got it: it could be auditing the installed dependencies for production, your dependencies, and the dev-dependencies to warn you that one of your dependencies was built insecurely by the developer.