Skip to content
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

fix: most eslint rules have moved to @stylistic #1507

Merged
merged 1 commit into from
Dec 18, 2024

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Dec 18, 2024

ESLint has moved most of it's style-related linter rules to a namespace called @stylistic.

Update our built-in linter rules to reference those rules in the new package name, and change the public interface to accept arbitrary strings, instead of an enum from a specific set of rules.

ESLint has moved most of it's style-related linter rules to a namespace
called `@stylistic`.

Update our built-in linter rules to reference those rules in the new
package name, and change the public interface to accept arbitrary
strings, instead of an enum from a specific set of rules.
Copy link

@aws-cdk/aws-service-spec: No model change detected

@@ -16,7 +16,7 @@ describe('statements', () => {
fn.addBody(code.comment('test comment'));

expect(renderer.render(scope)).toMatchInlineSnapshot(`
"/* eslint-disable prettier/prettier, max-len */
"/* eslint-disable prettier/prettier, @stylistic/max-len */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean though that consumers who don't have the stylistic plugin won't have this suppression now? is that a thing we care about?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't care about it, frankly.

But given that referencing non-existing rules in an eslint-disable directive is an error, we probably shouldn't have been putting linter rules in there to begin with.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah seems fragile. Ok, lets see if this causes any pain

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 I think the better pattern is to run a formatter/linter over the code afterwards. Most of the rule validations should be auto-fixable anyway.

@aws-cdk-automation aws-cdk-automation added this pull request to the merge queue Dec 18, 2024
Merged via the queue into main with commit 76fa496 Dec 18, 2024
9 checks passed
@aws-cdk-automation aws-cdk-automation deleted the huijbers/eslint-stylistic branch December 18, 2024 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants