The future of this fork/plugin

[JounQin]

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

import-js#1479

import-js#2108

import-js#2111

import-js#2717

It would affect 3rd party resolvers like import-js/eslint-import-resolver-typescript#248

@SukkaW do you want to collaborate here?

[43081j]

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!

[JounQin]

Benefits

1. No limitations anymore, I'll rewrite the whole package with TypeScript, Support for eslint-define-config #23 can be fixed as an effect, cc @Shinigami92
2. Replace all the legacy codes to modern JavaScript/TypeScript
3. Add features we want

Downsides

1. Less contributors at the first place
2. Maybe difficult to support both plugins, what's the future of https://github.com/import-js/eslint-import-resolver-typescript
3. Per 2, should we support TypeScript as first-class, so basically we combined the two packages, is that worth or needed considering not everyone uses TypeScript and package size difference

[SukkaW]

eslint-plugin-import has been missing a real update for years. We should take this opportunity to drop all Node.js <= 14 support.

[JounQin]

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:

1. I'll transfer this repository into @un-ts org because it will be changed as a TypeScript based library
2. If you want to join, which level do you want to be involved, org level or repository level
3. I'll start to setup the whole code base in a few days, the progress would just be similar as prettier/pretty-quick@v3.1.3...v4.0.0

[43081j]

a few things i think could be cleaned up or thrown away too:

• throw away memo-parser, feels like an experiment that got dumped in the repo and doesn't really belong here anymore
• eslint-module-utils is a "package" that gets pulled from disk (utils/), seems unnecessary. probably good to just move this stuff into src/utils
• check that those utils are actually needed
• consider dropping the concept of a "resolver"

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.

[JounQin]

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.

[Shinigami92]

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?

[JounQin]

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.

[Shinigami92]

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.

I also hate n, what does "n" stand for? I would need to look this up in the Readme or Repo...

[JounQin]

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.

[ljharb]

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.