Open bradzacher opened 2 months ago
We discovered this because this is causing one of our tests to break.
We have an integration test with the following package.json: https://github.com/typescript-eslint/typescript-eslint/blob/146179334b576141aa3d4179866bb63680adde85/packages/integration-tests/fixtures/flat-config-types-%40types__eslint-v8/package.json
It is intended to allow us to test community plugins to ensure that we don't get unexpected type errors. But this bug is causing its own unexpected type error -- causing our tests to fail https://github.com/typescript-eslint/typescript-eslint/actions/runs/10284026780/job/28461467116
Indeed, I can repro, and I found where it comes from.
For context, if you write the TS-compatible package my-lib
which has a peer dependency on, say, lodash
, it implies you must also have a peer dependency on @types/lodash
(otherwise your .d.ts
file that would import ... from 'lodash'
wouldn't work). Unfortunately library authors not always respect this as they're concerned of adding TypeScript-specific dependencies. To workaround that, Yarn automatically adds a @types
optional peer dependency for every non-@types
peer dependency.
The code checks whether an @types
peer dependency already exists (so as not to overwrite it), but in the case of @stylistic/eslint-plugin
the @types
package is instead provided through a regular dependency. It's quite unusual, and we forgot to add a check for this particular case. As a result the automatic peer dependency on @types/eslint
is added, and overrides the regular dependency (peer dependency + regular dependency is interpreted as "use the peer dependency if provided by the parent, otherwise use the regular dependency").
I'll make a fix later today.
Self-service
Describe the bug
Expected:
@stylistic/eslint-plugin
depends on@types/eslint@9.6.0
node_modules/@stylistic/eslint-plugin/node_modules/@types/eslint
containing@types/eslint@9.6.0
Actual:
To reproduce
package.json
.yarnrc.yml
Environment
Additional context
Looking at the lockfile I can see:
and
So yarn knows about the dependency and lists it as expected -- however it's just not installing it.
yarn.lock