Reporting not working from Webpack bundled code (Blank version number)

[bugsnag]

Reporting not working from Webpack bundled code (Blank version number)

[kattrali]

Thanks for the report, @JoeStanton. At first glance, I'd think it would be something to do with the notifier section having a null version field, but we'll look into it.

[foxyblocks]

I've setup a new lambda server to test this and was able to report errors to bugsnag just fine. Perhaps there is some environment difference that is preventing it from working for you.

Essentially all we are doing to get the version number is:

var path = require('path');
require(path.join(__dirname, '..', 'package.json')).version;

I suppose it's possible that there's a problem with __dirname?

Can you confirm that __dirname is working on your lambda server?

[JoeStanton]

Thanks for looking into this - I've cracked it. As we're transpiling ES6/7, we produce a Webpack bundle that we then use on Lambda. This inlines bugsnag rather than leaving it in node_modules.

Because your version lookup depends on the directory structure, it fails in this context.

Would you recommend if we're producing a JS bundle that we use the client side JS version of this library?

[foxyblocks]

No, the client side JS version is only meant to work inside a browser environment. According to this thread you can try listing bugsnag in externals under your webpack config.

If that doesn't work, then maybe we can add something to the library to detect that it is being processed by webpack and require the package.json rather than reading it from disk.

[JoeStanton]

If we list Bugsnag as a webpack external, users will need to do additional work to ensure this file is shipped next to their bundle and made available by some other means.

IMO it would be preferable to follow your latter suggestion on this? It may be an edge case, but I don't think its safe to assume runtime paths in the age of bundling, and this is non-trivial to debug when it does happen.

Perhaps the easiest solution would be to default the PAYLOAD_VERSION if it can't be found (or failing that, throw an error and make clear that this is a problem).

[jmshal]

It looks to me as if your patch, @JoeStanton (redbadger@d877e32) is enough to support both standard (non-transpiled) node.js apps, and bundled node.js apps as well. Or am I wrong?

From what I can tell Utils.getPackageVersion does a simple require anyway, so there's little to no difference - other than the relative path.

If that's correct, would it not be as simple as merging that patch upstream?

[JoeStanton]

@jacobmarshall it is indeed sufficient for bundled/non-bundled node apps, however, it assumes the existence of package.json without a try/catch. It would be quite odd for this file not to exist, but not sure if this would break someones use case.

[jmshal]

@jacobmarshall it is indeed sufficient for bundled/non-bundled node apps, however, it assumes the existence of package.json without a try/catch. It would be quite odd for this file not to exist, but not sure if this would break someones use case.

Correct, because it's reading the bugsnag-node package.json file. Which should always be picked up by the module bundler - in this case webpack.

I'll be honest, it's kind of strange to me that the current code wraps the require in a try/catch. I can see that it's always been there (c5aaa5f) - but I'm fairly confident it doesn't need to be there.

I can see now that it's also used to pickup the app's package.json version if one is not provided in Configuration.appVersion (https://github.com/bugsnag/bugsnag-node/blob/master/lib/configuration.js#L69). So that explains it 😜

[kattrali]

Hardcoding this value is the simple solution, and the same as other bugsnag libraries. I updated the release instructions as well as the value to ensure it stays up to date.