Moving settings to pnpm-workspace.yaml

[zkochan]

Currently we use 3 files for configuring pnpm:

• We use .npmrc for most of the settings. Mostly simple settings but also some that can be arrays
• We also load settings from the pnpm field in package.json. These are mostly more complex settings with arrays and objects.
• We also load catalogs from pnpm-workspace.yaml

We need to stop storing settings in package.json as it breaks the fetch command. See related issue: #9033. Moving all settings to the .npmrc ini file is not convenient. The best approach seems to be to move all the settings to pnpm-workspace.yaml. On top of the settings from package.json we may also move all the pnpm-specific settings from .npmrc and only keep auth related settings in .npmrc for npm compatibility.

Some settings may be project-specific. Instead of creating separate configuration files for projects in the workspace, we could create configuration overrides in the root pnpm-workspace.yaml. For instance:

packages:
  - "**"
hoistPattern:
  - eslint
configOverrides:
  - globs:
      - back-end/**
    settings:
      executionEnv:
        nodeVersion: 16.16.0

Related PRs:

• feat: reading settings from pnpm-workspace.yaml #9121
• feat: setting config settings via pnpm-workspace.yaml #9211
• feat: config set local should save settings in pnpm-workspace.yaml #9316
• feat: config delete local should delete setting in pnpm-workspace.yaml #9317
• feat: config update hook #9325

npm CLI will disallow 3rd party settings in .npmrc from v12. Related issue: #9232

[KSXGitHub]

There are many subtle bugs related to .npmrc and workspace root being at different places. Moving all settings to the workspace manifest would solve this problem.

[zkochan]

I was trying to recall settings that can be placed in nested directories but couldn't remember any except the executionEnv.nodeVersion

[KSXGitHub]

It's usually fine when the there is only one .npmrc at the workspace root. But sometimes, the monorepo doesn't have a .npmrc, but the home directory has one. This causes problem.

[gluxon]

This is a good idea! We've hit a lot of strange issues when reusing .npmrc. Ex: #6701

[zkochan]

Moving the settings from .npmrc will be a bit complicated unless we will give them more priority then the settings set via npm_config_ env variables. Which might be OK.

[zkochan]

I would like to also make it possible to share settings via configurational dependencies. I think the easiest and most powerful way to do it would be via introducing a new hook for config settings that could read the existing settings and extend/change them.