Development: Use yarn instead of npm

[wachunei]

Hey everybody,

I was beginning to work on a contribution and since there's a package-lock.json file I assumed the library is using npm as a package manager, but after running npm install I realized the package-lock.json file gets regenerated, I was like: what? isn't the point of the lockfile to lock dependencies? what about shrinkwrap? I'm confused now.

So it seems like npm has not settled down what it really means to have this file, so I'm proposing to move from npm and use yarn as the package manager, this way dependencies are the same across contributor.

However, I guess I'm not understanding something right about npm, so if you have any ideas about what's going on please share on comments, maybe change the package manager is not necessary and I'm just wrong about it.

[jaydenseric]

Please don't, many people are migrating from Yarn back to npm now it has caught up. Yarn is not really appropriate for OSS since most people don't have it installed and it is not part of a standard Node.js environment.

Besides, best practice is to .npmrc package-lock=false and .gitignore package-lock.json files for packages intending to be published. npm doesn't publish lockfiles to prevent bloating consumer node_modules with multiple versions of the same package; a lockfile in development gives a false sense of stability. It's also annoying for merge conflicts, etc. when juggling multiple PRs in a public project.

[wachunei]

Thanks for your answer! That's quite a big thread and with some different opinions. At what point was decided in this project to include package-lock.json? I'm still confused about the role that file is playing, so I might take some time next days to read that thread and come back with an informed opinion.

[jbielick]

@jaydenseric, could you expound on "a lockfile in development gives a false sense of stability."? How do we lock dependencies of this library so that users don't get minor version upgrades of our dependencies that may not be compatible? Use -E?

[jaydenseric]

@jbielick

could you expound on "a lockfile in development gives a false sense of stability."?

npm hard blacklists lockfiles from being published. If you have a lockfile in this repo, the only time it will be used is by yourself and other contributors when they clone the repo and npm install for local development of the package. The lockfile captures dependencies at a moment in time, and after a few days a fresh lockfile can have a large diff. You end up developing your package against what npm looked like days, weeks or even months ago, vs the npm your consumers install with now. Your tests may pass locally but your consumers might experience something totally broken. If CI uses the lockfile then the situation is even worse.

How do we lock dependencies of this library so that users don't get minor version upgrades of our dependencies

The only way is to pin the dependencies to exact versions (no ^). This is a terrible anti-pattern! If every package did that, consumer's node_modules would be gigabytes of duplicated packages at every pinned version (a nightmare for client project bundle sizes). Users would not benefit from important patches deep in the dependency tree, with no way to opt-in. Sure, you may alleviate the maintenance burden for your package, but you end up burdening the entire ecosystem around you. If npm thought it was a good idea, they would not blacklist lockfiles from being published.

The problem of patch versions creating issues is minor, but real. The most efficient solution is for consumers to update all their dependencies, test their project works ok then create a lockfile until the next time their are ready to update and test.

[jbielick]

Makes sense. Thanks for the explanation!

[jbielick]

I’ll delete the lock file and contributors can use whatever package manager suits them.