pnpm_10: init at 10.0.0

[gepbird]

Release: https://github.com/pnpm/pnpm/releases/tag/v10.0.0

Since the store and lockfile format has changed, we can't use pnpm_10 for packages previously using the latest pnpm. Therefore I pinned packages' pnpm to pnpm_9.

TODO

• read through the release notes and see if we can improve on the current infrastructure

  Store version bumped to v10.

  Upgraded @yarnpkg/extensions to v2.0.3. This may alter your lockfile.

  pnpm.fetchDeps hashes will change, as expected from a new major release

  Lifecycle scripts of dependencies are not executed during installation by default

  In the pnpm tools already use --ignore-scripts where possible, this may affect packages

  Overall there doesn't seem to be any new features for us

• bump default pnpm to pnpm_10 (packages using pnpm are now pinned to pnpm_9)

• update release notes (we can skip this if we stick to pinning old pnpm packages to pnpm_9)

• figure out error: "Cannot install with "frozen-lockfile" because pnpm-lock.yaml is absent"

  • removing --force from the pnpm install command will say "Lockfile /build/source/pnpm-lock.yaml not compatible with current pnpm"
  • needs testing with a pnpm 10 compatible project
    • pnpm config set store-dir my-store && pnpm install installs deps to my-store on v9, but installs to default location in v10, but this only happens if there are no node_modules/dist folders
    • solution: have a pnpm 10 compatible project with no existing generated store

• find all PRs that are using the pnpm package and warn them that it's being changed from pnpm_9 to pnpm_10to avoid breakages (after this is merged)

  there are 15 such PRs (last updated: 2024-01-15)

   195231
   265771
   317162
   326238
   329349
   350065
   350645
   353814
   355762
   358582
   359016
   366043
   369278
   369554
   372249
  

How should we deal with soon EOL pnpm 8? (followup PR)

With a new major release and pnpm_8 being EOL in about 4 months, I think we should try to bump pnpm version in packages.

How much we should wait before starting to bump?

• wait a few days: at least this to give pnpm some time to stabilize, just in case if a major issue is found that would require changing the hashes or similar
• wait ~3 months: hopefully we can migrate more packages to pnpm 10 by this time, however we shouldn't leave it to the last minute, because if we can't finish it in time for whatever reason, EOL eval warnings can be frustrating to users; it may also lead to less hash changes overall, breaking less PRs

I'd start it ~1-2 months depending on how many PRs are touching pnpm versions, what do you think @Scrumplex?

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[gepbird]

I patched stylelint-lsp to use pnpm_10 outside of this PR, it builds and works.

nixpkgs-review is broken again and shows 0 rebuilds, but CI shows pnpm and pnpm_10 which is good.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 371832

[Kamillaova]

please also backport it to 24.11

[Scrumplex]

please also backport it to 24.11

In that case, we should make sure to keep pnpm pointing at pnpm_9 to avoid breakage for downstream users.

[Scrumplex]

Changes LGTM

[Scrumplex]

Proposal for release note entry:

Pnpm was updated to version 10. If your project is incompatible, you can install the previous version from the package attribute pnpm_9

[gepbird]

Rebased to master as a package using pnpm got merged which needs to be changed to pnpm_9

[gepbird]

Only rebuild is still pnpm_10

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 371832

---

x86_64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

✅ 1 package built:

• pnpm (pnpm_10)

[Scrumplex]

There is another conflict.

Apart from that, I'd suggest dropping pnpm 8 soon. As pnpm 9 can work with lockfiles generated by pnpm 8, I don't really see many reasons to keep it around.

After you rebase, I'd say this is good to merge

[gepbird]

Apart from that, I'd suggest dropping pnpm 8 soon. As pnpm 9 can work with lockfiles generated by pnpm 8, I don't really see many reasons to keep it around.

I'm happy with starting the pnpm_8 -> pnpm_9 migration sooner, but I'd rather keep pnpm_8 until it hits EOL, even when there are no references to it in nixpkgs, just in case someone still uses that.

I'm creating the backport PR soon including the pnpm_10 init and pinning pnpm to pnpm_9 changes, but excluding setting the default pnpm to pnpm_10 and release note changes.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 371832

---

x86_64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

✅ 1 package built:

• pnpm (pnpm_10)

[gepbird]

Fixed a few instances where the file has let pnpm = pnpm_9 and I mistakenly bumped pnpm.{configHook,fetchDeps}. I believed nixpkgs-vet would catch as pnpm became an unused variable but turns out it didn't.