opentype.js
opentype.js copied to clipboard
opentypejs
Should we create a compatibility focused build in addition to the non-esm build?
There is a lot of IOT devices (like smart TVs) that use old versions of WebKit to run web apps, having a build compatible with ES5 would be helpful for people targeting use cases like this. A secondary build pass with closure compiler on the non-esmodule version would be one way of doing this. The reason why I'm bringing this up is that my current project has support as far back as Safari 5.1 if you exclude opentype.js (due to using closure compiler) but is being limited from being compatible with a lot of embedded/smart devices because of opentype.js's compatibility with older browsers. There are other tools that could do the job other than closure compiler but I'm not too familiar with them. What do you guys think?
Isn't Closure Compiler only for minification? AFAIK you can only specify if the input is to be treated as ES5 or ES6, but I'd be surprised if it actually did any transpilation/polyfilling for the output. I guess we'd need to use Babel or SWC instead.
No, closure compiler does ECMAScript version translation, so for example it pollyfills nullish coalescing when compiling to es5 or es6 which don't support it.
We can also look into SWC. Closure compiler might not be the best option because it requires the syntax to be annotated in a specific way using jsdoc comments, whereas SWC I don't think requires that.
@Connum I'm going to focus on this issue right now and then I'll focus on #677.
That's great! I tried swc on another project and it's quite fast. Will be worth looking into.
And once we are able to get rid of reify, we can finally use the latest ES features (private class fields and methods, optional chaining) during development. 🥳
Okay, so I did get working in a compatibility build and in the regular targets, but I do need to implement a plugin for SWC to translate the spread operator into a more compatible form.