x ‘eval’ and ‘arguments’ cannot be used as a binding identifier in strict mode
If you rename arguments to args, it passes the SWC syntax check. In strict mode, eval and args are reserved identifiers. Though, that seems to be within the blaze package? If that is, could you provide a PR fixing this?
Also it seems that the owner of ostrio:flow-router-extra and montiapm need to fix these:
Yes, if you can report to those repositories or fix these in a PR it would be great.
Verbose mode lets you check SWC compatibility with your project and ensures you fix all fallbacks using this mechanism.
When we deliver the Meteor-RSPack integration, which uses SWC to transpile and bundle your app code, your project will need to be fully compatible with SWC since RSPack likely won’t offer fallbacks. In Meteor 3.3 modern build stack, you can keep Babel fallbacks for the few affected files and still get good performance. If you want the full benefits of the future modern bundler integration, start preparing now.
I see that oxc.rs is not mentioned in this forum at all, and also not compared at swc.rs (or mentioned anywhere on the SWC website). Was oxc considered at all in this iteration of Meteor? Will it be in the future? Why? Why not?
There are always new tools araising, known or unknown. Honestly, this is the first time I’ve heard of Oxc transpiler.
One immediate reason for not including it is that it’s still in development. For example, we’ve reworked the minifier, but Oxc doesn’t have its own implementation yet.
There are other points we could discuss. SWC is the most popular and supports many Babel plugins after years of work, which makes integration straightforward. It’s also used in Meteor packages like zodern/minify-js-sourcemaps, and it’s already built into bundlers such as Rspack and Vite, with most issues solved, ensuring proper development for production envs.
I think we should stick with tools that are mature enough for smooth adoption. SWC meets that bar. I still see some gaps in Oxc (minifier, supported plugins, and much more), but if it closes them and keeps a Babel-compatible API, we can revisit switching.
Anyway, our work integrating SWC is public via PRs to guide other adopters (mostly on babel-compiler package). If anyone wants to test a different tool, just open a PR replacing SWC references with the new tool and measure stability and performance. I think Oxc will give us problems nowadays at first glance, but maybe someone could fix those limits and prove it’s convenient.
We’re currently root causing an issue we’re having where after upgrading to 3.3, the mobile app is not loading / HMR is not pulling the latest from the server. I’ll report back when we know more.
EDIT:
Other findings:
The mobile app icons don’t seem to be pulling in correctly anymore
Apologies for not getting back. We found the issue was related to a mutation observer trying to attach document.body before it was available, which only happened on iOS! We fixed our bug and the app is working fine now.
We have occasional issues where images and other resources don’t load in the mobile apps, not sure if anyone else has experienced that with their apps.
We have been running 3.3 in production all day! Going smooth so far
Amazing work Nacho. I’m glad you were to able to carry the torch and start working deeply with Meteor internals.
After years and years of work. Meteor is finally starting to catch its breath no longer bound by maintenance work but rather actively working to improve it. I’m super super glad that I get to witness this and even the upcoming work.
I think it’d be great if you can present a talk about this work in the upcoming Meteor Impact. Because I feel lost a bit: bundler, transpiler, zodern:standard-minifier-js, reify, vite, swc, babel, rust?? What’s Meteor made of on a low level? How does it take your code and what stages does it go through till it reaches the deploy-able version? Does Meteor offer source-maps as a built-in feature now?? So many questions. I really hope your work is not only documented but also transferable to a future generation of core Meteor devs.
Thank you for this amazing release, I updated two codebases and indeed saw a 50% improvement in app startup time for development !
Looking forward to using meteor build to deploy and compare build times with the previous version!
