Add internal to default order groups to match docs

[mudetroit]

Quick little bug fix we ran across recently. The docs list the default value for order groups as : ["builtin", "external", "internal", "parent", "sibling", "index"].

But that wasn't matched in the code This simply makes it match..

fixes #601

[coveralls]

Coverage remained the same at 94.896% when pulling e7a24ff on mudetroit:default-groups into 2cbd801 on benmosher:master.

[mudetroit]

Didn't realize this had been discussed previously in #608

[benmosher]

Yeah, though now that it has been independently re-suggested, I'm tempted to re-discuss.

@jfmengels: after reflecting on this, it feels like users fall into two major groups:

1. unaffected by this at all because they are using the stock node resolver (most?)
2. stand to benefit from adding internal because they are using webpack or meteor

@mudetroit, am I correct in assuming you're in the latter group?

[mudetroit]

@benmosher yes my current team falls into the later group, and I would surmise that a fair number of the webpack community does. Internal modules, are pretty easy to do with webpack, and avoid a whole class of problem with deeply nested relative pathing.

[IanVS]

I work with @mudetroit. We have an internal component library which we previously linked into node_modules to allow for simple imports. After switching to webpack, eslint-plugin-import/order started telling us to put those imports after everything else, which was a bit confusing. We've now overridden the default grouping to allow mixed internal and external, but may clean things up later to differentiate between the two now that we can.

If you want to bring the docs and code into alignment with the least disruption for everyone, it seems like you could use the following as a default order:

'import/order': [ 'error', { groups: [ 'builtin', [ 'external', 'internal' ], 'parent', 'sibling', 'index' ] } ]

This is already the de facto default for anyone not using Webpack, and would avoid linting errors when people switch to webpack with internal modules like we did.

[jfmengels]

after reflecting on this, it feels like users fall into two major groups:

1. unaffected by this at all because they are using the stock node resolver (most?)
2. stand to benefit from adding internal because they are using webpack or meteor

Yes, that sounds right. I originally proposed to fix the code #608, but as @ljharb mentionned, as the rule has always been this way since its introduction, this would probably be a breaking change. Therefore I made another PR #623 to fix the docs instead.

I think that the best course of action would be to fix the docs, and change the default settings in the next major release (which we could do sooner or later).

I originally thought that the default groups would be [ 'builtin', 'external', 'internal', 'parent', 'sibling', 'index' ] (the one written in the docs), but as @IanVS mentionned, we could specify merge external and internal. Not sure which one would fit the best to the most users, but we can discuss it. Though maybe in a new issue.

[benmosher]

@jfmengels actually yeah, a v3 with this + #479 fixed would be ideal, I suppose