Is there any harm in using NPM and Yarn in the same project?
YarnpkgYarnpkg Problem Overview
I have been using npm for a personal project and just recently stumbled across yarn. Would there be any harm or "intended side effects" to switching to yarn's package manager in the same project where I had been using npm?
Yarnpkg Solutions
Solution 1 - Yarnpkg
Although a few commenters here say its ok to mix both yarn and npm on the same project, after using yarn and npm and then yarn again, this is what yarn has to say about it:
warning package-lock.json found. Your project contains lock files generated by tools
other than Yarn. It is advised not to mix package managers in order to avoid resolution
inconsistencies caused by unsynchronized lock files. To clear this warning, remove
package-lock.json.
Solution 2 - Yarnpkg
Since to me it is not any harm to using both them into one project.
I use npm and yarn (50/50) in dev environment. But on ci/di i use only yarn because it is faster, and i reduce build minutes thanks yarn.
Also they both create different .lock file names.
Solution 3 - Yarnpkg
Nobody told about the lock files.
Imagine you use yarn on dev environment, and yarn on your build/production servers. When you install a package using yarn, and your project works on your computer, you probably would want to keep it working on a production environment (your server).
That being sad, you would commit you yarn.lock file, that "saves" the exact versions of each package you have, when the project ran on your computer.
On your buid/production server you should call yarn install
, but asking to keep all the same versions with --frozen-lockfile
parameter. Some even say "yarn install --frozen-lockfile
should be the default behavior", and I agree.
Then... another dev jump in the project you are working and install a package using npm
(other than yarn
). That new package will not be included in your yarn.lock
file, but, a new package-json.lock
file would be created, telling the exact packages versions it is using.
When that commit arrives on your build/production server, it will crash, fail, because that new package doesn't exist on yarn.lock
file. Someone would need to pull that changes, call a yarn
to install the dependences and update the lock file with the new package dependences, and push it again to the repo.
A quick point about using the lock file or not. If you call a 'yarn install' on your build/production server some weeks after the last install on your machine, the server would have many other new versions than your last "stable" version. It already happened to me many times.
I published recently the package-locks-checks, which help ensure you have not just one lock file but also locked each package version on your project.
Solution 4 - Yarnpkg
Here https://classic.yarnpkg.com/en/docs/migrating-from-npm/ we may find a confirmation that Yarn's resolution algorithm is compatible with NPM resolution algorithm.
Inside a npm project (with package.json) if you run yarn
it will read your node_modules
folder (using the resolution algorithm) and create a yarn.lock
file with your project's locked dependency tree.
Based on that I assume that they are compatible inside the same project.
Update 30/04/2021
My original reply refers to yarn 1 (classic)
, although I've just created a React app with create-react-app
tool and it creates the project's repository with package.json
+ yarn.lock
by default. Again, another demonstration that it's fine (even with the warning mentioned by Dave Pile).
At the end of the day this is a matter of putting both together to work and checking yourself...
Solution 5 - Yarnpkg
Plus you get a warning from yarn
as Dave Pile said because we have to push *-lock.json
files changes you have to consider using npm version >= 7 to make sure whenever you install packages by npm
it will update your yarn-lock.json
file too.
Because whenever you install the packages either by npm
or yarn
depends on what you have chosen for updating a dependency in the package.json
(Using tilde ( ~ ) which gives you bug fix releases and caret ( ^ ) gives you backward-compatible new functionality) it will update you.lock
file and since you have to push it might happen that you have different version of lock files.