-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Improve monorepo support for no-extraneous-dependencies rule #1016
Improve monorepo support for no-extraneous-dependencies rule #1016
Conversation
7e6c720
to
815abf0
Compare
7c150b2
to
980b087
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I'm still not sure this is a useful feature. Deps shouldn't be resolved from outside of a subpackage in a lerna-style monorepo.
|
||
if (!packageContent) { | ||
return null | ||
if (Object.prototype.hasOwnProperty.call(context.settings, 'import/paths')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's use the has
module for this.
@ljharb It's a documented approach in the readme for lerna: https://github.com/lerna/lerna/blob/master/README.md#common-devdependencies Furthermore, node itself inherently resolves dependencies from parent When you have... let's say 10-30 packages you're managing in a monorepo - then sure, not a big deal to manage dev deps on a per package basis. However, at my job for example we manage a monorepo with well over 100 packages. In this scenario; the task of managing dev deps for this volume of packages quickly outgrows what's practical. While I agree that this is up for debate on a best practices basis - I'm not sure how valueable it is to have this flexibility prevented at the level of an eslint plugin. Personally, I've found that hoisting all of these dev deps to the root of monorepo brings a significant benefit and gained sanity. |
Thank you for this PR @hulkish -- this has been a pain point for us so far. Hopefully this gets merged and released 🙏 |
@ljharb hoping this can land.. is there anything I can improve to allow it? |
Thanks for PR. We also reach this problem in monorepo. There even extra plugin in the wild https://github.com/Dreamscapes/eslint-import-resolver-lerna which partially solves it. |
I've also run into this issue. I would love to see this merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why add a new top-level setting (import/paths
) instead of expanding the existing packageDir
rule option to be either a string or a list of strings?
@benmosher hmm, sure - but, how would you configure |
thanks for the PR reference @dmk255! other relevant reading: |
I just turn off ---
extends: airbnb
root: true
overrides:
- files: "**/*{-,.}{test,stories}.js"
rules:
# devDependencies are all in the root
import/no-extraneous-dependencies: off |
Seems like this is just going to be an endless debate of correctness vs practicality. I'll just fork and publish this as a different package. |
You’re welcome to do that, but this should stay open. |
77d4423
to
2780d7c
Compare
@benmosher I actually had this work changed to use I don't care if we use my pr or yours, tbh. @ljharb Whichever you guys think is best. |
Just wondering... what's holding this up? What needs to be done to get this merged? |
busy week at work, but it's top of my queue for this project when I get time |
@benmosher thanks! |
@hulkish fyi, merged mine because I had fixed up and added a few more tests, LMK if I missed anything though |
Solves #935