Fall back to co-located source maps in `sourcemaps inject` command

[lforst]

Based on the feedback in getsentry/sentry-javascript#9666 the CLI should fall back to looking for a generated file's source map in the colocated location when

• the generated file doesn't have a sourceMapURL comment
• or the source map can't be found at the location that the sourceMapURL comment points to.

An example of "co-location":

/some/folder
- /output/
  - /my-bundle.js
  - /my-bundle.js.map

[brettdh]

Hi, author of getsentry/sentry-javascript#9666 here 👋

I'm going to start working on a PR for this. If someone already has something underway, please let me know. Thanks!

One question: if the source file contains an external sourcemap URL and a co-located source map file exists, which one should sourcemaps inject prefer? The common sequence of steps I'm thinking of is this:

1. remix build --sourcemap (or whatever build step you have to generate sourcemaps)
   • Whatever the build step, the sourcemap URL may point to static storage like S3, rather than a local file
   • If so, the local file is now more up-to-date than the remote one
   • Despite the Remix advice not to deploy source maps in production, there are valid reasons to do so (and the Remix situation with regard to server-side code appearing in client-side sourcemaps may be improving soon)
2. sentry-cli sourcemaps inject
   • Can the CLI reliably determine that the local sourcemap is newer than the remote one?
   • Should it be told to prefer one or the other via flag?
3. Upload bundles and source maps to hosting (perhaps to different hosts)
   • If sentry-cli chose wrong in the previous step, the source maps in Sentry are not those that were built for the source files that are about to be deployed

[brettdh]

I think I was under the impression that the CLI would attempt to download the sourcemap if sourceMappingURL was not a local file... but I'm having trouble finding the code that would do that. It looks like I might just be mistaken about that, and that the CLI treats remote URLs just like file paths... producing some pretty weird results when I run with --log-level debug.

For a js bundle containing this line:

//# sourceMappingURL=https://my-s3-bucket.s3.amazonaws.com/static/build/_shared/chunk-GBSSQ3TL.js.map

sentry-cli sourcemaps inject outputs this:

  DEBUG   2023-11-29 17:41:11.552172 -05:00 Sourcemap file
 /Users/brhiggins/path/to/my/project/public/build/_shared/https://my-s3-bucket.s3.amazonaws.com/static/build/_shared/chunk-GBSSQ3TL.js.map not found

which would certainly explain the failure to find the source map! 😅

[lforst]

I don't think the CLI will download files. It will just look for them locally. If you have "fetching source maps" enabled in Sentry we will also try to grab it from wherever the url points to.

[loewenheim]

That's correct, sentry-cli will never download sourcemaps. The missing piece here is trying a co-located sourcemap if the one in the comment can't be found locally.

Also note that your notion of "co-location" can be expanded a bit using the inject::find_matching_paths function:

sentry-cli/src/utils/sourcemaps/inject.rs

Lines 259 to 269 in 791a1f8

	/// Returns a list of those paths among `candidate_paths` that differ from `expected_path` in
	/// at most one segment (modulo `.` segments).
	///
	/// The differing segment cannot be the last one (i.e., the filename).
	///
	/// If `expected_path` occurs among the `candidate_paths`, no other paths will be returned since
	/// that is considered a unique best match.
	///
	/// The intended usecase is finding sourcemaps even if they reside in a different directory; see
	/// the `test_find_matching_paths_sourcemaps` test for a minimal example.
	pub fn find_matching_paths(candidate_paths: &[String], expected_path: &str) -> Vec<String> {

[brettdh]

Hmm, it seems that this issue also occurs if the sourceMappingURL is a URL path (without the https://<domain> part). This is indistinguishable from a file path, though. The logic here should probably be adjusted to fall back to colocation heuristics if the URL is a full URL or a file that can't be found. (It makes me wonder under what circumstances the value of sourceMappingURL will actually be used, but I digress.)

@lforst Better to create a new issue, or reopen this one?

[lforst]

@brettdh Please open a new issue with exact steps to reproduce what is wrong. Thanks!