I just recently successfully changed to using yarn on one of my systems, replacing npm, for my react-native projects. used yarn version 1.22.11.I ran it and it resolved dependencies beautifully and there were no problems.
So I copied the project over to another computer. I wanted to do the same thing -- use yarn with it-- but when I run the 'yarn' command, instead of going through my directory and fixing my dependencies...
...yarn goes through my directory and deletes not only the files, but the folders!! This is yarn version 2.4.1.
Anyone have thoughts about why this might happen?
yarn 2 does not use or create node_modules directory by default, instead it uses a new technology called plug 'n play (pnp). If you upgrade to yarn 2.x from yarn 1.x it will delete the node_modules folder.
For a primer on yarn 2 and pnp, see https://dev.to/arcanis/introducing-yarn-2-4eh1 and https://yarnpkg.com/features/pnp
If you want to turn off pnp in yarn 2 and use node_modules, see: How to turn off yarn#2 PnP?
But most of the community has stuck with yarn 1.x. See https://blog.hao.dev/state-of-yarn-2-berry-in-2021
You may decide to stick with yarn 1.x, return to npm, or try yarn 2.x berry with or without pnp. In general, if your project can work with pnp, it is much faster. However, many packages in the javascript ecosystem are incompatible.
Update 2022: Yarn 3.x is now available, and is easier to update to than yarn 2. pnpm is now also an interesting choice.
Related
The npm-shrinkwrap ensures that installed packages also have the same version of dependencies that was used at the moment of publishing to the registry (These versions are stated in the npm-shrinkwrap which is then used on installation).
I am currently using yarn (and lerna for publishing) and working on a monorepo project with workspaces. Now I would like to have each package in the monorepo have same guarantees provided by npm-shrinkwrap.
One shortcoming of the npm-shrinkwrap is that it does not support workspaces. Hence I cannot use npm-shrinkwrap since it is only created at the root and does not influence how individual packages in the monorepo get installed.
Since I am using yarn, I was wondering if there is an alternative to npm-shrinkwrap in yarn?
Or maybe a better question is, using yarn/lerna, how do I lock version dependencies for publication, such that when my packages in the mono-repo are downloaded, they are downloaded with the exact versions of dependencies (and transitive dependencies) that was specified at the point of publication?
I found the following in the yarn docs (classic yarn 1.x)
If you are using an npm-shrinkwrap.json file right now, be aware that you may end up with a different set of dependencies. Yarn does not support npm shrinkwrap files as they don’t have enough information in them to power Yarn’s more deterministic algorithm. If you are using a shrinkwrap file it may be easier to convert everyone working on the project to use Yarn at the same time. Simply remove your existing npm-shrinkwrap.json file and check in the newly created yarn.lock file.
From here:
https://classic.yarnpkg.com/en/docs/migrating-from-npm
My team is working on a react native project using GitHub for version control and we have been having a lot of issues dealing with npm dependencies. Every time we push to the master branch we keep getting conflicts with the package-lock.json file ... any best practices around that?
When you install the dependencies of libraries, you need to lock down the version of them. So You should get used to the package manager like npm, yarn, ...
I recommend use Yarn This is the document for how to using it. https://yarnpkg.com/en/docs
ie: install lib react-native-button. you just need run command yarn add react-native-button and commit the yarn.lock with package.json files. Then the guys in your team can pull these changes and run 'yarn install' to keep the synchronize for you projects.
Check it out and try. it is simple!
I recently started using pnpm as a package manager to for my node modules. This download allows for just one version of a package to be saved only once on a disk. This saves my hard drive space by only downloading the packages that the aforementioned download doesn't already have in a global scope. I was wondering if there are any other viable options that would assist in not having to run 'npm install' for every new project. Thanks in advance.
There is a new beta command in pnpm that allows doing installation in many projects at the same time. It is called pnpm recursive install.
Run pnpm help recursive to see the docs. As of pnpm#1.25, it prints:
pnpm recursive [concurrency] install
Experimental! Concurrently runs installation in all subdirectories with a package.json (excluding node_modules).
Options: same as for pnpm install
pnpm recursive [concurrency] update
Experimental! Concurrently runs update in all subdirectories with a package.json (excluding node_modules).
Options: same as for pnpm update
As far as I know, pnpm is currently the only Node.js package manager that has this feature.
Alternatively, you can use some monorepo-managing tool like lerna. It will run the package manager in each project for you. It will be a lot slower than pnpm recursive though.
You can try Yarn by Facebook: https://yarnpkg.com/en/
From their website:
Yarn caches every package it downloads so it never needs to download it again. It also parallelizes operations to maximize resource utilization so install times are faster than ever.
However, you still have to run yarn install for each package. I don't think it's ever really ideal to "share" packages between different installs. What if you had to make a one-off change to a package file? That would then affect all your pojects.
What exactly are you trying to avoid/do with your package manager? Yarn is incredibly easy to use and builds out all dependency relations based upon the package.json.
Everytime you make a new project npm install has to be run as it builds the node-modules that will be used for the node_modules. Whether you use Yarn, or pnpm, you still will have to do the equivalent of yarn add, etc.
For managing many dependencies, yarn is really nice because you can yarn add [insert package here] and yarn start.
I'm working on an open source project which is currently using lerna to help manage a single repository with multiple packages. So far, so good, except that every now and then something breaks because we don't currently shrinkwrap anything. I've been trying to do some monorepo version of shrinkwrapping so that we're not at the mercy of all our dependencies (it's amazing how often everything goes wrong in the middle of a release!) but have hit a bit of a wall and wondered if I'm even on the right track.
I was originally hoping to use npm shrinkwrap which I was familiar with from previous projects. Unfortunately lerna doesn't appear to support shrinkwrap.
Plan B was to make use of yarn which, after some initial difficulties, seemed to be going ok after switching to using yarn workspaces- at least I think yarn install --frozen-lockfile was doing what I wanted.
Unfortunately, other than dependency locking, yarn doesn't seem to be helping- everything worked with npm and lerna, but lerna and yarn workspaces seems to be causing issues resolving modules (even resolving something in the same directory which is baffling).
Maybe switching to yarn is overkill anyway so I started wondering if more recent versions of npm and package-lock.json would be a better idea. Unfortunately that looks like it would need some work arounds with lerna at which point I'm beginning to wonder how much lerna is really adding. Maybe dropping lerna would help?
So, tl;dr, does anyone have a good way of locking down module dependencies in a monorepo?
I'd suggest simply using exact versioning; so in your package.json files where there are version numbers for dependencies like ^3.4.2, changing it to 3.4.2. The ^ (or ~) before the number suggest a version range. You can get that to happen with the save exact config option: --save-exact flag or by placing save-exact=true in a .npmrc file in the repo. lerna add also supports an exact option.
Hope that helps!
yarn is a production ready package manager that natively supports monorepos :)
When using yarn workspaces, there is no need to use lerna as a monorepo manager as well at the same time.
You can use other features of lerna if you want, but there is no reason to use lerna for installing monorepos (which are already uses yarn).
If there is a specific errors when installing/managing monorepo using yarn, please add them to the question.
Notes:
--frozen-lockfile doesn't do anything in yarn monorepo. yarn has a open issue on that which I think won't resolve soon.
I work in a team of about 20 other developers. All of our projects utilize npm packages and currently all of our developers are running npm to manage those packages. I'm very curious about Yarn and have it currently installed on my machine. However I'm nervous to actually use it to install packages in case it screws up a project for other developers.
My question is can one developer utilize Yarn on a project while other devs are using npm in the same repo? From what I've read, Yarn uses the same package.json file to get its dependencies. We ignore the node_modules in our repo, however we use npm shrinkwrap to lock dependencies. I know Yarn has a Yarn.lock file and that is where my concern lies. Has anyone attempted to run Yarn independently from their team and what issues have you run into?
Yarn doesn't read npm-shrinkwrap.json. It generates its own yarn.lock. While only you use yarn, the project in your environment might have dependencies version different then that your teammates have. However it's safe to try yarn in your own environment since it doesn't overwrite shrinkwrap file and won't impact other developers.