Allow import/order to accept a glob/regex

[HenriBeck]

Why

It should be possible to sort the imports based on their needs.

For example:
I want to have my meteor imports after my node imports but before the rest.

Proposal

.eslintrc.js

module.exports = {
  rules: {
    'import/order': ['error', {
      groups: [
        'builtin',
        '^meteor/.+$'
      ]
    }]
  }
}

Thoughts?

[ZxMYS]

+1! Need it to put css imports into a separate group.

[tirli]

Any updates on this feature?

[lucasveigaf]

Would really love to have this as well. Seems like it's a recurring request.

[michielmetcake]

Any update on this proposal? I would love to see this 👍

[fregante]

I think this customization would make the rule much more useful and flexible. Placing CSS imports on top is quite important since their order matters.

[ljharb]

Their order matters relative to each other, but it doesn’t matter if they’re first, last, or scattered between.

[fregante]

but it doesn’t matter if they’re first, last, or scattered between

What happens here? I think component.css will appear before main.css, but that's not what I want.

// main.js
import "./component.js"
import "./main.css"

// component.js
import "./component.css"

[ljharb]

Sure, but that’s across files - which means you have to intimately know the implementation details already, and that can’t be safely encoded in a lint rule. You won’t always want main to come before component - for example, if you want main to override component.

[fregante]

You just said that it doesn't matter, I showed you it does matter. The lint rule totally can expect .css files to be on top. That's all I'm asking. I'm not asking to detect whether it matters, because we already know it matters and that's why they should be on top.

You won’t always want main to come before component

That's up to the lint configurator to decide.

[ljharb]

Touché. The problem is that it doesn't matter the same always - and neither "css on top" nor "css on bottom" actually covers all generic use cases, because it always depends on the exact things those CSS files are doing, due to the global nature of CSS.

In other words, I don't think it's something that can be properly configured in static analysis in a generic sense, due to the inherent category error of importing globally-side-effecting CSS in the first place.