Can't be bundled with Webpack when DefinePlugin is used

[chiplay]

We are using analytics-node in our AWS Lambda function and last night started receiving errors:

Unable to import module 'index': Error
at require (internal/module.js:12:17)
at Object.<anonymous> (/var/task/node_modules/analytics-node/lib/index.js:10:16)

Looks like some change between 2.1.1 and 2.3.0 is breaking the import/require for us. Unfortunately lambda error stacks are pretty obscure - any ideas?

[pdkn]

same issue here. we are using node 4.3 in Lambda. Code is compiled using webpack and babel with preset es2015. When we run there's 2 errors traced:
Error 1:
module initialization error: ReferenceError
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)

Error 2:
module initialization error: ReferenceError
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)

any pointers would be wonderful. Thanks

[vadimdemedes]

@chiplay This doesn't look like an error with analytics-node itself, but an error related to your deployment on Lambda. The error you've mentioned seems to be a popular issue: https://forums.aws.amazon.com/thread.jspa?threadID=168326. Could this be the source of your problem?

@pdkn Same here, I think, because the stack trace doesn't have references to analytics-node. Could you confirm that your deployment works fine, when you remove all calls to analytics-node (and require('analytics-node'))? I tried compiling this project with webpack and there were no issues.

[vadimdemedes]

Closing this issue for now. Make sure to try out the latest release (https://github.com/segmentio/analytics-node/releases/tag/v3.0.0)!

If the advice above doesn't help, feel free to open a new issue.

[pdkn]

Hi @vadimdemedes I've just upgraded to 3.0 from 2.4 and tried to bundle analytics-node into the webpack build. Alas it throws this warning:
WARNING in ./~/formidable/lib/incoming_form.js
1:43-50 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

and then when running the code in Lambda (Node 6.10):
module initialization error: ReferenceError "true" = namespaces; ^^^^^^ ReferenceError: Invalid left-hand side in assignment.

If we don't bundle the lib into the webpack bundle but keep as external lib then it works

Class & Webpack config Attached:
Tracking.js.zip
webpack.zip

[vadimdemedes]

WARNING in ./~/formidable/lib/incoming_form.js
1:43-50 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

The webpack error isn't for analytics-node, but for formidable module.

module initialization error: ReferenceError "true" = namespaces; ^^^^^^ ReferenceError: Invalid left-hand side in assignment.

This is more likely an error with your code, because it's not a valid JS. analytics-node doesn't have "true" = namespaces;. Otherwise our CI builds would fail too.

If you search in your editor for "true" = namespaces, what does it show?

[pdkn]

yup, but 'formidable' is a dependency of 'superagent' which is a dependency of analytics-node.

[vadimdemedes]

This is a good find, @pdkn! But, even though, the bundle will still compile just fine.

[pdkn]

that's right, the bundle compiles fine, but when we run the code in Lambda it errors.

[pdkn]

I can't find any references to "true" = namespaces yet but will keep hunting

[vadimdemedes]

Here's the problem: debug-js/debug#467. The combination of webpack's DefinePlugin and debug fails, because DefinePlugin replaces the code in debug, causing a syntax error. I thought about removing debug anyway, it's not that useful and is kind of annoying to have in library's code.

cc @stephenmathieson @nettofarah @stevenmiller888

[stephenmathieson]

I'm fine with removing debug here

EDIT: I don't think removing debug from this library will fix this issue, since debug is also used by our dependencies. maybe we need to move off of superagent too?

[stevenmiller888]

isomorphic-fetch seems to be all the rage these days.

[stephenmathieson]

isomorphic-fetch leaks a bunch of globals (intentionally). imo this would be an undesirable side effect of using an analytics library

[vadimdemedes]

I'd remove debug and switch from superagent to got - a lightweight and simple HTTP client.

[nettofarah]

+1 to @stephenmathieson's comment.
Got sounds like a good option.
Anything non-global and promise based is a step forward.
Also, +1 for simplicity, so got might be the winner here.

[pdkn]

Was going to mention superagent is a bit of a beast. 'Got' sounds better. I tend to roll my own with vanilla node http & promises. Good article here on dependency tree https://www.tomas-dvorak.cz/posts/nodejs-request-without-dependencies/

[stephenmathieson]

does got work in the browser? many people bundle analytics-node in their client-side apps

[vadimdemedes]

It should work with browserified Node.js modules (like http). Since superagent doesn't crash @pdkn's app, but debug does, the quick solution for their issue would be to only remove debug for now. We can switch from superagent later.

[stephenmathieson]

superagent works because it uses package.json's browser field and ships a completely separate codebase to client-side apps

also, see my edit in #91 (comment); just removing debug won't work

[pdkn]

Bear in mind this lib is called analytics-node. Shouldn't people be using analytics.js for browser?

[stephenmathieson]

I'd agree, but we (Segment) don't have a great solution for people who want to use commonjs/modules for everything, and those who can't dirty the global namespace (what if your company has a "widget" other people use on their sites). using analytics-node works fine in these scenarios.

also, since it works now, it'd be (another) breaking change to drop support for browserify/webpack/etc, which I don't think would be a good move just yet

[vadimdemedes]

Oops, I forgot about #91 (comment). There's a way to workaround isomorphic-fetch's global polluting, so we can use that. Will post more details later.

[pdkn]

For the record I def don't recommend breaking changes for others ;) I hadn't looked at analytics.js and didn't realize it wasn't commonjs/modules. Bare in mind we have a solution at the moment by setting the lib as an external and then copying it into the bundle. (see webpack config zip up the thread). We just want to avoid this step for code hygiene (and so others don't have same issues).
Here's another lightweight http request lib that works node & browser as well as having promises supported - https://github.com/blakeembrey/popsicle

[stephenmathieson]

popsicle is pretty nice for this sort of thing!

[c0bra]

I'm in favor of any of these XHR libraries, but just to throw another name in the ring: I had luck using axios for doing back front and backend requests with the same library.

[stephenmathieson]

@chiplay @pdkn is this still an issue for you? We've removed our dependency on Superagent and I think everything should be working properly now.

[chiplay]

@stephenmathieson not that I've heard of recently - thanks for checking in.

[vadimdemedes]

Closing this since the underlying issue is resolved now.

[vadimdemedes]

No, we're still using debug ourselves.