Add ECMAScript modules

[graphicore]

Also adds a higher level instantiation module harfbuzz.mjs, usage :

import getHarfbuzz from './vendor/harfbuzzjs/harfbuzz.mjs';
const hb = await getHarfbuzz();

// then use harfbuzz here e.g.:
await fetch('myfont.ttf').then(data=> data.arrayBuffer());
hb.createBlob(fontdata)
// etc.
``

[graphicore]

If there are any questions about this, please ask. For me it's a pain to work around the style of a global hbjs plus commonJS imports and I figured fixing it in Makefile is a good way to go. My use case are web apps built with vite/rollup.

[khaledhosny]

Since I’m the defacto maintainer and I don’t know much about JS, I have to admit I don’t understand how is the module proposed here different from what we already have. I also don’t like that we have to build the same thing twice. If ECMAScript module is better than whatever we have now is called, should we migrate wholesale than having to support both?

There is also #99 which I don’t know if it overlaps with this in anyway.

[lianghai]

@khaledhosny, ESM (ECMAScript Module) is the modern format these days, but the legacy CommonJS format is still commonly supported by library authors, though more and more libraries have stopped providing the CommonJS format. There’s an article about how to decide to go ESM-only: https://antfu.me/posts/move-on-to-esm-only.

The #99 discussion is more about how to move this library to TypeScript, though that change would naturally also bring in some modern bundling tooling and generate the ESM format.

[khaledhosny]

OK, I’ll need to research this a bit more. But I see the potential of fixing #99 and switching to the new modules at the same time and be a one big breaking change. I understand the need here, but I’d like to do it the proper way and cleanup this repository instead of adding another hack to the pile.

[khaledhosny]

I might or might not be able to work on this, and any one else is welcome to beat me to it. Otherwise, I’d like to hear from people who use this library who are more familiar with javascript, what is the ideal API for them as we are going to be breaking things, so now is a good time to clean the API as well.

[graphicore]

Typescript is agnostic of the module style, it just inherits it from Javascript. With Typescript, an ESM style file often uses .mts, analogue to .mjs, as an extension. Typescript is basically just static types sprinkled over Javascript, e.g. Vite, which I mentioned before, is not even checking the types before before transforming a TypeScript module to Javascript, it just removes/transforms the extra syntax. So, I don't think TypeScript is very relevant when talking about module styles.

Additionally to what @lianghai said, many projects ship all flavors of modules sometimes plus typescript. ES-Modules are the IMO the best practice approach for web app development, while "global scope pollution"-style can be nice for a quick start but is a technical debt on large projects. Also, ESM is the standard.

I'd also be interested on more views.

What kind of work is required to move this forward?

[lianghai]

For projects that require a building step (especially libraries written in TS), different formats are usually handled by the bundler (eg, https://tsdown.dev/options/output-format). This is why it’s easier to consider the CommonJS vs ESM situation once we have more clarity about #99, otherwise this is just additional manually maintained bundling logic that will soon be replaced by what the bundler does.