[turborepo] yarn runs two different versions of eslint

[cullylarson]

trafficstars

What version of Turborepo are you using?

1.6.3

What package manager are you using / does the bug impact?

Yarn v1

What operating system are you using?

Mac

Describe the Bug

I have a few packages that depend on eslint. Most of them use eslint v8.26.0. One of them uses v6.8.0. Let's say:

• packageA: eslint v8.26.0
• packageB: eslint v8.26.0
• packageC: eslint v6.8.0

If I cd into packageA and run yarn eslint -v, the output is v6.8.0. However, if I add a package.json script to packageA ("lint": "eslint -v") and run yarn lint, the output is v8.26.0.

If I cd into the root node_modules/.bin and ls -al eslint, it links to the eslint in packageC. Strangely if I look at the version of node_modules/eslint in the root folder, it's v8.26.0.

It seems like if I run yarn eslint -v inside packageA, it should use the version of eslint in defined in packageA's package.json, not the root node_modules/.bin/eslint.

Also, why does packageC's eslint get linked in the root .bin, but the root eslint package is v8.26.0?

Expected Behavior

Running yarn <bin command> in a package's folder should run the version of the command defined in the package's own package.json, not some version from another package.

To Reproduce

I imagine if you created these three folders, with the defined versions above, it would reproduce the issue.

Reproduction Repo

No response

[petermekhaeil]

I would imagine this is the behaviour of your chosen package manager, rather than Turborepo.

Do you need multiple versions of eslint? A recommendation is to have only one version of eslint installed in the root. Each package can have its own eslint config. When you run lint it will find the closest eslint package which is in the root.

[nathanhammond]

Indeed, this is not a Turborepo bug. We do not contribute to this in any way. The specific behavior for where things are installed are based upon the package manager's behavior.

For additional debugging you can look into yarn ls which is aware of their resolution algorithm.

Further, you're using Yarn v1, which is EOL, so any actual issues will remain unaddressed. We would recommend exploring migration to pnpm.

I'm closing this as it's not a Turborepo issue, but conversation can of course continue here.

[cullylarson]

Ah, that makes sense. Thank you for your help @petermekhaeil and @nathanhammond. I appreciate it.

EDIT: Upgrading to yarn 3 resolved this issue.