Our great sponsors
-
corepack
Zero-runtime-dependency package acting as bridge between Node projects and their package managers
-
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.
-
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.
Said rust npm package manager already exists, but it's somewhat buggy still:
https://github.com/orogene/orogene
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
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:
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.
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.
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
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
│ └── 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
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