Yarn 4.0

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • orogene

    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

  • corepack

    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

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

    SurveyJS logo
  • setup-bun

    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:

  • pn

    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.

  • pacquet

    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.

  • wireit

    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

  • rfcs

    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

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • pnpm

    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

  • pnpm.io

    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

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts