build: use Ably as UMD lib name

[owenpearson]

Fixes a regression in which, when using UMD without commonjs/amd, the esbuild UMD wrapper would add each named export of ably to the global namespace rather than adding it in an object called Ably (as it did in v1).

[VeskeR]

esbuild-plugin-umd-wrapper outputs different UMD wrapper code for AMD resolution when libraryName option is provided compared to what webpack does on our v1 branch. That causes all our browser tests to fail with errors like: "TypeError: Cannot read properties of undefined (reading 'Ably')"

webpack from v1 branch (build/ably.js):

...
else if(typeof define === 'function' && define.amd)
	define([], factory);
...

esbuild-plugin-umd-wrapper with libraryName: 'Ably' from this PR (build/ably.js):

...
} else if ("function" == typeof define && define.amd) {
	define("Ably", [], f);
}
...

Note the difference for AMD resolution (define function call):
Webpack defines "anonymous" module, just define([], factory);
esbuild-plugin-umd-wrapper plugin defines a named module define("Ably", [], f);

This causes all browser tests to fail.
I'm not sure how exactly named modules in AMD behave, and I couldn't find any meaningful explanation of this feature. Seems like it's not recommended to use named modules anyway, and we should stick to how it was done in v1 to avoid problems.

There doesn't seem to be an option to change this behavior in esbuild-plugin-umd-wrapper.

@owenpearson WDYT?

[VeskeR]

I've created a fork of an esbuild-plugin-umd-wrapper plugin that would allow us to not name our AMD module, thus preserving the behavior we had on v1 branch using webpack.

To use it, we need to change dependency line in package.json to:

"esbuild-plugin-umd-wrapper": "ably-forks/esbuild-plugin-umd-wrapper#1.0.7-optional-amd-named-module",

and this line to:

plugins: [umdWrapper.default({ libraryName: 'Ably', amdNamedModule: false })],

@owenpearson let me know if you want me to push those changes to this PR (and also resolve conflicts with integration/v2 branch, since it got updated a few times since this PR was opened)

[owenpearson]

@VeskeR, nice one, thanks for not only identifying the issue but also creating the fork to fix it! If you're happy to update the PR and resolve conflicts too that would be amazing 🙂