add support for projectRoot in source-map-uploader-plugin

[rossipedia]

Goal

@bugsnag/source-maps provides an option for projectRoot, but BugsnagSourceMapUploaderPlugin does not expose that option. This helps for situations where the project being built is in a subfolder of the repository, rather than the root (as I understand it).

Design

Simplest, most straightforward approach I could think of.

Changeset

Added a projectRoot option that is propagated to @bugsnag/source-maps

Testing

We've been running this change using patch-package in building Docker Hub.

[luke-belton]

Hi @rossipedia - thanks for raising this. The Bugsnag Webpack plugin uses Webpack's Compilation object to derive the paths to source maps. Are you able to share a reproduction example with us please where this isn't working as expected? Currently we're struggling to see a situation where projectRoot would be needed, but of course we're happy to investigate!

[rossipedia]

Hi @luke-belton, I don't think I can share the specific project as it's closed-source, but I'll try to explain with screenshots and code samples.

(Also, fwiw, we found that this solution doesn't actually work, unfortunately).

The Docker Hub project lives in a sub folder of our repository (the client folder). Our plugin config looks like this:

        new SourceMapDevToolPlugin({
          filename: '[file].map',
          moduleFilenameTemplate: (info) => info.resource,
          append: false,
          sourceRoot: 'client',
          test: /\.js$/,
        }),
        new BugsnagSourceMapUploaderPlugin({
          apiKey: bugsnagApiKey,
          publicPath: 'http*://*/', // sample
          appVersion: BUILD_VERSION,
          ignoredBundleExtensions: ['.css'],
        }),

With this, we get weird path names in our stack traces:

Notice the client/dist/node_modules/... path. This path isn't correct. While the build generates the minified files under client/dist, node_modules is actually a sibling of the dist folder (client/node_modules).

As such, we're not quite sure how to properly configure this plugin to resolve source file paths correctly. I've tried quite a few permutations of the SourceMapDevToolPlugin but when we can get the actual path to be what we want, we end up with nonsensical stack traces.

[luke-belton]

Hi @rossipedia - after some internal discussion we're still not really 100% clear on your project setup here unfortunately, in particular how in a webpack build the bundle will be referring to a node_modules directory in a parent folder of the bundle. Appreciate it's a closed source project and you can't share the code but could you perhaps put together a minimum reproduction example for us to demonstrate the issue?

You said this PR doesn't solve the issue - have you been able to find an alternative workaround?

[rossipedia]

Hi @rossipedia - after some internal discussion we're still not really 100% clear on your project setup here unfortunately, in particular how in a webpack build the bundle will be referring to a node_modules directory in a parent folder of the bundle. Appreciate it's a closed source project and you can't share the code but could you perhaps put together a minimum reproduction example for us to demonstrate the issue?

You said this PR doesn't solve the issue - have you been able to find an alternative workaround?

I think what we've been dealing with is two separate issues. The nonsensical stack traces seem to all originate from Safari, so we've filtered out Safari for now and the stack traces seem to make sense now. However we're still seeing weird paths in the filenames. I'll see if I can put together a minimal repro and post it here

[djskinner]

Regarding the nonsensical stack traces, it may be caused by https://bugs.webkit.org/show_bug.cgi?id=221548 as we experienced something similar with Safari stacktraces leading us to raising the bug

[johnkiely1]

Hey @rossipedia, just wondering if you've had a chance to put together a minimal repro case? We are still unable to reproduce what you are seeing.

[rossipedia]

Not quite yet. I've had a few other things come up in priority. I'll try to get something put together shortly

[johnkiely1]

Hey @rossipedia, going to close this out for now, but let us know as soon as you can provide a repro case and we can reopen. Thanks.