-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usage in a monorepo #58
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using this in a monorepo, where 99% of the development deps are declared in the root workspace, including ESLint and this config. If I go and run ESLint in one of the sub-workspaces (with
yarn run -T eslint
), I get the following:I tried aliasing
hasAnyDep
tomoduleNotAvailable
, but that has its own fatal side effects. So I went here:eslint-config-auto/lib/utils.js
Lines 12 to 15 in 0eae8ba
And prepended
process.cwd()
withprocess.env.npm_package_json ??
, and everything started to work as expected. It's available in npm 7+ and Yarn 3.2.2+. Why did it help? Because-T
inyarn run -T
means--top-level
, so it executes the ESLint binary from the root of the monorepo, andnpm_package_json
resolves to thepackage.json
which "owns" that binary. I'm not sure how npm handlesrun
commands, but I know that they do hoisting too, so I imagine the behavior should be the same.This assumes that a project-level
eslint
is used, not a system-level one, and thateslint-config-auto
is installed alongsideeslint
, not in a sub-workspace, along with every single dependency thateslint-config-auto
might look for.The above is a quick fix that will make monorepos work now, but it's not a complete solution. For example,
eslint-config-auto
might be installed in the root, and one of the packages might depend onreact
, and even with this fix it will not pick up React, becausehasAnyDep
will look only in the rootpackage.json
.The real solution is to find the root of the monorepo, and then go down the tree, merging all dependencies. Note that workspaces can be nested infinitely, it's not just one level. Unfortunately, I wasn't able to find any existing package that does this correctly (they all go down only one level). But I think a good enough version could be to just do a
find-up
of eitheryarn.lock
,pnpm-lock.yaml
orpackage-lock.json
. Here's how Yarn does it, and pnpm. If no lock file is found then fall back to the current behavior.Or could use a flawed existing library (ignore the "yarn" in its name, it works for any package manager). It's easy and it covers 99.(9)% of use cases, I haven't seen a 3+ level workspace yet.
Thoughts?
The text was updated successfully, but these errors were encountered: