@jfmengels / @ljharb: what do y'all think of spinning import/order (and maybe more/all the pure style-guide rules) out into a separate plugin?
There is clearly an enthusiastic user base, but I am not a member thereof and so I think it's frustrating for everyone when I basically just don't get involved, and I don't have the bandwidth already to manage the static analysis stuff (which I do use and am passionate about).
Thoughts?
Practically, I think we'd move the current implementation either back to @jfmengels' project or to some new project (not sure whose, in that case) and then deprecate here with a note to migrate to the new separate plugin, and remove in v3.
I don't see the value there; it's fine if you personally aren't interested in one of the rules (it'd just be made clear that we don't need to check with you about that rule in particular).
Keep in mind that the cost of adding a new plugin to shared configs - like airbnb's - is very high, so by spinning a rule out its effectively preventing airbnb config users from being able to use it by default.
that is fair. one of the primary benefits originally was combined exposure of both sides of this plugin. I just hate for the issues to pile up here, is all. I've been moving slowly enough as it is on any of the minor bugfixes over the last 12 months or so, I really appreciate all the slack you've been taking up.
maybe I'm just mentally overinflated the wave of order issues. will leave it be for now. but yeah, if @jfmengels is done maintaining it (can't blame him) and I'm not going to really be helpful managing it, that leaves you to champion this rule and its many issues (if you're up for it) or maybe it'd be good to pull in another primary collaborator from the community.
(also @jfmengels, apologies if you've been keeping up and I'm just missing it, I have looked at a pretty small subset of the currently open issues so I'd believe I've just missed anything you've posted in the last bunch of months)
We want to split some of our imports to separate group, probably it's also related to this issue.
import 'external-module';
import 'special!file'; // โ this group
import './internal-module.js'
I think this idea is worth revisiting.
import/order has not been updated in months and is missing many requested features. Meanwhile import/order has already been forked and that library has already done the work of implementing various feature requests still open in this repo.
It may be worth either deprecating import/order and recommending import-helpers/order-imports instead. Or making it possible for that fork to be merged into eslint-plugin-import and the author to easily improve it.
@dantman that author doesn't seem to have indicated that it's been forked, nor made any PRs to this repo.
I don't think it's a good idea to deprecate the rule; I think that if there's feature requests that haven't yet been implemented here, there's a good reason.
What if in v3 we just re-exported their forked rule? Does everyone win?
(Assuming it is compatible)
I'd rather remove it entirely than do that; anything that's not in our rule is something that shouldn't be imo - ie, unsafe sorting.
Most helpful comment
I think this idea is worth revisiting.
import/orderhas not been updated in months and is missing many requested features. Meanwhileimport/orderhas already been forked and that library has already done the work of implementing various feature requests still open in this repo.It may be worth either deprecating import/order and recommending import-helpers/order-imports instead. Or making it possible for that fork to be merged into eslint-plugin-import and the author to easily improve it.