Closed JounQin closed 3 months ago
when i was considering forking the same plugin, i came to the conclusion it makes more sense to diverge than staying in sync.
there's a lot of extra logic, architecture, etc that could easily fall away these days IMO.
i'd rather you make it independent so you can be set free on it rather than working within constraints of the original plugin
just my two cents
if you need any help, too, i'd be happy to. i work on a fair amount of things in the eslint ecosystem and was about to do my own fork until i discovered this one!
Benefits
Downsides
eslint-plugin-import has been missing a real update for years. We should take this opportunity to drop all Node.js <= 14 support.
eslint-plugin-import has been missing a real update for years. We should take this opportunity to drop all Node.js <= 14 support.
@SukkaW
Yes, we'll rewrite the whole code base into modern JavaScript/TypeScript features.
Do you want to join to maintain this project?
Next steps:
a few things i think could be cleaned up or thrown away too:
utils/
), seems unnecessary. probably good to just move this stuff into src/utils
i don't believe there's any need for this resolver architecture anymore. feels like an over-complication of things, especially splitting them out into independent packages.
i think you should be able to use this plugin and it supports every day resolution out of the box (standard resolution browsers/node-esm use, and node resolution). anything else is an edge case you could support through config, but definitely don't need an extra package for.
if we use enhanced-resolve, that itself is configurable for all those cases. doesn't seem to be a reason to have resolvers anymore, just configure enhanced-resolve differently for those edge cases.
i think you should be able to use this plugin and it supports every day resolution out of the box (standard resolution browsers/node-esm use, and node resolution). anything else is an edge case you could support through config, but definitely don't need an extra package for.
if we use enhanced-resolve, that itself is configurable for all those cases. doesn't seem to be a reason to have resolvers anymore, just configure enhanced-resolve differently for those edge cases.
And that's why I'm using enhanced-resolve
in https://github.com/import-js/eslint-import-resolver-typescript, I'll continue to use that package in the new core. While we still need to support tsconfig features like paths
, allowArbitraryExtensions
, customConditions
and moduleSuffixes
, etc.
I mean the new plugin will be a TypeScript-first plugin.
Just want to leave my opinion here. I really like the idea of rewriting everything to TS and enhance the project in a good way.
Right now I don't feel like that I can over much time 🙁 But if you want, you can invite me into the org 🙂 and I can help when I have and find time
Another thing: I dislike the plugin-name "i", because it is not clear what "i" means. Is it possible to e.g. publish as @un-es/eslint-plugin-import
or something like that?
The idea of eslint-plugin-i
comes from eslint-plugin-n
.
Personally, I don't think we should rename to a new brand considering it's already a little bit well known.
The idea of
eslint-plugin-i
comes fromeslint-plugin-n
.Personally, I don't think we should rename to a new brand considering it's already a little bit well known.
I also hate n
, what does "n" stand for? I would need to look this up in the Readme or Repo...
I also hate
n
, what does "n" stand for? I would need to look this up in the Readme or Repo...
I don't think anyone would use @un-es/eslint-plugin-import
before knowing this is the active more elegant fork, I may prefer to use the non-fork version eslint-plugin-import
.
n
or i
, on another hand, indicates that it's much lightweight somehow. If you know what it does at once, you'll never forget it.
To clarify, eslint-module-utils is a separate package; the repo is a kind of hybrid monorepo. You’re right about the memo parser, that isn’t used.
A great many users need the webpack resolver, or use the plugin with ecosystems that don’t use standard node resolution, so just be aware of who’s being excluded if you choose to drop the concept of resolvers.
i don't believe we need a resolver architecture/plugin system for that
nothing is stopping us providing configurable resolution using a single built-in resolver. i think it was an over-engineering of a much simpler thing. enhanced-resolve plus some configuration will achieve everything we need.
just my opinion though. sure you believed the opposite when you built it, which is fair enough. each to their own
I didn’t build it.
enhanced-resolve
is good enough to handle webpack things. eslint-module-utils
is needless anymore.
I've started the migration at #26
Really glad to see someone start fork it, I had really bad experience contribute to the original repo once, and decide never do it again..
I dislike the plugin-name "i".
Same here.
Progress: I've successfully removed all resolver
concepts by using enhanced-resolve
directly at f747071
(#26) as @43081j proposed. And eslint .
run in this project itself is just working, the next step will be focusing on testing.
@fisker @Shinigami92
Do you think @eslinter/eslint-plugin-import
or @eslint-community/eslint-plugin-import
would be accepted?
I own @eslinter but I don't know how to join @eslint-community, and eslint-community
is a bit too long to myself, like @typescript-eslint, I'd prefer @tseslint
for example.
Although it's too late as @bradzacher said, but we still have the chance.
Another interesting thing is that, I own https://github.com/eslinter/eslint-plugin-jsx and the npm package now, so I'll start to adapt @jsx-eslint packages like https://github.com/jsx-eslint/eslint-plugin-react into eslint-plugin-jsx
when I finished the migration of eslint-plugin-import
.
I really hope @Rel1cx can join in this case.
doing such good work already 🙏 ill have a read through the PR this weekend if i can
on the naming - i do agree it'd be nice if it had a "full" name (rather than i
) but i understand it already has a fair amount of users. if it were upto me, i'd probably call it eslint-plugin-import
under a scope.
the eslint community org would be good to put this into but you're right that the scope is pretty lengthy. even if you don't adopt that name, it may still be worth joining that org on github though (assuming it is "official" and actively managed, and doesn't remove any ownership from you).
Any chance to have eslint-plugin-module or eslint-plugin-modules?
Any chance to have eslint-plugin-module or eslint-plugin-modules?
@fisker I'll try to contact these two package owners.
@eslint-community/eslint-plugin-import
would be nice, @eslint-community
is a trusted community group
Does @eslint-community/eslint-plugin-import
even work in legacy ESLint config?
It should be eslint-plugin-___
or @___/eslint-plugin
, am I wrong? If it works, the plugin name will be @eslint-community/import
?
Does @eslint-community/eslint-plugin-import even work in legacy ESLint config?
Yes. The users can always use the plugin full name or @eslint-community/import
for shorthand.
{
'@eslint-community/import/consistent-type-specifier-style': 'off'
}
Great rule name! 😄
Great rule name! 😄
That's why I'd prefer a short package name.
Progress:
Test Suites: 25 failed, 29 passed, 54 total
Tests: 257 failed, 2226 passed, 2483 total
cc @MichaelDeBoey @ota-meshi for @eslint-community
@JounQin Although I agree with the choices made in this fork and I don't get why @ljharb doesn't want to add them (I understand the reasoning of BC, but I don't agree with people still using Node v4, especially not for running their linter), I'm not sure if we want to have a fork of a package that's still actively maintained but has different opinions tbh 🤔
I'll talk to the rest of the core @eslint-community team to decide what to do with this case, as normally we're only taking over (widely dependent upon) ESLint-related packages that are either widely dependent upon and/or that are abandoned by the original author or where the original author wants to give it a safer place so it doesn't get abandoned if they're unable to continue maintenance for whatever reason
fwiw I'm highly likely to do a breaking change in the ~first~ last part of this year to drop eslint < 8, and the associated node versions.
I'm not sure if we want to have a fork of a package that's still actively maintained but has different opinions
choices are good. if it doesn't make sense to have two in the eslint-community org, maybe that's fair enough. but out in the wild, it'd be nice to see multiple options sometimes, regardless of why they exist. just fwiw.
i'm likely to move many repos to this plugin, away from the other, whatever the outcome of the naming and wherever it lives. some will be similar. so maybe the whole eslint-community thing is something for future rather than now (if it becomes depended upon enough).
It def makes sense to wait until sufficient adoption before moving anything into that org.
@MichaelDeBoey
I'm not sure if we want to have a fork of a package that's still actively maintained but has different opinions tbh
That's the biggest problem, a lot of issues can not be resolved due to this problem
I'll talk to the rest of the core https://github.com/eslint-community team to decide what to do with this case
Glad to hear. And I want to clarify, we'll move forward w/wo joining in @eslint-community, and I own @eslinter, I'll migrate eslnt-plugin-react
in next step.
@ljharb
fwiw I'm highly likely to do a breaking change i the first part of this year to drop eslint < 8, and the associated node versions.
Sorry, but I can't believe it and we've removed the concept of different resolver
s, I don't think that's acceptable for you.
It def makes sense to wait until sufficient adoption before moving anything into that org.
That's OK, we have our own org @eslinter.
I'll migrate
eslnt-plugin-react
in next step.
did you already start this? i have a branch lying around which does a bunch of it from what i remember
if you want any help, ping me when you make the repo and i'll push the branch for you to look at, at least
(don't want to take this thread off topic so lets catch up once the repo exists rather than here)
@JounQin true, because that makes it useless for preact and svelte and vue and styled-components etc users.
@43081j
I haven't personally, but I know a great project https://github.com/Rel1cx/eslint-react, that's why I said I really hope @Rel1cx can join us.
@43081j
I haven't personally, but I know a great project Rel1cx/eslint-react, that's why I said I really hope @Rel1cx can join us.
I strongly support you to do a full rewrite of eslint-plugin-import, maybe called eslint-plugin-esm + eslint-plugin-cjs (two separate packages), or eslint-plugin-module (one package). But as for migrating eslint-plugin-react to eslint-plugin-jsx, my point of view is consistent with this reply https://github.com/Rel1cx/eslint-react/issues/52#issuecomment-1785153861.
@Rel1cx In my view, some rules are universal, some rules are framework specific.
For react rules, we can have jsx/react/x
rules, for vue rules, we can have jsx/vue/x
rules, etc, and we can have jsx/x
rules for universal cases.
So in eslint-plugin-jsx
, @eslint-react could be an dependency.
You could make an eslint-plugin-jsx but that only makes sense if the rules in it are truly framework-agnostic, and considering that most of the natural framework-agnostic rules have already been migrated to @stylistic/eslint-plugin-jsx, there aren't that many left.
Where JSX fits into the ecosystem of front-end languages and frameworks:
JS in Vue TS in Vue TSX in Vue
JS in Solid TS in Solid TSX in Solid
...
In essence, JSX is just a syntax extension, how to lint TSX here is the same as TS, JS here, it's up to the frameworks, making an eslint-plugin-jsx that doesn't just take care of the correctness of JSX itself, but also has to be configured (or prefixed) to support the behaviour of all the specific frameworks that have used JSX in the past, are using JSX now, and will be in the future is equivalent to making a @typescript-eslint/eslint-plugin but not only for the correctness of TS itself but also configured (or prefixed) to support the behaviour of all the frameworks that use TS, React, Preact, Solid, Vue, etc.
Don't think of JSX as anything special, it's basically the same thing as JS and TS.
Just my two cents, I roughly agree.
OK, like @jsx-eslint, I own @eslint-jsx, we can make framework specific plugins at that org.
Progress:
Test Suites: 21 failed, 33 passed, 54 total
Tests: 171 failed, 2108 passed, 2279 total
After thinking, I think eslint-plugin-import-x
could be the best choice just like https://github.com/eslint-community/eslint-plugin-es-x.
i think that makes sense, since future forks of other plugins could follow the same naming convention too. nice to have some consistency there
I've published eslint-plugin-import-x as the successor of eslint-plugin-i
, it should work as previous for now, except it's not an alias anymore, all settings are renamed into import-x/
prefix.
The whole progress was tough, #26 was unable to continue because I chose to migrate codes instead tests first.
But finally I migrated babel-core
into @babel/core
, babel-eslint
into @babel/eslint-parser
, etc., successfully at #30. And I also migrated mocha
/sinon
to jest
.
But I haven't removed the resolver
concept: let's continue discussing at #40.
In the next step, I'll try to migrate the whole code base into TypeScript.
I'm thinking about maintaining this package as a complete independent plugin from upstream because a lot of issues can not be fixed easily without API changes, see
https://github.com/import-js/eslint-plugin-import/issues/1479
https://github.com/import-js/eslint-plugin-import/issues/2108
https://github.com/import-js/eslint-plugin-import/issues/2111
https://github.com/import-js/eslint-plugin-import/issues/2717
It would affect 3rd party resolvers like https://github.com/import-js/eslint-import-resolver-typescript/pull/248
@SukkaW do you want to collaborate here?