Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Should we create a compatibility focused build in addition to the non-esm build? #619

Open
ILOVEPIE opened this issue Oct 4, 2023 · 8 comments · May be fixed by #693
Open

Should we create a compatibility focused build in addition to the non-esm build? #619

ILOVEPIE opened this issue Oct 4, 2023 · 8 comments · May be fixed by #693
Labels
enhancement Needs Investigation question

Comments

@ILOVEPIE
Copy link
Contributor

ILOVEPIE commented Oct 4, 2023

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?
@Connum
Copy link
Contributor

Connum commented Oct 18, 2023

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.

@ILOVEPIE
Copy link
Contributor Author

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.

@Connum
Copy link
Contributor

Connum commented Oct 18, 2023

Interesting, I didn't know that!
If we can better support, I'm all for it!

@ILOVEPIE
Copy link
Contributor Author

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.

@ILOVEPIE
Copy link
Contributor Author

@Connum I'm going to focus on this issue right now and then I'll focus on #677.

@Connum
Copy link
Contributor

Connum commented Mar 27, 2024

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. 🥳

@ILOVEPIE
Copy link
Contributor Author

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.

@ILOVEPIE
Copy link
Contributor Author

I might just be missing an input into the target. I'll have to check.

@ILOVEPIE ILOVEPIE linked a pull request Mar 31, 2024 that will close this issue
Open
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Needs Investigation question
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Switch from Reify to SWC for ensuring compatability with older browsers. SABRE-JS/opentype.js
2 participants
@ILOVEPIE @Connum