pnpm: set the overrides but it looks like not work

pnpm version:

6.17.0

Code to reproduce the issue:

Recently, out project change from yarn to pnpm because of its speed. But when I install the modules, I find it not like what we expected.(Maybe I think the overrides property is like yarn resolution) Here is the package.json code

{
    "dependencies": {
        "@editor-kit/core": "3.37.0-rc.0"
    }
    "pnpm": {
        "overrides": {
                "@editor-kit/core": "3.37.0-rc.0"
        }
    }
}

Here is the node_modules Topology in .pnpm folder after pnpm install

Also in pnpm-lock.yaml file, I find the same version package(@editor-kit/core) with different hash.

Expected behavior:

Just one package will be install when I set the overrides

Actual behavior:

Many package, and these package have same version with different hash. Really expecting a reply!

Additional information:

Old and large project, there is too much dependencies

node -v prints: 14.16.0
Windows, macOS, or Linux?: macOS

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 15
Comments: 20 (2 by maintainers)

Most upvoted comments

It would be great having this work for workspaces

+19

ssijak on Dec 8, 2022

It seems counterintuitive that overrides would not work for workspaces because I was under the impression that workspaces can be used as a feature to coordinate a monorepo containing multiple applications and not just multiple packages. For example I might have the structure:

.pnpmfile.cjs
package.json
pnpm-lock.yaml
pnpm-workspace.yaml
apps
├── app-a
          ├── package.json
├── app-b
          ├── package.json
 packages
├── package-a
          ├── package.json
├── package-b
          ├── package.json

and my pnpm-workspace.yaml looks like this

packages:
  - apps/**
  - packages/**

It seems advantageous in a large monorepo where apps are owned by different teams that dependency overrides could be specified at the app workspace level. For example if app-a and app-b both depended upon lib-a which is consumed as a workspace and not as a published package, if lib-a has react as a dependency, and app-a wants to upgrade to react@18 whereas app-b wants to stay on react@17 it would seem useful to be able to specify app workspace level overrides rather than global overrides at the root package.json level. I’m wondering what you would suggest as best practice here @zkochan if it would be better for lib-a to specify react as a peerDependency or if there is a way to specify package versions for specific workspaces using something like the PNPM hooks?

Seems like one potential solution in yarn for this is no-hoist

+18

dtothefp on Apr 19, 2023

Note that overrides seem to be ignored in workspaces. If you use workspaces, what will help is if you move overrides to the root package.json (possibly create empty one first).

+17

IlyaSemenov on Feb 18, 2022

您好，我已收到您的邮件，我会尽快给您回复。

lanmch on Jun 23, 2022

Any update/solution found?

413n on May 6, 2022

您好，我已收到您的邮件，我会尽快给您回复。

lanmch on Mar 28, 2022

您好，我已收到您的邮件，我会尽快给您回复。

lanmch on Aug 4, 2022

Hello, I believe I’m also running into this issue. (Or quite possibly I’m misunderstanding how overrides work)

I’m seeing the override set in both package.json and pnpm-lock.yaml after running pnpm audit --fix, and pnpm install, however the version of the dependency in the lockfile still shows the old version (in this case minimist 1.2.5), but the override is asking for >=1.2.6. A few other dependencies have the same problem.

Running pnpm audit shows no vulns tho.

TLDR: it seems overrides are not being applied to pnpm-lock.yaml

CobyPear on Mar 28, 2022

您好，我已收到您的邮件，我会尽快给您回复。

lanmch on Jul 7, 2023

pnpm --version
7.8.0

root folder package.json

  "pnpm": {
        "overrides": {
            "terser@>=5.0.0 <5.14.2": ">=5.14.2"
        }
    }

pnpm-lock.yaml after pnpm install

overrides:
  terser@>=5.0.0 <5.14.2: '>=5.14.2'

  /@nrwl/node/14.1.9_rxth3vu7uqsqsbv3sw45o5zan4:
    resolution: {integrity: sha512-p3TxPZxMTCAF1P4JT/THWwqY3q8f/Pfpy0iAK9bjQ/y8sf89yuEQGPIL+ZdFbhB9tSPGB+Z/KArtyOBrcvBUVA==}
    dependencies:
      '@nrwl/devkit': 14.1.9_nx@14.1.9
      '@nrwl/jest': 14.1.9_zyjyql4vrws2e3dlcmculsfl64
      '@nrwl/js': 14.1.9_fsqoc4b7rvscsk67gqchq7wfwy
      '@nrwl/linter': 14.1.9_do52n5atlgggvlg34rjob6rbam
      '@nrwl/workspace': 14.1.9_fiqdsaqwobgw6ewevb2b22olhq
      chalk: 4.1.0
      copy-webpack-plugin: 9.1.0_webpack@5.72.1
      enhanced-resolve: 5.9.3
      fork-ts-checker-webpack-plugin: 6.2.10_emg3wltpsrflttkk66ka66uori
      fs-extra: 10.1.0
      glob: 7.1.4
      license-webpack-plugin: 4.0.2_webpack@5.72.1
      rxjs: 6.6.7
      rxjs-for-await: 0.0.2_rxjs@6.6.7
      source-map-support: 0.5.19
      terser-webpack-plugin: 5.3.1_webpack@5.72.1
      tree-kill: 1.2.2
      ts-loader: 9.3.0_fz3vkvdtk4wrv742s4dvevasza
      ts-node: 9.1.1_typescript@4.6.2
      tsconfig-paths: 3.14.1
      tsconfig-paths-webpack-plugin: 3.5.2
      tslib: 2.3.0
      webpack: 5.72.1
      webpack-merge: 5.8.0
      webpack-node-externals: 3.0.0
    transitivePeerDependencies:
      - '@swc/core'
      - bufferutil
      - canvas
      - esbuild
      - eslint
      - node-notifier
      - nx
      - prettier
      - supports-color
      - typescript
      - uglify-js
      - utf-8-validate
      - vue-template-compiler
      - webpack-cli
    dev: true


  /terser/5.13.1:
    resolution: {integrity: sha512-hn4WKOfwnwbYfe48NgrQjqNOH9jzLqRcIfbYytOXCOv46LBfWr9bDS17MQqOi+BWGD0sJK3Sj5NC/gJjiojaoA==}
    engines: {node: '>=10'}
    dependencies:
      acorn: 8.7.1
      commander: 2.20.3
      source-map: 0.8.0-beta.0
      source-map-support: 0.5.21
    dev: true

still broken for workspaces

morriswinkler on Aug 4, 2022