Upstream will be allowed to update with breaking changes due to ESLint v9

[MichaelDeBoey]

As @ljharb mentioned on Discord, that he's going to do a once-in-a-decade breaking change now that ESLint v9 and flat config are shipped.
He also confirmed that this would also be for eslint-plugin-import.

Don't know what that means for this plugin, but I bet this could mean that we could at least rebase our fork to a newer version 🤔

[MichaelDeBoey]

FYI I already opened up the following PRs upstream:

• feat: drop Node 4, 6, 8, 10, 12, 14 & 16 support import-js/eslint-plugin-import#3091
• feat: drop ESLint v2, v3, v4, v5, v6 & v7 support import-js/eslint-plugin-import#3092
• feat: remove dependencies for Node built-ins import-js/eslint-plugin-import#3093

[SukkaW]

Don't know what that means for this plugin, but I bet this could mean that we could at least rebase our fork to a newer version 🤔

We don't have to, and we can't anyway.

We have completely rewritten our project in TypeScript. We have already embraced utilities from the @typescript-eslint project, we have already migrated all toolchains (test framework to jest, compiler from babel to tsc), and we have already been targeting Node.js 18 for months, and we are planning to introduce new APIs and new resolver design.

In short, we have already completely deviated from eslint-plugin-import.

[MichaelDeBoey]

@SukkaW If I'm not mistaken, @ljharb is open to PRs to upgrade toolchains + new APIs as well

[SukkaW]

@SukkaW If I'm not mistaken, @ljharb is open to PRs to upgrade toolchains + new APIs as well

Nah, he won't agree that eslint-plugin-import to be rewritten in TypeScript in any foreseeable future.

[ljharb]

it must be fun to be so aggressively wrong all the time :-p

[SukkaW]

is open to PRs to upgrade toolchains + new APIs as well

• feature request: add ignore options for import/no-duplicates import-js/eslint-plugin-import#1479
• [feature] make context.getCwd() available in resolver import-js/eslint-plugin-import#2108
• when using typescript recommended config it should allow for imports of js equivialent import-js/eslint-plugin-import#2111

All those proposals remain opened and none of them are resolved in eslint-plugin-import, that's the reason behind the birth of eslint-plugin-import-x.

Also, I really don't want to remind anyone about the tsconfig-paths saga again.

https://github.com/import-js/eslint-plugin-import/issues?q=is%3Aissue%20tsconfig-paths%20state%3Aclosed

but I bet this could mean that we could at least rebase our fork to a newer version 🤔

When I said "we can't anyway", I mean the eslint-plugin-import-x has changed the entire codebase since the fork. Here is the diff:

import-js/eslint-plugin-import@main...un-ts:eslint-plugin-import-x:master

If you are willing to resolve more than thousands of git conflictions and help us rebase, please do, I am more than happy to accept PRs from you!

it must be fun to be so aggressively wrong all the time :-p

You didn't even comment on @MichaelDeBoey's mentioned PRs with "LGTM, waiting for the major release schedule". And all his PR towards eslint-plugin-jsx-a11y remains unreleased, and you also didn't even mention once "LGTM, merged, waiting for the next major release schedule".

And there is es-tooling/eslint-plugin-jsx-a11y-x#1 (comment), you aren't really dropping the legacy Node.js support anyway.

[ljharb]

I didn't have to, because I've communicated that to them via other means.

I'm not saying I'm going to change all of my hard-earned principles, I'm just saying that any time you're making a claim about what someone else will or will not do, you're going to automatically be wrong, because the only person you can say that about with authority is yourself.