-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
import/order: needs a champion? #951
Comments
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 |
(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.
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. |
I found out about it from import-js/eslint-plugin-import#951 (comment)
@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.
The text was updated successfully, but these errors were encountered: