A dependency doesn't work in the browser

[Arlen22]

index.js:26 Uncaught ReferenceError: global is not defined
    at index.js:26:3
    at forEachArray2 (index.js:13:17)
    at forEach (index.js:63:9)
    at node_modules/typed-array-byte-offset/index.js (index.js:24:2)
    at __require (polyfill.js:3:50)
    at node_modules/es-abstract/2024/IsTypedArrayOutOfBounds.js (IsTypedArrayOutOfBounds.js:12:28)
    at __require (polyfill.js:3:50)
    at node_modules/es-arraybuffer-base64/Uint8Array.prototype.setFromBase64/implementation.js (implementation.js:12:31)
    at __require (polyfill.js:3:50)
    at node_modules/es-arraybuffer-base64/Uint8Array.prototype.setFromBase64/polyfill.js (polyfill.js:3:22)
(anonymous)	@	index.js:26
forEachArray2	@	index.js:13
forEach	@	index.js:63
node_modules/typed-array-byte-offset/index.js	@	index.js:24
__require	@	polyfill.js:3
node_modules/es-abstract/2024/IsTypedArrayOutOfBounds.js	@	IsTypedArrayOutOfBounds.js:12
__require	@	polyfill.js:3
node_modules/es-arraybuffer-base64/Uint8Array.prototype.setFromBase64/implementation.js	@	implementation.js:12
__require	@	polyfill.js:3
node_modules/es-arraybuffer-base64/Uint8Array.prototype.setFromBase64/polyfill.js	@	polyfill.js:3
__require	@	polyfill.js:3
node_modules/es-arraybuffer-base64/Uint8Array.prototype.setFromBase64/shim.js	@	shim.js:3
__require	@	polyfill.js:3
node_modules/es-arraybuffer-base64/shim.js	@	shim.js:5
__require	@	polyfill.js:3
(anonymous)	@	auto.js:3

[ljharb]

Which bundler are you using?

Any "node module bundler" that doesn't transpile global to window by default is a broken one, and you should file an issue on it.

[Arlen22]

I'm using esbuild. Relevent options are

bundle: true,
target: 'ES2022',
platform: 'browser',
format: "esm",

[ljharb]

I can't speak to the options, but I'd suggest filing a bug on esbuild. A node module bundler MUST transpile global, otherwise it's not a node module bundler.

[Arlen22]

Apparently evanw/esbuild#73 is related.

[Arlen22]

I wouldn't call esbuild a node_modules bundler necessarily. Is there some kind of spec or understood definition of what this entails? If a lot of npm packages expect it, there must be some place where those expectations are listed. At this point, the usage of the node_modules folder doesn't guarantee that the packages installed in it are actually "node modules".

[ljharb]

What is it trying to bundle, then, if not node modules? The entire concept of "bundler" was invented specifically to bundle node modules.

there must be some place where those expectations are listed

Unfortunately conventions frequently exist without being documented. It makes them no less real or important.

[Arlen22]

What is it trying to bundle, then, if not node modules? The entire concept of "bundler" was invented specifically to bundle node modules.

Browser modules? JS files from NPM packages? Why would browser modules be written using code that explicitly breaks in the browser? Do they have some way of declaring themselves so developers know they need special handling to be used in the browser? In the browser, I would naively assume that I can concatenate all imported js files in execution order into a single js file and expect it to work, since that's how browser code normally operates.

Unfortunately conventions frequently exist without being documented.

I suppose then it's inevitable that major packages will be created that aren't aware of these conventions. But I'm pretty sure I've gotten this error when using webpack as well. I'm almost always using custom configs so maybe the conventions were buried deep in plugins that I wasn't aware of.

Any bundler based solely on the language is going to be unaware of these conventions. If they're not documented then it shouldn't surprise anyone when the conventions are forgotten.

[ljharb]

“browser modules” would be just ESM files, with no dependencies (except URL-based modules) and package.json wouldn’t serve much purpose. It doesn’t really make sense to put those on npm, and it definitely doesn’t make sense to bundle them, so that’s not relevant here.

The npm ecosystem has written modules this way (with implicit polyfills) since 2010, when the concept of bundling was invented by browserify. It’s on new tool creators to research the field and interoperate (or not), it’s not on package authors to change the way they’ve always done things.

Any bundlers based solely on the language is going to be largely useless, since the language has no forms of i/o. All of that is environment-specific.

[Arlen22]

“browser modules” would be just ESM files, with no dependencies (except URL-based modules) and package.json wouldn’t serve much purpose. It doesn’t really make sense to put those on npm, and it definitely doesn’t make sense to bundle them, so that’s not relevant here.

I bundle all kinds of stuff into my web apps. Frameworks, client libraries, utility functions. They all have their own dependencies that also have to be installed and deduped. Package managers are very useful here and package.json has a whole slew of browser side additions that various bundlers make use of (perhaps also by implicit convention, I don't know).

Bundling everything into one JS file makes a lot of sense in business apps where I want the full program loaded in one shot so everything can be as responsive as possible. Obviously bundling makes sense regardless because loading hundreds of ESM files on first page load takes forever, creating a terrible user experience.

The npm ecosystem has written modules this way (with implicit polyfills) since 2010, when the concept of bundling was invented by browserify. It’s on new tool creators to research the field and interoperate (or not), it’s not on package authors to change the way they’ve always done things.

I've seen browserify around but never understood or used it. Do they document their implicit polyfills and other node-to-browser conversions? Which bundlers actively support this?

Any bundlers based solely on the language is going to be largely useless, since the language has no forms of i/o. All of that is environment-specific.

Well yeah, it does require the library authors to have separate browser and node exports. It's rare, but this is usually mediated through the "exports" or "browser" property of package.json for cases where the package uses both browser and node platform specific APIs.

Apparently that convention is already well established as I've basically never run into any issues with that other than this global thing that occasionally happens. Most of the time I can find a different package that does the same thing without the error.