-
Notifications
You must be signed in to change notification settings - Fork 9
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
getDependencies
called twice
#665
Comments
Yea Im also not terribly happy with that either and actually believe passing The third proposed solution wouldn't work because then you couldn't pass multiple react overrides. probably not a scenario that happens a lot but it would limit capabilities of overrides. I do like the last approach the most, but would need to think about ways to make it compatible with |
Thanks for the info, this flat config looks very, very promising! Much simplification ahead 🎉 |
While I'm in the linting head-space, I might as well... 😂
Looking at the typical usage example I suggested for the README in #622 (comment):
Something that bothers me (very slightly) with this is that
getDependencies
gets called twice: once explicitly to pass tocreateReactOverride
, and once internally bycreateConfig
.I feel like this is a potential source of bug, for instance if you pass a different
cwd
tocreateConfig
than togetDependencies
, or ifgetDependencies()
is located in a file inside a sub-directory (like on a monorepo) and you pass the file's__dirname
to it... The two calls may end up looking at two differentpackage.json
files.Here are some ideas to fix this:
createConfig
could accept adependencies
object (could be confusing)createConfig
could be replaced with a newcreateConfigFromDependencies
function, which would be called internally bycreateConfig
--createConfig
would still exist for users who don't need to configure any overrides (this could also be confusing)createConfig
could accept anoverrides
object instead of an array and it would then be up tocreateConfig
to create the overrides - e.g.overrides: { react: { rules: {... } } }
(but this prevents customising the dependencies if needed)createConfig
could optionally accept functions as overrides that receive the dependencies as arguments - e.g.overrides: [(dependencies) => createReactOverride({ ...dependencies })]
(best compromise, I think)The text was updated successfully, but these errors were encountered: