Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Bump ESLint and related dependencies #254
Bump ESLint and related dependencies #254
Changes from 1 commit
0cf5f2d
da14e6a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
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.
I know that the
createConfig
function was already released and published. However, I can't help but wonder whether it will, in the long run, make our ESLint configurations unnecessarily difficult to understand and debug. ESLint already provides recommendations for combining configuration objects (and exporting configs so they can be properly combined), and these are what plugins likeeslint-plugin-import-x
,eslint-plugin-jsdoc
, andeslint-plugin-prettier
follow in switching to the flat config format.Upon switching to ESLint 9, I would expect the config file to look like the following:
While using
map
is a bit more verbose, I think it's very clear that we are creating objects to add to the flat array that we are ultimately exporting. I am not sure that is so clear with thecreateConfig
utility.What are your thoughts on this? I believe there are also further improvements we can make to the ESLint packages so that we can streamline this file, but I will leave that for a future comment.
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.
I considered this, and after talking about it with @rekmarks, we decided to create a simple util function that handles it for you. I don't think it changes so much in understandability of the config, and because it's less verbose, I feel like it's easier to read.
The function is based on
typescript-eslint
's config function, so it's not like we're the only ones doing this.This gets very verbose if you actually want to override some rules or other settings. For example:
Of course we could use some deep merge function, but that's essentially what
createConfig
does, but easier.I don't think this will be any more of a problem with
createConfig
compared tomap
and spreading the config. Either way it's quite easy to log the object to see what's going on.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.
I find ESLint's recommendations—i.e. the
map()
syntax—to be completely unreadable, and much prefer the utility function. In fact, during the migration of our monorepo to ESLint 9, not using thecreateConfig()
function was more difficult and bug-prone, as opposed to the reverse.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.
Thanks for the replies. That helps me understand the reasoning better.
I do wish it were more obvious that an object with
extends
actually represents multiple objects; that seems to diverge from the central ideas behind flat config. But, if it succeeds in helping us write the config files we want to write, then perhaps it doesn't matter.