Feature: Add <BUILTIN_MODULES> Special Word

[fbartho]

• This allows users to specify a gap between built-ins and third-party in a slightly less wonky way, and the plugin's default importOrder & related documentation a bit clearer.
• This also allows users to move the built-ins around relative to other imports. (Weakens our previous opinionated decision that built-ins should always be first).

[IanVS]

Minor suggestions, but nothing blocking. Nice improvement!

[IanVS]

Nice little perf improvement here.

[fbartho]

I wanted also to parse importOrder and normalize it only once, but that requires a further cleanup because there’s logic that looks at the first entry in importOrder and does something if it’s a space.

I decided to submit this PR as-is and consider if it’s worth changing that at some future date.

[IanVS]

Why do this map here, vs just injecting the regex str on line 25?

[fbartho]

We could inject the regex-str up on line 25, but it wouldn’t allow for us to remove the .map — if we want to allow users to have the built-in modules in a different place.

Here’s my thought process our code sort of looks like this:

// top-of-file-comment(s)
a-z builtin imports
a-z other-third-party
a-z relative imports
runtime.code()

I like gaps between my groups of imports, so we’d have this awkward leading empty string on the array [“”, ”<THIRD_PARTY_MODULES>”,… if there was no word for builtin modules.

And we’d never even be able to express “put a gap above built-ins, but after top-of-file comments” if we didn’t have that special word. — Unfortunately, we still can’t do that (yet) even if importOrder can express it. It would require further logic that I’m still interested in implementing; I think it’s just a (+-)1 on the shifting of the loc you recently added.

[IanVS]

Oh right, I was neglecting to consider that we need to support both having the special word in the config and injecting it. The third-party special word is handled elsewhere.