pnpm v11

[zkochan]

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.

[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.