Webpack compatibility about btree-typescript

[qwertie]

This package uses the "module": "umd" option. In my experience - as I wrote in my tutorial on TypeScript including WebPack - the code generated by TypeScript for this is compatible with both Node.js and browsers (provided that the browser provides the necessary require function), and the same can be said for commonjs. (TypeScript cannot produce code that runs in a "plain" browser environment without predefined symbols like "require" or "define", which is really stupid in this particular case, as nothing is imported - as you saw, require is not used.)

My experience may be incomplete. Maybe WebPack supports TypeScript in UMD mode with awesome-typescript-loader but not TypeScript-converted-to-JavaScript in UMD mode, and I only tried the former.

I'm concerned about whether switching to commonjs mode will break any existing users. The WebPack documentation makes it look like UMD is supported - have you tried that libraryTarget: 'umd' option?

[CraigMacomber]

I am using output.libraryTarget 'umd': webpack's output.libraryTarget controls what kind if package webpack generates, not what kinds of modules are supported as input.

As this library is being webpacked along with hundreds of other npm packages, and its the only one with issues, I suspect it has some compatibility problem with webpack.

I'll reach out to one of my teammates with a better understanding of module formats and see if I can get a more confident answer for you. Thanks for your quick response!

[CraigMacomber]

I have some more/better information now.

Users can work around the issue by using https://www.npmjs.com/package/umd-compat-loader. Forcing this configuration on every application that transitively consumes our package (and thus sorted-btree) is a bit unfortunate, but sorted-btree is nice enough that its worth it :)

module: {
	rules: [
		{
			test: /\\node_modules\\sorted-btree\\b\+tree.js$/,
			use: { loader: 'umd-compat-loader' },
		},
	],
},

In general, es6 modules work best with static analyzers like webpack (more explicit dependencies), with commonjs being being the next best supported in webpack. In this case, the difference between commonjs and es6 modules won't matter much (sorted-btree has no external dependencies, so improved dead code analysis shouldn't offer any value), and thus my recommendation would be to go with commonjs (assuming you want to continue supporting users that do not have es6 support).

Moving to commonjs could possible break some consumers, but should mostly work. I understand if you don't want to risk it though: consider including a change to commonjs if you end up having to do other braking changes in a major version update.

Since I have a workaround (and have included it here so anyone else looking for it can find it), feel free to close this issue if you do not plan to make any changes based on it.

[qwertie]

I'm considering switching to CommonJS output. This would seemingly be a downgrade, since UMD is compatible with two module systems (CommonJS and AMD). OTOH webpack is very popular and if it does not support UMD properly two years after I first researched this, perhaps it will never do so and I should just switch. AMD is supposed to be technically better but, reportedly,

AMD’s asynchronous nature remains a theoretical advantage, but in practice, modern module loaders have found ways to solve these problems for CommonJS. Webpack allows configuration options for lazy loading individual modules, and developers using Browserify have found workarounds to the problem. At this point there’s no real difference in the capabilities of AMD compared to other module formats.

Of particular concern is what you said about transitivity... people who use your library would need to do what, exactly?

I have just released v1.4.0 built with TypeScript 3.8.3 - which changes the d.ts file. I remember being unable to use an npm package built with TypeScript above 3.7 on a project that used TypeScript below 3.7, so I suspect this might be a breaking change and I bumped the minor version (1.2.4=>1.3.0).

[CraigMacomber]

Webpack occurs at the application ends of the dependency graphs when actually publishing an application. That means any special config a package needs to webpack correctly will need to be handled by all webpacked applications which transitively depend on it.

For example, in our codebase the package that uses sorted-btree is not directly webpacked, but we have applications in two other repos which use that package, and now they special case sorted-btree to use the umd loader, despite not referring to softed-btree themselves in any other way. If someone else were to use out package in an app, and wanted to webpack it, they would also have to do this.

Thats not as bad as it sounds (we already have several special webpack rules for other things, and already had umd loader, as a dependency for something), but its certainly not ideal.

[qwertie]

Okay, I've pulled the trigger. v1.4.0 is commonjs.

[CraigMacomber]

I have removed the workaround in our code and confirmed it webpacks properly on 1.4.0