pnpm v11 - planned breaking changes discussion

[zkochan]

This was a discussion about pnpm v11 breaking changes. For the v11.0 there is this discussion: https://github.com/orgs/pnpm/discussions/11377

Planned breaking changes:

• Stop reading from and populating the npm_config_ env variables. npm doesn't allow 3rd party tools to use this env variables. Otherwise it fails on unknown settings.
• Remove the deprecated allowNonAppliedPatches completely in favor of allowUnusedPatches.
• Remove ignorePatchFailures. All patch application failures should throw an error. This includes removing the special (legacy) exception for name-only patches.
• Stop reading settings from the "pnpm" field of package.json.
• Change the global configuration file to be in Yaml format.
• Drop Node.js v18 support.
• Remove the pnpm server command from pnpm. Support it via hooks as a 3rd party tool.
• Make init-type=module by default
• Make enableGlobalVirtualStore true by default. This one would be a big change but would make pnpm stand out. Related issue: Fail to find package in global virtual store #9618 It will be enabled by default for global packages, dlx, runtimes, config dependencies, and package manager dev engines.
• remove the useNodeVersion and executionEnv.nodeVersion settings. But before that we might want to optimize how node.js is installed via engines, symlink to a global location.
• make strictDepBuilds=true by default.
• remove old fetcher hooks.
• bump version of the store to v11.
• explore changes to the index file format that would make install faster. Maybe storing integrities in a different format.

[KSXGitHub]

@zkochan I have added new items to the list. Although, maybe we should completely remove ignorePatchFailures setting?

[zkochan]

yes, I think we should remove it

[KSXGitHub]

I have edited it.

[rrosenshain-sc]

Stop reading from and populating the npm_config_ env variables. npm doesn't allow 3rd party tools to use this env variables. Otherwise it fails on unknown settings.

We use a config to pass variables to scripts in package.json. If we can't use the config, what's the best way to pass values to scripts?

[zkochan]

You can declare the env variables directly, no?

[rrosenshain-sc]

yea but I want engineers not having to think about which ENV VAR to pass.

Over-simplified example:
Instead of them having to run NODE_ENV=prod pnpm myScript / NODE_ENV=staging pnpm myScript I want to have a script in package.json:
start:dev: NODE_ENV=dev pnpm myScript
start:prod: NODE_ENV=prod pnpm myScript

[zkochan]

This example that you provided will still work.

[jenewland1999]

Will v11 drop support for the soon to reach EOL build of Node, v18?

[zkochan]

yes

[jenewland1999]

Stop reading settings from the "pnpm" field of package.json.

Have you published any rationale or reason for why you're dropping support for this field and what is going to be used in favour? Also, will there be any automated means of migration built in for existing things listed under the pnpm field?

[zkochan]

In the past we had 2 ways of declaring settings. Some were set in .npmrc and some in the "pnpm" field of package.json. Now we will have a single place for the settings: pnpm-workspace.yaml. Related discussion: https://github.com/orgs/pnpm/discussions/9037. The docs are already updated: https://pnpm.io/settings

I don't know if there will be automated migration. Maybe someone will create a codemod for this.

[karlhorky]

I think @bilalq made a good point about making strictDepBuilds: true the default in the next major version, which would be pnpm v11:

It may even make sense to make this the default on the next major version bump. Failures deferred till runtime are the worst, so anything to make those less likely is amazing.

• feat: add an option to fail on unapproved dependency builds #9071 (comment)

[zkochan]

I am also considering changing onlyBuiltDependencies, ignoredBuiltDependencies, and neverBuiltDependencies. I think it would be better to have instead something like what lava moat is using:

allowBuilds:
  esbuild: true
  core-js: false
  ghooks: 'warn'

pnpm would be able to prepopulate this setting on install and then the user would have the choice to either run pnpm approve-builds or edit the settings.

I am open to using allowScripts instead too but then we need to also rename the approve-builds command and dangerouslyAllowAllBuilds

Related issue: #10235

[mcmxcdev]

If v11 "stops reading settings from the pnpm field of package.json", does the same apply for .npmrc ?

We use that file and have comments in there like:

# TODO: Remove once https://github.com/vercel/next.js/issues/68805 has been resolved
public-hoist-pattern[]=*import-in-the-middle*
public-hoist-pattern[]=*require-in-the-middle*

To my knowledge, the last time I checked the pnpm-workspace.yaml doesn't preserve comments when it gets autoformatted by pnpm which would be a loss of functionality. I feel like this would be a pre-requisite to solve before v11, the related issue is #2008 and more specifically this comment: #2008 (comment)

[zkochan]

We can't use .npmrc. npm CLI will start throwing errors on unknown settings in .npmrc.

[mcmxcdev]

That is clear, what I was saying is that pnpm-workspace.yaml needs feature parity, at least retaining comments, otherwise people will not be able to migrate without downsides.

[zkochan]

The comments are preserved #10402

[zkochan]

Everything that was planned for pnpm v11 is implemented.

[stphane]

If I understand correctly, useNodeVersion and nodeVersion should be abandoned (from both pnpm-workspace.yaml and .npmrc ) in favor of package.json engines section, right?
~ Thank you for the hard work ~

[zkochan]

yes

[david-plugge]

Awesome! Is there a planned release date?

[michkot]

I wanna check about the pnpm-workspace.yaml behavior: with v10 I saw some surprising/undefined behavior with cases like this:

root/package.json
root/pnpm-lock.yaml
root/pnpm-workspace.yaml -- with packages: "."
root/nested/package.json

Doing pnpm install inside root/nested/ often ignores root/nested/package.json -- pnpm sees pnpm-workspace.yaml + lockfile above does not even consider that this root/nested/package.json not in its workspace.

What will be the guidance for v11 for this? Always create empty pnpm-workspace.yaml beside package.json if they are single-package projects?
+, what will the default value for "packages" in workspace be? ".", or "*" ?

[michkot]

Hmm so "By default, all packages of all subdirectories are included." this statement from https://pnpm.io/pnpm-workspace_yaml untrue for v10/v11?

[michkot]

Here is repro-as-tests for what I am talking about #11296

[michkot]

@zkochan Sorry to nudge you again, but I’m still looking for a definitive answer here. To recap: how should we handle nested packages in pnpm v11 so they don’t automatically form a workspace together?

[zkochan]

I have answered you above. I don't have a different answer.

[zkochan]

The document on the website should be updated.

[stefanprobst]

in v11, does pnpm info work when only pnpm is set in devEngines.packageManager?

[zkochan]

yes

[HasanMothaffar-OSG]

I cannot update to V11. When I run pnpm self-update on Windows, this is the output:

pnpm self-update

Nothing to stop. No server is running for the store at C:\Users\Lenovo\AppData\Local\pnpm\store\v10
The currently active pnpm v10.33.2 is already "latest" and doesn't need an update

Even the pinned version for pnpm in the docs is 10.X, and when I navigate to the V11 docs, it shows this alert.

How can I update to V11? Isn't it the latest release?

[zkochan]

You can run:

pnpm self-update latest-11

No, it is not latest yet but it is stable.

[zkochan]

This was a discussion about pnpm v11 breaking changes. For the v11.0 there is this discussion: https://github.com/orgs/pnpm/discussions/11377