I’ve been having an issue with sourcemaps but I have found the reason why. The docs kinda state it but don’t state it clearly enough that #sourceMappingURLabsolutely must be present in your dist JS file. After browsing other topics here, and, in particular, finding the following answer:
I am happy that I’m the one doing it wrong. Sentry basically doesn’t support what Webpack calls “hidden sourcemaps” (see Webpack v1 docs and Webpack v2 docs). The way Webpack produces these is to produce a sourcemap as normal but to not include the #sourceMappingURL declaration, thus effectively severing the link between dist and sourcemap.
I was rather hoping, however, that I could still use these with Sentry. Basically uploading the distibution JS to my website and the sourcemap to Sentry as an artifact. But it seems that Sentry requires the mapping URL declaration. I get it (kinda) - as @benvinegar said in the quoted reply, there’s no presumption of mapping unless explicitly stated.
So, my question: is it likely/possible that Sentry would ever support this in any form?
I imagine that if Sentry did not wish to use any assumptions, we could use an extra parameter on the Sentry API to make a given soucemap refer to a given dist JS file. sentry-cli already treats sourcemaps differently to other artifacts (presumably for the --validate flag only, but maybe other stuff?) so it’s not a crazy stretch to assume that Sentry could support this with not-too-great effort, right?
FWIW I am aware that I can easily get around this issue by producing a normal sourcemap (i.e. leaving that declaration in), and then simply not uploading the sourcemap to my web server but still uploading it to Sentry. This is pretty good except that it’s not 100% ideal. Anyone opening devtools on the production site will produce some 404s for the sourcemap. Not the end of the world I know, but as I said, not 100% ideal either.
We do have the ability to support this through the SourceMap header on the release artifact you upload to us. We talked internally a while back, and I forget if we added support for this easily through sentry-cli or not, or if we really document this anywhere. I’ll look and get back to you. I only know the server supports this.
Ooh this is great news, thanks for the quick reply. I look forward to hearing if sentry-cli has this baked in.
Vaguely on-topic, do you have any Sentry Official Recommendation on the way to do releases in a continuous deployment scenario. Basically version numbers are too iffy for our app as we are constantly deploying when an issue is fixed, or whatever, so my thinking is to use the git rev ID. But to do that I’m gonna have to, on build:
Commit all outstanding changes to git (should be done anyway) and bail if git status is not happy.
Get the current rev ID.
Call webpack and pass the rev ID in an an environment variable so define plugin can inject it into the built source.
Upload all files but the generated sourcemap to website.
Create a release in Sentry using aforesaid rev ID.
Upload sourcemap to that release.
Does that sound about right and the “best” way to go about it or am I missing an easier way? My current build process (not involving creating the Sentry release or uploading the sourcemap) is using a relatively simple npm script to remove existing build artifacts with rimraf, call Webpack to build and finally call netlify to deploy. But doing the above steps looks like quite a bit more work that would probably have to be put in a build script rather than npm script section.
The docs kinda state it but don’t state it clearly enough that #sourceMappingURL absolutely must be present in your dist JS file.
The troubleshooting guide has a section titled “Verify sourceMappingURL is present”. Is it a case that you didn’t find this section? Or that you found it, but didn’t feel that sourceMappingURL “absolutely must be present”? Genuinely curious so we can improve the docs if it’s the latter.
We do have the ability to support this through the SourceMap header on the release artifact you upload to us.
This is missing from the docs. We should update this.
Hmm I think you have me there. So yeah, I think you’re right that actually it’s pretty clearly spelt out. Maybe the only thing that needs changing is that it should say “even if you are uploading a sourcemap as a release artifact” or similar.
I can’t say now (you have rightly predicted that hindsight is making me feel pretty stupid for not getting that before coming here ), but I can only assume I must have thought that that section was talking about the situation where the sourcemap is downloaded on the fly and not uploaded as a release artifact.
), but I can only assume I must have thought that that section was talking about the situation where the sourcemap is downloaded on the fly and not uploaded as a release artifact.