Yarn 4.0

1. orogene

   1 4 1,500 1.7 Rust

   Makes `node_modules/` happen. Fast. No fuss.

   

   Said rust npm package manager already exists, but it's somewhat buggy still:

   https://github.com/orogene/orogene

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. corepack

   2 7 3,007 8.5 TypeScript

   Zero-runtime-dependency package acting as bridge between Node projects and their package managers

   

   I'd love to use Bun for my projects, but it's not integrated into Corepack yet (and therefore you cannot pin the bun version w/ checksum in package.json)

   https://github.com/nodejs/corepack/issues/295

4. setup-bun

   3 1 564 6.5 TypeScript

   Set up your GitHub Actions workflow with a specific version of Bun

   

   I use Bun in CI too, and they have a clean GitHub Action for it: https://github.com/oven-sh/setup-bun.

   Actually now that you mention CI, I remember now that I did also run into non-deterministic problems runnign type checks on projects with Bun using Github's free runner.

   Errors looked like this, but it worked fine every 2/3 runs with the exact same code:

5. pn

   4 1 114 3.8 Rust

   This is an experimental wrapper over the pnpm CLI written in Rust

   

   b) use syncpack to ensure all your dependencies in different workspaces use the same versions. This doesn't need to be done in the package manager.

   pnpm also has pnpm licenses to help keep compliance happy.

   If someone wants to write a package manager in Rust for speed (pnpm is already moving in this direction, see https://github.com/pnpm/pn and https://github.com/pnpm/pacquet ), we'd take a look. Otherwise - not enough benefit to switching away.

6. pacquet

   5 2 778 5.8 Rust

   experimental package manager for node.js

   

   b) use syncpack to ensure all your dependencies in different workspaces use the same versions. This doesn't need to be done in the package manager.

   pnpm also has pnpm licenses to help keep compliance happy.

   If someone wants to write a package manager in Rust for speed (pnpm is already moving in this direction, see https://github.com/pnpm/pn and https://github.com/pnpm/pacquet ), we'd take a look. Otherwise - not enough benefit to switching away.

7. wireit

   6 17 6,223 7.3 TypeScript

   Wireit upgrades your npm/pnpm/yarn scripts to make them smarter and more efficient.

   

   npm workspaces plus Wireit works far better than Lerna, in my experience.

   https://github.com/google/wireit

   Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and it's long-running service script support make it much more useful and comprehensive than Lerna.

   I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706

8. rfcs

   7 37 745 4.1 JavaScript

   Public change requests/proposals & ideation (by npm)

   

   npm workspaces plus Wireit works far better than Lerna, in my experience.

   https://github.com/google/wireit

   Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and it's long-running service script support make it much more useful and comprehensive than Lerna.

   I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706

9. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

10. pnpm

    8 130 31,892 9.8 TypeScript

    Fast, disk space efficient package manager

    

    │ └── tsconfig.json

    Whenever pnpm installs workspace dependencies, it installs them at the root of the workspace, (in the tore inside the docker build image of course, not on the host), and those are the dependencies for all 3 packages all together in one virtual store, here:

    ./node_modules/.pnpm

    So, when I want to create my container image for say packages/app1, I don't see how I could copy only my dependencies for that app from the build image like this:

    COPY --from=deps /app/packages/app2/node_modules/ /app/packages/app2/node_modules

    Because while of course the dependencies are installed in the build image, they are at the root of the workspace in virtual store there, and not in /app/packages/app2/node_modules/ – this directory only contains symlinks to the root virtual store.

    Of course I can copy all the dependencies from the root virtual store of the build image into my image, but then those are the dependencies for ALL packages in the workspace, not just for app1

    I suppose I could try to install only the dependencies for app1, but this is broken with the default pnpm settings at the moment (it still installs dependencies for everything in the workspace)

    https://github.com/pnpm/pnpm/issues/6300

11. pnpm.io

    9 3 256 9.5 JavaScript

    pnpm's website

    

    An update on this:

    After talking to one of the contributors on Discord, it seems that they have a special "deploy" command for exactly this (copying files and dependencies for a single workspace package) which I had overlooked since the documentation for it wasn't so self explanatory, they have now updated the docs for this command [1] and opened a PR to update the docs for the Monorepo Docker example to use it instead [2].

    I have to say I'm impressed with how responsive the maintainers were to my question, and this `pnpm deploy` workflow does actually make sense to me.

    [1] https://github.com/pnpm/pnpm.io/commit/3e6cb7b2cdaf23a423c31...

    [2] https://github.com/pnpm/pnpm.io/pull/469

Suggest a related project