pnpm 10

[zkochan]

Major Changes

• Lifecycle scripts of dependencies are not executed during installation by default! This is a breaking change aimed at increasing security. In order to allow lifecycle scripts of specific dependencies, they should be listed in the pnpm.onlyBuiltDependencies field of package.json #8897. For example:

  {
    "pnpm": {
      "onlyBuiltDependencies": ["fsevents"]
    }
  }

• pnpm link behavior updated:

  The pnpm link command now adds overrides to the root package.json.

  • In a workspace: The override is added to the root of the workspace, linking the dependency to all projects in the workspace.
  • Global linking: To link a package globally, run pnpm link from the package’s directory. Previously, you needed to use pnpm link -g.
    Related PR: #8653

• Secure hashing with SHA256:

  Various hashing algorithms have been updated to SHA256 for enhanced security and consistency:

  • Long paths inside node_modules/.pnpm are now hashed with SHA256.
  • Long peer dependency hashes in the lockfile now use SHA256 instead of MD5. (This affects very few users since these are only used for long keys.)
  • The hash stored in the packageExtensionsChecksum field of pnpm-lock.yaml is now SHA256.
  • The side effects cache keys now use SHA256.
  • The pnpmfile checksum in the lockfile now uses SHA256 (#8530).

• Configuration updates:

  • manage-package-manager-versions: enabled by default. pnpm now manages its own version based on the packageManager field in package.json by default.

  • public-hoist-pattern: nothing is hoisted by default. Packages containing eslint or prettier in their name are no longer hoisted to the root of node_modules. Related Issue: #8378

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

  • virtual-store-dir-max-length: the default value on Windows has been reduced to 60 characters.

  • Reduced environment variables for scripts:
    During script execution, fewer npm_package_* environment variables are set. Only name, version, bin, engines, and config remain.
    Related Issue: #8552

  • All dependencies are now installed even if NODE_ENV=production. Related Issue: #8827

• Changes to the global store:

  • Store version bumped to v10.

  • Some registries allow identical content to be published under different package names or versions. To accommodate this, index files in the store are now stored using both the content hash and package identifier.

    This approach ensures that we can:

    1. Validate that the integrity in the lockfile corresponds to the correct package, which might not be the case after a poorly resolved Git conflict.
    2. Allow the same content to be referenced by different packages or different versions of the same package.
       Related PR: #8510
       Related Issue: #8204

  • More efficient side effects indexing. The structure of index files in the store has changed. Side effects are now tracked more efficiently by listing only file differences rather than all files.
    Related PR: #8636

  • A new index directory stores package content mappings. Previously, these files were in files.

• Other breaking changes:

  • The # character is now escaped in directory names within node_modules/.pnpm.
    Related PR: #8557
  • Running pnpm add --global pnpm or pnpm add --global @pnpm/exe now fails with an error message, directing you to use pnpm self-update instead.
    Related PR: #8728
  • Dependencies added via a URL now record the final resolved URL in the lockfile, ensuring that any redirects are fully captured.
    Related Issue: #8833
  • The pnpm deploy command now only works in workspaces that have inject-workspace-packages=true. This limitation is introduced to allow us to create a proper lockfile for the deployed project using the workspace lockfile.
  • Removed conversion from lockfile v6 to v9. If you need v6-to-v9 conversion, use pnpm CLI v9.
  • pnpm test now passes all parameters after the test keyword directly to the underlying script. This matches the behavior of pnpm run test. Previously you needed to use the -- prefix.
    Related PR: #8619

• node-gyp updated to version 11.

• pnpm deploy now tries creating a dedicated lockfile from a shared lockfile for deployment. It will fallback to deployment without a lockfile if there is no shared lockfile or force-legacy-deploy is set to true.

Minor Changes

• Added support for a new type of dependencies called "configurational dependencies". These dependencies are installed before all the other types of dependencies (before "dependencies", "devDependencies", "optionalDependencies").

  Configurational dependencies cannot have dependencies of their own or lifecycle scripts. They should be added using exact version and the integrity checksum. Example:

  {
    "pnpm": {
      "configDependencies": {
        "my-configs": "1.0.0+sha512-30iZtAPgz+LTIYoeivqYo853f02jBYSd5uGnGpkFV0M3xOt9aN73erkgYAmZU43x4VfqcnLxW9Kpg3R5LC4YYw=="
      }
    }
  }

  Related RFC: #8.
  Related PR: #8915.

• New settings:

  • New verify-deps-before-run setting. This setting controls how pnpm checks node_modules before running scripts:

    • install: Automatically run pnpm install if node_modules is outdated.
    • warn: Print a warning if node_modules is outdated.
    • prompt: Prompt the user to confirm running pnpm install if node_modules is outdated.
    • error: Throw an error if node_modules is outdated.
    • false: Disable dependency checks.
      Related Issue: #8585

  • New inject-workspace-packages setting enables hard-linking all local workspace dependencies instead of symlinking them. Previously, this could be achieved using dependenciesMeta[].injected, which remains supported.
    Related PR: #8836

• Faster repeat installs:

  On repeated installs, pnpm performs a quick check to ensure node_modules is up to date.
  Related PR: #8838

• pnpm add integrates with default workspace catalog:

  When adding a dependency, pnpm add checks the default workspace catalog. If the dependency and version requirement match the catalog, pnpm add uses the catalog: protocol. Without a specified version, it matches the catalog’s version. If it doesn’t match, it falls back to standard behavior.
  Related Issue: #8640

• pnpm dlx now resolves packages to their exact versions and uses these exact versions for cache keys. This ensures pnpm dlx always installs the latest requested packages.
  Related PR: #8811

• No node_modules validation on certain commands. Commands that should not modify node_modules (e.g., pnpm install --lockfile-only) no longer validate or purge node_modules.
  Related PR: #8657

---

This discussion was created from the release pnpm 10.

[MikeMcC399]

@zkochan

Congratulation on the v10 release! Will you set v10.0.0 to latest now or will you set v10 to latest on a later date?

https://github.com/pnpm/pnpm/releases/tag/v9.15.3 still owns the latest tag

$ npm view pnpm dist-tags
{
  'latest-1': '1.43.1',
  'latest-2': '2.25.7',
  'latest-3': '3.8.1',
  'latest-4': '4.14.4',
  'latest-5': '5.18.10',
  dev: '6.23.7-202112041634',
  pr4475: '0.0.0-pr4475.1',
  'latest-6': '6.35.1',
  'next-6': '6.35.1',
  'latest-7': '7.33.5',
  'next-7': '7.33.7',
  'latest-8': '8.15.9',
  'next-8': '8.15.9',
  latest: '9.15.3',
  'next-9': '9.15.3',
  'latest-9': '9.15.3',
  'next-10': '10.0.0',
  'latest-10': '10.0.0'
}

[zkochan]

I will set it on a later date. I want to see if any major issues will get reported.

[MikeMcC399]

Good strategy! Thank you for confirming what I guessed!