You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 20, 2024. It is now read-only.
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):
constdependencies=getDependencies();constcustomReactOverride=createReactOverride({
...dependencies,rules: {/* some rule overrides */}});module.exports=createConfig({rules: {/* some rule overrides */},overrides: [customReactOverride],});
Something that bothers me (very slightly) with this is that getDependencies gets called twice: once explicitly to pass to createReactOverride, and once internally by createConfig.
I feel like this is a potential source of bug, for instance if you pass a different cwd to createConfig than to getDependencies, or if getDependencies() 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 different package.json files.
Here are some ideas to fix this:
createConfig could accept a dependencies object (could be confusing)
createConfig could be replaced with a new createConfigFromDependencies function, which would be called internally by createConfig -- createConfig would still exist for users who don't need to configure any overrides (this could also be confusing)
createConfig could accept an overrides object instead of an array and it would then be up to createConfig 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:
Yea Im also not terribly happy with that either and actually believe passing dependencies to createConfig would be the simplest solution for everyone involved.
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 generateStandalone. Might introduce it in v5 with ESLint's FlatConfig once its out (probably v9 on their end).
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: