feat(inject): Make sourcemap discovery smarter

[loewenheim]

This generalizes the discovery of sourcemaps when injecting, which should make the command easier to use. In particular, you can now have source and sourcemap files in different directories, but the directory hierarchies need to mirror each other. For example, consider:

code/
  index.js -> index.js.map
  child/
    foo.js -> foo.js.map
    index.js -> index.js.map
sourcemaps/
  index.js.map
  foo.js.map
  child/
    index.js.map

With this change, each index.js.map reference will be matched to its counterpart in the sourcemaps directory, but the foo.js.map reference would not be resolved because the file is not in the right place. If there is any ambiguity, as in

code/
  index.js -> index.js.map
sourcemaps/
  index.js.map
sourcemaps2/
  index.js.map

a warning is printed and the sourcemap is treated as not found.

I believe this implementation hits a nice sweet spot between convenience and generality.

[Swatinem]

thats interesting, but it needs a better explanation what the assumptions around this are.

[Swatinem]

do you really need to clone the url? does it not outlive your usage here?

[loewenheim]

The problem is that if we don't clone here, we hold a borrow of self.sources, which we later try to borrow mutably as well.

[Swatinem]

I believe if we can change candidate_paths to a &[&str], we also don’t need to clone for the output.

[loewenheim]

thats interesting, but it needs a better explanation what the assumptions around this are.

Fair point. Here is a more detailed description of how this works:

1. A minified source file's sourcemap URL is interpreted relative to the file's directory. For example, if code/page/foo.js refers to foo.js.map, we interpret that as code/page/foo.js.map, and if it refers to ../foo.js.map, we interpret it as code/foo.js.map. This is the sourcemap's expected path.
2. If we have a sourcemap file under the expected path, we're done.
3. Otherwise, we iterate over all sourcemaps we know of. We consider a sourcemap's path a match for the intended path if the two paths have the same number of segments and differ in exactly one segment (before the file name—this is an edge case that I actually forgot to handle). For example, maps/page/foo.js.map would be a match for code/page/foo.js.map, as would code/page2/foo.js.map, but code/foo.js.map or code/page/bar.js.map would not.
4. If there is exactly one match, we take it. If there are none, we clearly don't have the sourcemap. If there are multiple, we make no further attempt to choose the "right" one and just bail.

I think this covers the use case of code and sourcemaps residing in two separate, but "parallel" directory hierarchies with about as little complexity as possible.

[kamilogorek]

I wonder what's the chance for us to find an incorrect file. Either by a sheer chance that it's a mismatch or eg. sourcemap is out of date during deployment. But I think the same can happen now if they live in the place that pragma points to anyway ¯_(ツ)_/¯