-
-
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 group by prefix #795
Comments
If we allow any string there, then adding any new options goes from being a semver-minor to a semver-major, and there'd be no easy way to tell people when they have to update their configs. |
What if the prefixes were done in a second option
The |
That would avoid the conflict I specified. Also, instead of a prefix, we'd probably want to use globs - ie, |
Globs would work as well. And I like the addition of the suffix. What's the difficulty of doing something like this? I'd love to contribute this myself if possible. Do you have any suggested resources (aside from the code itself) on how to get started with writing part of a linter plugin? |
I am also interested in this. Are there any plans to implement this? |
Yea I would also like to see support for this. Is it posible to also declare imports based on imported file extension? For example I want to have |
See my comment in #807 (comment) I think in times of yarn/lerna workspaces, users need some degree of control about e.g. what is "internal". Having namespaced packages should actually help the situation. |
Would love to see some action on this feature request. |
Any news on this? :( |
I import from all over my app, with a mix of relative and root imports. The current order rule covers most of my cases, and with #629 fixing #389 (sorting alphabetically), that will cover more. But one case that won't be covered is that I prefer to have all my global functions imported first, which come from a
/lib
directory, followed by my components which come from a/client/modules
directory.Sorting alphabetically, I would have to do
But I'd rather do
Within the rule itself, there's one way I could see it being defined
Use the existing
groups
option, and anything that isn't currently an option (builtins
,sibling
, etc) would be considered a prefix"import/order": ["error", {"groups": ["builtins", "external", "/lib", "/client"]}]
This would also handle the concern in this comment that people will start to request a bunch of order types and exceptions to them
The text was updated successfully, but these errors were encountered: