babel-preset-meteor is filled with proposal plugins which have been all turned to standard since ES11.
In the same package, @babel/core is fixed to 7.14.0 released 2.5 years ago.
I’d be ready to test a version of Meteor with these latest tools and push some updates if someone could help me understand the areas that need to be touched to move it to ES14. For the moment I have a local version of https://github.com/meteor/babel-preset-meteor/blob/master/package.json cleaned up of all outdated proposals and filled with the relevant transform plugins (that replace the proposals).
For example in ECMAScript 2022 a top-level await is introduced: “The ability to use top-level await, making it possible to use the keyword outside of an async function”
Ensure the legacy client has babel plugins for all newer ecmascript features
Ensure the modern client has babel plugins for all ecmascript features that are not fully supported by the minimum modern browser versions.
Drop support for browsers that don’t fully support es5. I don’t think Meteor has supported these browsers for years, but there is still code in every Meteor app to support them
We’ve discussed possibly dropping support for old browsers that don’t support es6 classes. This would allow the legacy client to use native es6 classes, fixing a common cause for the legacy client to break. Since the browser versions that supports classes also support many other es6 features, this would allow us to remove many babel plugins and polyfills from the legacy client.
There’s also the ecmascript-runtime-client and ecmascript-runtime-server packages that need to be updated along with the babel packages.
We don’t really have any guidelines on where to put the line between legacy and modern clients. One thing to keep in mind is that many developers don’t test the legacy client so it frequently is broken.
The data for caniuse and mdn support tables has become easily accessible the past few years. We could create some simple tools to help with maintaining this.
The general understanding had been that top level await has to be implemented by the bundler. There have been some exceptions in the last few years, but they all have some requirements or only work with specific bundlers.
The next step is to finish the linker rewrite, and then do something similar with the import scanner to make it faster and more easily extendable. That would allow more of the TLA compilation to be moved from babel to the import scanner where it would only need to be run for the async modules to avoid unnecessarily increasing the bundle size. This is also dependent on dropping support for some very old browsers, so we can either use a simpler way to compile async/await to generators for legacy browsers, or use native async/await.
Unfortunately, I wasn’t able to figure out how to get TLA to work with fibers in Meteor 2 - either we would have a breaking change to make top level fibers code follow the top level await spec, or we would have to make top level await work differently than the spec.
caniuse says async/await is supported by 97.3% of users. That’s much higher than the last time we had discussed this. Compared to requiring es6 classes (supported by 97.78%), requiring native async/await would drop support for these browsers:
chrome 42 - 54
edge 13 and 14
safari 9 and 10
Samsung Internet 5
@filipenevola Meteor had supported old versions of Safari. Do you remember why, and if it is still needed?