[BUG] Overrides are not applied correctly with workspaces

[nlf]

Is there an existing issue for this?

• [X] I have searched the existing issues

This issue exists in the latest npm version

• [X] I am using the latest npm

Current Behavior

When overrides are applied to a project with workspaces, they do not consistently apply.

Expected Behavior

Overrides should apply regardless of the usage of workspaces.

Steps To Reproduce

git clone https://github.com/defencedigital/mod-uk-design-system.git
cd mod-uk-design-system
git switch spike/npm-v8-2
npm install
npm ls trim

trim should be at version 0.0.3, while it is stuck at 0.0.1

Environment

• npm: 8.7.0
• Node.js: 16.15.0
• OS Name: OSX Monterey
• System Model Name: 13" M1 MacBook Pro
• npm config:

; copy and paste output from `npm config ls` here

[villelahdenvuo]

I have the same issue with some serverless lambdas. I added an override to the root package.json for aws-sdk, but it still installs the incorrect version:

➜  mygrano-serverless ✗ npm ls aws-sdk
@grano/[email protected] /repot/mygrano-serverless
├─┬ @grano/[email protected] -> ./antivirus
│ └─┬ @grano/[email protected]
│   └── [email protected] deduped
├─┬ @grano/[email protected] -> ./serverless-utils
│ └── [email protected] deduped
├─┬ @grano/[email protected] -> ./ses
│ └─┬ [email protected]
│   └── [email protected] invalid: "^2.1222.0" from node_modules/aws-lambda-ses-forwarder
├─┬ @types/[email protected]
│ └── [email protected] deduped
├── [email protected]
└─┬ [email protected]
  └── [email protected] deduped

npm ERR! code ELSPROBLEMS
npm ERR! invalid: [email protected] /repot/mygrano-serverless/node_modules/aws-lambda-ses-forwarder/node_modules/aws-sdk

[zanemcca]

@villelahdenvuo did you find a solution for this. Our whole build seems to be broken and overrides are the only solution available so any help is very welcome.

[villelahdenvuo]

@zanemcca Nope, I ended up forking the aws-lambda-ses-forwarder so that I can add the ^ to the aws-sdk version, overrides still don't seem to work.

[zanemcca]

I have also tried to fork my dependency and change the versions to use ^. The really annoying thing is that even that solution is not working since there is a newer version of the package available so my forked package is installing the latest version instead of the fixed version I need which is one minor release earlier.

I would really like to see this important feature work as documented. Is there any way someone can take a look at this?

The only workaround right now is to fork the dependency that contains the bad version and update the version to an exact package version that matches what you need. Not only is this a ton of work for developers in the easiest of cases but it is likely to be much worse if the offending package version is deeply nested.

[daksh-sagar]

facing same issue with my project, is there a fix planned for this ?

[jonaskello]

Just migrated to npm from yarn workspace were we used resolutions and everything worked. Is there no way in npm to override a dependency for the whole workspace similar to what yarn does?

EDIT: Found #4517 which explains some parts

[sanioka]

Still actual.

npm workspaces and npm overrides don't work together correctly?

./package.json

	"workspaces": [
		"./ui-components",
		"./apps/*",
		"./packages/*"
	],
	"overrides": {
                "@company/ui-components": {
		        "material-ui": {
			        "react": "$react",
				"react-dom": "$react-dom"
			},
			"react-table-6": {
				"react": "$react",
				"react-dom": "$react-dom"
			}
		}
	}

My workaround:

./package.json

	"workspaces": [
		"./ui-components",
		"./apps/*",
		"./packages/*"
	],
	"dependencies": {
		"react": "17.0.2",
		"react-dom": "17.0.2",
		"react-table-6": "^6.11.0",
		"material-ui": "^0.19.0"
	},
	"overrides": {
		"material-ui": {
			"react": "$react",
			"react-dom": "$react-dom"
		},
		"react-table-6": {
			"react": "$react",
			"react-dom": "$react-dom"
		}
	}

[JaneJeon]

This is actually blocking monorepo adoption with npm. This is kind of a serious issue, esp. since the overrides means we can't manually pin a peer dep's version, and could lead to security issues.

[JaneJeon]

And even with the override on the root package, it still doesn't work, so I'm not sure how the person above saying #4517 "fixes it" got it to work.

[grundius]

I can confirm that it still does not work on Node 20 with npm 9.8.1. I have the overrides in the root package as https://github.com/npm/cli/issues/4517 indicates. As mentioned by @JaneJeon this blocks monorepo adoption.

EDIT: A "solution that works" is using npm i --legacy-peer-deps. Of course, that puts ensuring that you have the correct peer deps installed back in the hands of the programmer, but it might be adequate.

[pavelkornev]

Seems like it's time to use pnpm...

[thorsent]

Not certain but I think I'm probably having the same issue. What I wanted to do was to override a package in my monorepo to point to a github repo. This is so that we can work against development branches of our internal dependencies without having to publish them to npm or use npm link. I tried, and tried, and tried, but could not get the override to be respected. In fact, I couldn't get the github repo to be respected at all unless all instances of this dependency in all package.jsons were also changed to point to the github repo.

But, my overrides for react 18 work fine (thank God!) so my experience therefore is also some sort of situational behavior.

I'll have to revert to using npm link (P.S. Take a look at yarn link and use of portals. It's more transparent and a lot less friction than npm link.)

[maksnester]

10.7.0 overrides still do not work correctly

[nukeop]

I've been maintaining a monorepo for quite some now, using lerna earlier, now npm workspaces, and now I need to override a single dependency of a single package - only to find out that I can't, without using patch-package. Are there any workarounds?

[zanemcca]

@isaacs Can someone on the main team take a look at this. It feels like a serious limitation of the mono-repo abilities. This is something that shows up very easily for any applications that use monorepos at scale and it has been a thorn in our side for a few years at this point.

[nukeop]

For anyone reading this later, I applied a workaround in the end - by directly copying the package whose dependencies I could not override to my project, then installing whatever versions of dependencies I wanted. It sure is dumb, but at least it works. Might not work for larger libraries.

[cjnoname]

We got the same problem

[iharshks]

This worked for me: I have to override formidable to 3.5.1 version. And my dependency tree for that looked like:

@loopback/[email protected]
    └─┬ [email protected]
      └─┬ [email protected]
        └── [email protected]

Individual package.json override did not worked. Root override did work but it was causing other issues due to package mismatch. So I did this, in root package instead:

  "overrides": {
    "superagent": {
      "formidable": "^3.5.1"
    }
  },

Which results in:

@loopback/[email protected]
    └─┬ [email protected]
      └─┬ [email protected] overridden
        └── [email protected] overridden

[gavmck]

I had to manually install the package in the root as well as apply the override as above