chore: upgrade eslint #134
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- upgrade eslint and all deps to latest - move to new flat config - get to zero warning/error linting runs
✅ Deploy Preview for zmk-studio ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
also adds es5 for dangling commas as it seems to be the least destructive
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What it does
Does what it says on the tin!
...Slightly more detail
The Eslint v9 migration is fairly straightforward, albeit less bothersome now that plugin authors have had a change to catch up to the new flat config.
I tended to prefer the old files, they seemed a lot cleaner, but moving to the JS config allows for some nice LSP suggestion so it's about half and half.
NPM Script Changes
js/ts(x?)files, and this is now sourced from the config file (score one for "locality of behavior"!)report-unused-directivesis now the default behavior so I've removed that as wellmax-warningsto a config, so there's one CLI flag left, but otherwise I think this cleans it up nicelyWhat's with all the turned off rules??
So. This will be slightly divisive depending on which side of things you fall on: I've turned off all rules currently causing warnings and errors. The reasoning behind this is that from a zero warning/error you can add a linting check to the pipeline (just in any of your GH actions, or creating it's own). IMO with OSS, warnings and errors tanking pipelines can help keep code style dialed in.
I wasn't sure if there were reasons some of them hadn't been ignored before. For example I know coming from Rust using
letjust makes sense, butprefer-constwasn't turned off causing 84 errors across the codebase, all but 1 are auto-fixable though.Some of these could also make for nice "first issues" for those looking to contribute but unsure how. Basically - find an ignored rule, turn it off, and see if you can fix all the issues, etc.
Others will need special attention: exhaustive deps in react-hooks is crucial for preventing bugs due to unexpected effects calls, but take much more effort to make sure nothing has been botched when updating them. (Suggested reading for whoever takes that on)
There are a few that I'll go ahead and update tomorrow since they're tiny or very clean. But I wanted to scope each to it's own commit, and I'll circle back on those and push them up tomorrow.