Webpack 5 compatibility

[pluma]

Webpack 5 no longer automatically polyfills node core modules. Some other compilers probably don't either. We currently rely on webpack 4 to do this for our web build but going forward it would probably be best to avoid unnecessary polyfills altogether.

The best course is probably to extract the node core module specific helpers into utility modules and provide web-compatible alternatives as we already do for other idiosyncrasies like XHR.

[lostpebble]

I'm guessing this is also related to why I can't use ArangoJS with Cloudflare workers? Since they basically run in the context of a Service Worker, and can't make use of any native Node core modules stuff.

This is really an important requirement then, I think if the library has no requirements on Node.js itself (why would it?) then its important that it doesn't rely on only being run in that execution environment. This is a big blocker for me.

[EDIT]

Actually the main issue I'm running into now, after deploying to cloudflare workers to test ArangoDB with basic authentication, is that this relies on window.btoa and window isn't available in the context of a Service Worker either.

But again, that means the code of the library is assuming and relying on a specific context.

Unless I'm mistaken and I've done something wrong along the way while packaging things.

[pluma]

@lostpebble ArangoJS comes in two flavors: server (node) and browser. CloudFlare Workers seem to be different from both.

CloudFlare Workers support the Fetch API, which is originally a browser API but not currently used by the browser build of arangojs and unavailable to the Node version. To answer your question ("why would it?"): arangojs handles binary data and performs network requests. These things require APIs that are not part of the JS language spec but the respective runtime environment APIs (native Node core modules, or browser APIs).

This issue is about compatibility for the web version to swap out some of the currently polyfilled Node core modules (like URL parsing helper functions) with the web equivalents at build time by wrapping them in helper files with web and node versions. It seems to me that CloudFlare would represent a third target as it is neither Node nor a browser.

[pluma]

I don't know how soon I can find time to address these compatibility issues and upgrade to webpack 5 but since I have no experience with CloudFlare Workers, my suggestion would be that you could look over the changes when they're ready and tell me if you see an easy way to make the browser version support the CloudFlare Workers API.

[lostpebble]

Okay cool, I'd be happy to take a look and see.

I think, for the browser build, if you made use of the Fetch API for requests and if you first checked if something is available in the "global" space- such as btoa (which is available in Service Workers globally) before defaulting to window.btoa- it might already solve a lot of the issues.

[pluma4345]

I'm closing this as 8.0.0-rc.1 uses Webpack 5 and the smoke tests succeed.