🐛 BUG: Usage of "typeof module" causes error "The uploaded script has no registered event handlers. [code: 10068]"

[paul-go]

What version of Wrangler are you using?

2.0.25

What operating system are you using?

Mac

Describe the Bug

Attempting to deploy the following code causes the error:
"The uploaded script has no registered event handlers. [code: 10068]"

"use strict";
addEventListener("fetch", () => { });
typeof module;

Commenting out the last line causes the deployment to function as expected:

"use strict";
addEventListener("fetch", () => { });
//typeof module;

EDIT: Seems the same thing is happening if I change the variable after typeof to exports. Is this thing specifically trying to prevent me from detecting Node.js vs Cloudflare?

[kimyvgy]

I got the same issue after integrated @apollo/client into my project.

It seems due to typeof module statement.
https://github.com/benlesh/symbol-observable/blob/master/es/index.js#L12

// node_modules/symbol-observable/es/index.js
var root;
typeof self < "u" ? root = self : typeof window < "u" ? root = window : typeof globalThis < "u" ? root = globalThis : typeof module < "u" ? root = module : root = Function("return this")();
var result = symbolObservablePonyfill(root);

I can use wrangler to deploy my project successfully if I replaced typeof module < "u" to false:

// Deploy successfully
// node_modules/symbol-observable/es/index.js
var root;
typeof self < "u" ? root = self : typeof window < "u" ? root = window : typeof globalThis < "u" ? root = globalThis : false ? root = module : root = Function("return this")();
var result = symbolObservablePonyfill(root);

[cameron-robey]

This is due to the way we handle the two types of worker formats.
Currently we "guess" which type of worker we have - and if we find exports we assume it is a modules worker.

From packages/wrangler/src/entry.ts line 133:

/**
 * A function to "guess" the type of worker.
 * We do this by running a lightweight build of the actual script,
 * and looking at the metafile generated by esbuild. If it has a default
 * export (or really, any exports), that means it's a "modules" worker.
 * Else, it's a "service-worker" worker. This seems hacky, but works remarkably
 * well in practice.
 */

For now you can bypass this "guessing" by using the command line flag --no-bundle.

Will discuss with the team about a potentially "better" way of detecting the type of worker to handle situations like this.

[0x15f]

Is there any update on this issue? Encountering it using toucan-js and @cfworker/sentry, using the --no-bundle flag does not seem to make a difference.

[jimmed]

I'm also experiencing this issue, and it seems to be a bug in Wrangler itself.

By inspecting the outputs of esbuild.build in guessWorkerFormat, it seems like esbuild is appending the following:

export default require_build();

Thus, wrangler detects that I have a default export, and incorrectly assumes that I am using module worker syntax.

I believe this is happening, because esbuild is being run with format: "esm", so it wraps the bundle in a __commonJS({ ... }) interop wrapper, and exports that as default:

var __getOwnPropNames = Object.getOwnPropertyNames;
var __commonJS = (cb2, mod) => function __require() {
  return mod || (0, cb2[__getOwnPropNames(cb2)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
};
var require_build = __commonJS({
  "build/index.js"(exports, module) {

    // ... my bundled code here ...
    
  }
});
export default require_build();