✅ Deploy Preview for v3-meteor-api-docs canceled.

✅ Deploy Preview for v3-migration-docs canceled.

@Grubba27 can we get a beta release of this package to see if this helps to solve the issue from #13272 ?

My full-app test run is getting an aggregate error: ETIMEDOUT on both 172.67.137.45:443 and 104.21.26.159:443, and ENETUNREACH on both 2606:4700:3035::ac43:892d:443 and 2606:4700:3037::6815:1a9f:443. (The latter two are because AT&T is bad at being an ISP and I don't have IPv6 access.)
edit: it seems to happened at extracting bootstrap, which is fun because I have to manually set the jquery version in my app to match the one in the non-core package, which doesn't match the one bootstrap thinks it supports.

It seems like that was an intermittent Cloudflare issue. Unfortunately it didn't fix the issue from #13272; I still got

 Class private methods are not enabled. Please add `@babel/plugin-transform-private-methods` to your configuration.

on an imported node module.

Does the meteor preset replace the babel default preset? babel/babel#13091 added private methods to the babel preset for 7.14, but if the meteor preset replaces that then maybe you have to add the plugin, even if it should be a no-op for the versions of node the app would actually run on.

Seems like Babel added a targets option to their config stanza (https://babeljs.io/docs/options#targets) and it doesn't seem to be set in https://github.com/meteor/meteor/blob/018371ef65facdc0dc8eaf22e71af417ce483e1e/npm-packages/meteor-babel/options.js so babel will always target ES5. (Although I'm also confused about what's happening with the finish function, because it seems like an object with presets and plugins keys gets created, then wrapped in an array, and that whole array gets assigned to presets in finish.)

This update looks simple but needs extensive checks. In the past, there were attempts to update babel-preset: #13193, #13171 and #13510.

When upgrading babel presets, we must review all changelogs for independent plugins (or global @babel/preset-env), apply migrations, update Meteor’s Babel configs and adjust settings. Then run tests and verify that Meteor apps still build. To do this, we need to publish npm updates for libraries like babel-preset-meteor, @meteorjs/babel and babel-compiler; and all dependent each other. Without a local testing approach for npm packages depending on Atmosphere, testing requires remote publishes, which makes upgrade process unfun.

In the past, the core team and contributors like @9Morello tried a refactor, revealing our lag on newer Babel syntax. We shipped Meteor 3.3 with SWC, a modern transpiler that stays current. We’ve delayed internal Babel upgrades because they touch many areas and require config refactors and deep testing. With limited resources, we can’t tackle Babel now.

I think we either need to put this Babel issue on the roadmap or move completely to new compilers that won't have such a high maintenance cost. The issue with outdated use of Babel is cropping up in many places in the codebase.

But I agree SWC and modern build tool takes priority.