Fast degradation of source map load times

[DaveWelling]

This is probably something I'm doing wrong, but I'm not sure where to start. I hope you don't mind if I run it by you in case you have suggestions on how I might debug.

We have pretty large bundles and I've observed that the source maps seem to load fairly rapidly on the first run. However, it degrades very fast as I add changes and reload the app. Source map loads will usually timeout after the 3rd or 4th reload. If I completely shut down everything (the app on the mobile device and the repack service) and start them again, it seems to help (although I don't know if it is very consistent). We are using "@callstack/nativepack": "1.4.2", I don't think I've modifed my sourcemap plugins configuration from that in the template:

        new webpack.SourceMapDevToolPlugin({
            test: /\.(js)?bundle$/,
            exclude: /\.chunk\.(js)?bundle$/,
            filename: sourcemapFilename,
            append: `//# sourceMappingURL=[url]?platform=${platform}`
        }),
        new webpack.SourceMapDevToolPlugin({
            test: /\.(js)?bundle$/,
            include: /\.chunk\.(js)?bundle$/,
            filename: '[file].map',
            append: `//# sourceMappingURL=[url]?platform=${platform}`
        }),

I did try to use the columns: false option on the first constructor above, but that crashed for some reason.

I don't really understand the subtleties between the way repack rebuilds bundles for HMR and just normal bundle rebuilds when you make changes and reload. You may recall I had to disable HMR to get ES6 modules to work. Any chance that is the culprit? Any suggestions such as a way to increase log verbosity around source map bundling, etc.? Any chance there is some sort of cumulative caching problem that would affect the source map creation/distribution?

As an alternative, we don't usually get tremendous value from the sourcemaps for vendor code. I started to see if I could somehow speed things up by not including those, but I didn't have a lot of success. Instead of, when an error occurs, delivering me to the nearest location in the code that IS sourcemapped, I believe the debug tools just complained they did not have a sourcemap for the error location. If you know of a way around that problem and think that approach has merit and could wave your hand in the general direction of the best way to do that, I would be super grateful. :)

[DaveWelling]

One other data point, I inconsistently get something like this:

x [18:01:24.796Z][DevServer@android] Failed to symbolicate {
  error: 'Start offset -1590986392 is outside the bounds of the buffer'
}
! [18:01:24.825Z][DevServer@android] Failed to read source map from sourceMappingURL, trying fallback {
  sourceMappingUrl: 'data:application/json;charset=utf-8;base64,".concat(base64);var sourceMapping="/*# "                 
  <...big source map here>

[zamotany]

I don't really understand the subtleties between the way repack rebuilds bundles for HMR and just normal bundle rebuilds when you make changes and reload.

Re.Pack doesn't really do anything regarding the source map creation. Re.Pack only provides config for these 2 plugins webpack.SourceMapDevToolPlugin and that's it.

The errors you're getting in the console makes me think that the source maps might be broken on incomplete.

I have couple of question:

1. Do you have this issue with HMR enabled or disabled?
2. load times mean the time to build source maps or the time to symbolicate the stack trace from error? I'm not sure which load you're referring to.
3. Do you think you could create some repro project for it?

[DaveWelling]

1. Do you have this issue with HMR enabled or disabled?
2. load times mean the time to build source maps or the time to symbolicate the stack trace from error? I'm not sure which load you're referring to.
3. Do you think you could create some repro project for it?

1. I have the issue with HMR disabled. If you'd like, I might be able to turn HMR back on to see if it matters. I think I'd need to change the module type for my libraries and the webpack.config.js.
2. Great question. I do get the delays and timeouts in the absence of errors. I suspect it is the time to build the source maps because I believe I've received timeouts even if I don't put a breakpoint or have an error (e.g. just opening up a code file that needs source mapping in the browser debug tools).
3. I can certainly try. It will probably require some effort and time because I'll need to create a demo repro that has a similar configuration and number of dependencies. My employer won't thank me for posting our client code base. :)

[zamotany]

1. Let's leave HMR disabled for now.
2. Source maps are built together with the code, so once there's a new version of the bundle available the source maps are already created, so after reloading application with a new bundle, source maps are ready to go. Just to confirm, the timeouts are not the one where RN app timeouts while waiting for the compilation (of a bundle) to finish, right? Based on what you're saying I would recommend to check the size of source maps after initial bundling, a then after each change to - we want to figure out if the source maps are not getting bloated with old code.
3. Totally understandable.

[DaveWelling]

2. I didn't realize that source maps are generated at the same time. That's super useful info. Thanks. And your guess is correct: source map loading times out after the bundling is complete and the app is rendered. Based on that, your recommendation makes perfect sense to me. I'll try to track down where webpack is stuffing those source maps and compare them between bundlings. I might not get it today, but I can't see myself letting this languish too long because it does make debugging take longer. As always, very grateful for your help.

[RafikiTiki]

@DaveWelling Closing this due to inactivity. If you still want to create a repro and investigate it further please reopen or create new issue. Please keep in mind that since this issue was opened there was a major version release of repack – v3.