-
Notifications
You must be signed in to change notification settings - Fork 48
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
chore(eslint)!: migrate all eslint configs to v9 #974
Conversation
BREAKING CHANGE: This removes v8 from being supported and moves to flat config
BREAKING CHANGE: This removes eslint@v8 from support and moves to flat config
BREAKING CHANGE: This removes eslint@v8 from support and moves to flat config
BREAKING CHANGE: This removes eslint@v8 from support and moves to flat config
.changeset/blue-rats-notice.md
Outdated
|
||
chore(eslint)!: migrate all eslint configs to eslint@v9 | ||
|
||
BREAKING CHANGE: removes v8 support and transistions configs to flat config |
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.
Might want to explicitly call out that these are now type:module
instead of the previous cjs
format.
There's 3 (normie), 9 (react) projects still depending on this package internally, but I agree, that it's not enough to warrent keeping this configuration around. |
Summary
This PR upgrades all eslint configs to use v9. I know that in eslint >= 8.23 flat config is supported however, feasibly I do not want to make these config semi backwards. Better to do the breaking change now and just keep a v8 branch for patch/bug updates. I've also removed the
flow
based configs. I know Flow is still around and utilized but we no longer support its use internally at GoDaddy. If there are hard opinions to this I do not mind bringing them back in this PR and migrating them to v9. I've also remove the CLI portion of these libraries as we should only be using theeslint
binary directly.The biggest question here is should be using all the custom rules we have established here or should we be leveraging the industry standards. A lot of our rules are outdated and often times conflicted with a lot of
recommended
configs and plugins. IMHO we should probably lean that way and allow the consumer to decide if they want to modify the rules they want to have. The config should mostly provide the additional configs and plugins (such as the react, mocha, node, ect.) doing this keep their configs small but still allows for flexibility.Changeset
Test Plan
These have been tested locally to make