List of known sourcemap inject bugs

[loewenheim]

1. We have gotten customer reports of injection problems when a file starts with something like

(this.foo=this.bar||[]).push([[2],[function(e,t,n){"use strict"; […] }

This trips the "use pragma" detection and causes the line to be skipped, which is obviously not intended. Solution: make the regex stricter.

2. Block comments aren't handled at all. Thus, if a file started with

/* lol, lmao */
"use strict";

we would erroneously inject at the very top. Solution: handle block comments.

3. 'use strict'; can be on the same line as the rest of the code, eg 'use strict';(function(){console.log('wat')})(); is a valid code, and we do not handle injecting snippet "in-between" - ref: Source maps inject results in corrupt source map files #1646

Tasks

Beta Give feedback

1. fix(inject): Make pragma detection stricter #1648
   +0
   
2. Handle block comments
3. Handle same-line use strict usages

[yharaskrik]

I have something to add to this list. We are using GraphQL and sometimes the injection gets injected into the template string that is defining out GraphQL queries. Here is a couple snippets to show you:

Although this MIGHT fall into #1 above.

This is a minified Angular App

[loewenheim]

Thank you for the report. The second screenshot looks gnarly. The fact that a statement starts on the same line as the pragma and then continues for several lines is going to be very hard to work around.

[yharaskrik]

Thank you for the report. The second screenshot looks gnarly. The fact that a statement starts on the same line as the pragma and then continues for several lines is going to be very hard to work around.

Is that not normal? I don't think we are doing anything different than a normal Angular production build. I can investigate a bit to see if maybe we are doing something out of the norm?

[loewenheim]

Is that not normal? I don't think we are doing anything different than a normal Angular production build. I can investigate a bit to see if maybe we are doing something out of the norm?

Sorry, I didn't mean to imply you were doing anything wrong. This is just one of several assumptions we were making that appear to not hold up in practice.

[yharaskrik]

Is that not normal? I don't think we are doing anything different than a normal Angular production build. I can investigate a bit to see if maybe we are doing something out of the norm?

Sorry, I didn't mean to imply you were doing anything wrong. This is just one of several assumptions we were making that appear to not hold up in practice.

No worries all good! I can double check that a plain angular build that is freshly generated does the same thing just so we know.

[yharaskrik]

Is that not normal? I don't think we are doing anything different than a normal Angular production build. I can investigate a bit to see if maybe we are doing something out of the norm?

Sorry, I didn't mean to imply you were doing anything wrong. This is just one of several assumptions we were making that appear to not hold up in practice.

No worries all good! I can double check that a plain angular build that is freshly generated does the same thing just so we know.

Just generate a fresh Angular project using Nx, looks like the apps get minified to a single line. So ya. I guess that is a case you might have to handle. Let me know if I can help at all.

[loewenheim]

@j-fulbright Does the first line of the injected JS file contain "use strict"; or something similar?

[j-fulbright]

Actually after reviewing with another developer, it was determined the CLI is adding an extraneous semicolon in the mappings group. Reviewing of the source for the CLI, it appears this is intentional in some way, but it is breaking our sourcemaps, as removing the semicolon, makes them resolve correctly on the commandline.

*mappings = format!(";{mappings}");

Working:

{"version":3,"file":"main.2de0db9ef2b6b37e.js","mappings":"uIAAO

After CLI:

"file":"main.2de0db9ef2b6b37e.js","mappings":";uIAAO,IAAMA

Beginning of some of the JS files:

(self.webpackChunkcorporate_portal=self.webpackChunkcorporate_portal||[]).push([[179],{7177:(Xt,rt,B)=>{"use strict";B.d(rt,{$:()=>s});let s=(()=>{class X{}return X.paths={base:"",login:"login",portal:"secure",dashboard:"dashboard",users:"users",groups:"groups",accounts:"accounts",phoneSearchLink:"phone-search-link",dataSearch:"data-search",dataValidation:"data-validation",generatedReports:"generated-reports",

It is possible the pragma changes that are merged may resolve for us, since it changes regex as well

[d3ce1t]

As a workaround, I'm executing this in a React App in order to remove the semicolon in sourcemaps after injecting debugIds using sentry-cli:

find build/static/js -type f -name "*.js.map" -exec sed -i 's/\("mappings":"\);/\1/g' {} +

I hope it works for you :)

[loewenheim]

I am sorry for the frustration caused by this. We're currently working on putting injection on a more solid foundation.

[jbub]

We just got bit by this badly, simplified reproducer:

Original js file:

(function (global, factory) {
    typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
        typeof define === 'function' && define.amd ? define(factory) :
            (global = global || self, global.myObject = factory());
}(this, (function () { 'use strict';
    var myHTML = "\n";
    return {};
})));

Minified:

(()=>{var i=(n,e)=>()=>(e||n((e={exports:{}}).exports,e),e.exports);var d=i((t,f)=>{(function(n,e){typeof t=="object"&&typeof f<"u"?f.exports=e():typeof define=="function"&&define.amd?define(e):(n=n||self,n.myObject=e())})(t,function(){"use strict";var n=`
`;return{}})});d();})();

Debug ids Injected:

(()=>{var i=(n,e)=>()=>(e||n((e={exports:{}}).exports,e),e.exports);var d=i((t,f)=>{(function(n,e){typeof t=="object"&&typeof f<"u"?f.exports=e():typeof define=="function"&&define.amd?define(e):(n=n||self,n.myObject=e())})(t,function(){"use strict";var n=`
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof self?self:{},n=(new Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="2c4f8e42-99ad-5954-85ef-815190b8286a")}catch(e){}}();
`;return{}})});d();})();
//# debugId=2c4f8e42-99ad-5954-85ef-815190b8286a

As you can see this is pretty bad, it ends up inserting the sentry debug snippet inside the myHTML variable. Are there any workarounds available ? When can we expect this to be fixed ? We had to disable sourcemap support because of this, making the Sentry issues mostly unreadable.

[kamilogorek]

Adding #1689 to the list to make it easier to track.

[jbub]

@kamilogorek this was closed by mistake ?

[kamilogorek]

Yes, sorry. Thanks for catching this. I meant to close linked issue only 😅

[loewenheim]

All of these bugs should be fixed as of sentry-cli 2.20.4. Thank you very much for your forbearance, eveyone 🙇

[NSiggel]

not sure if related, but we are having an issue where using "sentry-cli sourcemaps inject" has broken our projects use of the Angular SwUpdate.versionUpdates.subscribe((event: VersionEvent)
to run automatic updates in our application in production.

As soon as we removed the

• sentry-cli sourcemaps inject $CODEBUILD_SRC_DIR/www

The next release went through automatic updates properly.

I suspect this is causing an issue for the ServiceWorker process looking up which files need to be downloaded (hashmap lookup ?) such that the inject process breaks the hashmap of files to be downloaded by the updater ?

ANY suggestions/work arounds ? I was happy to finally get proper source maps for a release working w/ Web/iOS Capacitor via the artifact bundles but now need to remove it from our CICD since broke automatic updates.

[lforst]

@NSiggel To me this doesn't sound like a bug. If injecting something into your code is not feasible due to code integrity you should probably resort to the legacy method of uploading which does not need to inject but is a bit trickier to get right.

If you face any more issues please open another issue since this seems unrelated.