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

Upgrade to ESLint 9 #24

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

miyasudokoro
Copy link

  1. Migrated to ESLint 9 configurations
  2. Updated all deprecated rules, including those that moved to @stylistic/js
  3. Implemented TODO: do not use the built version to check the code from test/fixtures/.eslintrc.js (deleted)
  4. Fixed the .gitattributes to actually enforce LF

commit d06d40a
Merge: a462335 ebced6b
Author: Devin McIntyre <k.devin.mcintyre@gmail.com>
Date:   Fri Oct 18 14:09:03 2024 -0600

    Merge branch 'update-to-eslint-9' of https://github.com/miyasudokoro/eslint-config-jquery into update-to-eslint-9

commit a462335
Author: Devin McIntyre <devin.mcintyre@ricoh-usa.com>
Date:   Fri Oct 18 13:51:44 2024 -0600

    update to ESLint 9

commit ebced6b
Author: Devin McIntyre <devin.mcintyre@ricoh-usa.com>
Date:   Fri Oct 18 13:51:44 2024 -0600

    update to ESLint 9
Migrated to ESLint 9 configurations

Updated all deprecated rules, including those that moved to @stylistic/js

Implemented TODO: do not use the built version to check the code from test/fixtures/.eslintrc.js (deleted)

Fixed the .gitattributes to actually enforce LF
@miyasudokoro
Copy link
Author

Note: JQuery 3.7.1 has an invalid eslint ignore statement that makes the tests fail for this project in ESLint 9, but that must be
fixed in JQuery itself. The file attributes/prop.js has two "eslint ignore" statements for the same rule, which is no longer allowed. These should probably be changed to "eslint ignore next line" statements.

...\src\attributes\prop.js
113:4 error Rule "no-unused-expressions" is already configured by another configuration comment in the preceding code. This configuration is ignored

...\src\selector.js
2113:2 warning Unused eslint-enable directive (no matching eslint-disable directives were found)

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, this sounds useful! I added a few remarks.

Comment on lines +16 to +20
export default [
// ... any other configurations,
jquery,
// ... any other configurations
];
Copy link
Member

Choose a reason for hiding this comment

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

@timmywil that's probably a good idea; the way we use the config is too "picky"; we should perhaps just apply it on a global level and then provide overrides in separate blocks.

Copy link
Author

Choose a reason for hiding this comment

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

At my workplace, we use eslint-config-jquery as one of the base sets of rules, then override a handful of them that we disagree with. It looks like this:

const base = {
    plugins: {
        '@stylistic/js': stylistic,
        jsdoc
    },
    rules: {
        'no-unused-expressions': [
            'error',
            {
                'allowShortCircuit': true
            }
        ],
        '@stylistic/js/quotes': [
            'error',
            'single',
            {
                'avoidEscape': true,
                'allowTemplateLiterals': true
            }
        ],
        '@stylistic/js/linebreak-style': 'off',
        'jsdoc/tag-lines': 0,
        'jsdoc/no-defaults': 0
..... more stuff here .....
};

..... more stuff here ....

export default [
    ignores, // note: this must go first for it to be applied globally
    js.configs.recommended,
    jquery,
    jsdoc.configs[ 'flat/recommended-typescript-flavor' ],
    base,
    overrideForUnitTests  // this has a "files" selector for unit tests and exempts them from jsdoc and max-len
];

@mgol mgol requested a review from timmywil October 18, 2024 23:31
@mgol
Copy link
Member

mgol commented Oct 18, 2024

Note: JQuery 3.7.1 has an invalid eslint ignore statement that makes the tests fail for this project in ESLint 9

Don't worry about jQuery 3.7.1, we didn't have ESLint 9 or the flat config in the repo back then. The latest state of the 3.x-stable branch is the code for the next 3.x release and it doesn't have the comments you mentioned.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

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

A few more comments; thanks for the changes so far!

Please re-request review once every comment is addressed; I'll do a final review pass then, including me trying it locally (I don't have enough time at the moment).

@miyasudokoro miyasudokoro requested a review from mgol October 25, 2024 19:20
@mgol
Copy link
Member

mgol commented Nov 21, 2024

@miyasudokoro Sorry for the delay, I just wanted to give you a status update. We are focused on releasing jQuery 4.0.0 now, I'm not sure if I'll be able to look at this PR finally before we do at least the RC release - and I want to test this on a few jQuery repositories.

Also, while in jQuery on the 3.x-stable branch we use ESLint 9, on main we use ESLint 8 due to incompatibility of eslint-plugin-import with ESLint 9 & the flat config. There's active work on that done at the moment, so I hope we'll be able to upgrade soon. I'd like to merge the PR only after that happens.

@mgol
Copy link
Member

mgol commented Nov 21, 2024

BTW, the build is failing. Please update the Node.js version used in CI to 22, that should help.

@miyasudokoro
Copy link
Author

@mgol Thank you for the status updates. I am not very familiar with Github workflows, but I attempted to upgrade the Node.js version.

@mgol
Copy link
Member

mgol commented Dec 2, 2024

Thanks for the Node update. The CI now fails on a different thing, can you have a look?

You don't have to wait for me approving the run, BTW - CI is mostly just doing npm install && npm test - or npm it for short - you can run it locally to find issues independently.

@miyasudokoro
Copy link
Author

@mgol Those CI errors are the two things I noted in my Oct 18 comment. The tests won't pass until we're testing a jquery version that has removed those two invalid lines. I vaguely remember going to make a branch of jquery to fix them but seeing that they were already fixed by somebody else's branch, so I think this will resolve itself via the jquery 4.0.0 release.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

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

@miyasudokoro

Those CI errors are the two things I noted in my Oct 18 comment. The tests won't pass until we're testing a jquery version that has removed those two invalid lines.

Maybe it'd be better to change the approach here. Special handling of this PR is fine since it changes so much but what if we want to introduce changes to the rules later? We would have to first fix them in jQuery source without relying on this plugin to provide them, then wait for the release and only then update them here. jQuery sometimes has long breaks between releases, this seems like too much of a churn.

I'd propose the following:

  1. Keep test/fixtures/jquery.js in the repo.
  2. Add an npm script that copies jQuery from devDependencies to test/fixtures/jquery.js. This task should require being invoked manually, it should not be run in CI.

Then, if we want to introduce changes to some rules, we can patch the fixture in place and release the update without waiting for the next jQuery release.

Thoughts?

"devDependencies": {
"eslint": "^8.5.0"
"eslint": "^9.12.0",
"jquery": "latest"
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer to provide a concrete version here, even without the ^ range. This is because code style changes are not breaking and may happen even in patch releases, breaking the build.

@mgol
Copy link
Member

mgol commented Mar 3, 2025

@miyasudokoro Hey, are you interested in finishing this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants