Clean up url normalization

[mourner]

Partially reverts #2702 while retaining the fix, getting rid of Node URL.parse and getting back to regexps and string manipulation. Reasons:

• 40% less code
• the build is 3.6% lighter (gzipped) without url module
• it's 20x faster (normalizeTileURL on a typical satellite style profiling session would take ~60ms, now 2.5ms)
• consistency and readability (previously we mixed both regexps and URL parsing together)
• it feels hacky to use URL parsing on strings that are not really true urls

@lucaswoj @xrwang

[jfirebaugh]

Can we use URL instead? I'd really like to avoid parsing with regexes.

[mourner]

@jfirebaugh that's what I started with first, but it looks like using it as a constructor for parsing URLs is not supported in IE11. I tried doing a fallback with the document.createElement('a') hack, but then ugly differences surfaced, like parsing mapbox://styles/foo as hostname="",path="//styles/foo" rather than hostname="styles",path="foo".

I'm convinced regexps are the cleanest and most robust solution here. Keep in mind that this code doesn't really normalize usual urls (it returns them as is), only Mapbox-style special strings that look like URLs but with subtle differences that are not handled by URL parsing libs (like hostname containing commas).

[jfirebaugh]

MDN says:

When using a user agent where no constructor has been implemented yet, it is possible to access such an object using the Window.URL properties (prefixed with Webkit-based browser as Window.webkitURL).

But I tested in IE 11 and this statement is either misleading or untrue; there doesn't seem to be any way to construct a URL instance in IE 11. Too bad.

This is an aside, but we shouldn't think of the first component as a "hostname" -- in URI parlance, it's an "authority". It's true that tilesets are an ugly exception; at some point we need to change them to mapbox://tilesets/....

I'm not strongly opposed to using regexes, I just think the code would be clearer and more maintainable if it used a URL/URI parser. The equivalent native issue is mapbox/mapbox-gl-native#6183.

[lucaswoj]

at some point we need to change them to mapbox://tilesets/....

We should do this sooner rather than later.

[mourner]

I'm not strongly opposed to using regexes, I just think the code would be clearer and more maintainable if it used a URL/URI parser.

I hoped for that too, but in practice found the PR approach much easier to read/update code in than the old one. The diff is hard to read, but try comparing the two sources (before/after) side by side.

[mourner]

I'm now trying out a middle-ground approach of writing a very tiny Mapbox url parsing utility, as suggested by @lucaswoj.

[mourner]

@jfirebaugh @lucaswoj can you review again after the last commit please?

[lucaswoj]

I like this compromise.

• As long as we aren't conforming to the URL spec, we shouldn't try to use the URL library.
• parseURL encapsulates the regex parsing nicely.
• There's nothing Hard about parsing mapbox:// URLs using a regex

🚢