I have been using Biome and have been pretty happy with it.
OXC seems to me to make sense if Meteor was going towards the Vite ecosystem, but currently it is not. It could still be adopted and I have heard that it might eventually kill Biome. That said its parses is still in Beta.
@italojs still worth looking at OXC, maybe we should think about making the structure so that if needed we could switch with minimal effort.
not yet, we can discuss it better and choose togheter, I’ll take a look into oxc 
Somewhat related but:
What is the state of typescript and type generation for meteor packages?
I’m not familiar with it meteor package development, but is there “tsup” or “tsdown” equivalent for meteor packages?
From what I recall, atm the current state is still the one described in the docs:
We plan to give some love to this soon.
It is in our roadmap: Roadmap | Docs
On a macro level this is a good step for Meteor but on a micro level this still needs some refining. Biome and OXC got mentioned but no https://rslint.rs/
Actually we’re in a bit of a conundrum post 3.4. Do we double down on the entire RS stack or only keep what’s useful? @nachocodoner
I think this would be a good opportunity for Meteor to issue a standardized linting guide as the current eslint ones have fallen out of favor. meteor/npm-packages/eslint-config-meteor at 86a32d99841e682fc23e52bb58f30ee0e8a88fc1 · meteor/meteor · GitHub
Good call. With RSPack integration it makes more sense to integrate further with RS ecosystem.
And this is why a public discussion helps a lot. The original decision is not to implement this directly with a closed decision, but to discuss it with the whole community. Many eyes are better than a few.
About using rslint, I would not necessarily encourage us to use the whole Rust ecosystem as the main reason. It is true that it has benefits, and we have already done that with Rust through SWC and Rspack, but for instance rslint is not even stable yet. It is still in early development. So it is important to understand the project’s current status and what limitations we would have.
According to rslint, it claims compatibility with most ESLint and TypeScript-ESLint configurations to reduce migration costs, and it ships with existing TypeScript-ESLint rules and widely used ESLint rules out of the box. It also delivers 20-40x faster linting than traditional ESLint. It is currently in an experimental phase, but under active development. The latest release is v0.2.3 from last week. So it seems promising and active.
Anyway, the Meteor codebase currently does not have a well-applied linter strategy, so starting with one, even something as simple as rslint, is already better than having nothing at all. We can try reusing ESLint definitions and see what happens, or start fresh with what rslint supports at the moment. Since this is an incremental effort, adoption can also move together with rslint as it matures toward more stable versions.
I tend to favor the stacks we have already invested effort in. To me, it seems like a good choice to grow with it together with the other Rspack tools and future collaborations in the same ecosystem. But I also understand that if we find strong limitations, or signs of inactive development, we should choose something else. In this specific moment, I do not think that is the case, or at least not until we have more practical experience with it.
Also, more than the specific tool to use, this is about enforcing a convention and guidelines for the core and Meteor contributors. So it is more about creating a habit and a standard. The tool is important, but if we stay within the ESLint compatibility and standards umbrella, moving and migrating across tools will be easy.
I just noticed in the README that it’s actually written in Go so we can’t adopt it! u.u
Jokes aside, here is my take:
IMO unfortinately we don’t currently have capacity enougth to support another tool and While it’s a cool project(i’m really curious to contrib into rspack ecosystem with rust), it would distract us from Meteor, which already requires a lot of our attention.
Biome looks like more plug and play while oxc is more “low level”, btw biome uses oxc:
The resolution of the dependencies is powered by the library oxc-resolver, one of the many libraries provided by the OXC project. It’s battle-tested and spec compliant!
Second Perplexity, OXC is more for our case, but idk, still thin the simpler is better
Practical recommendation
• If you just want to replace Prettier + ESLint in a product repo with minimal fuss and good editor behavior, Biome is the safer, more ergonomic choice today.
• If you are building tooling (bundlers, custom compilers) or want to bet on a unified, ultra‑fast Rust toolchain (transform/minify/resolve, not just lint/format), leaning into Oxc (Oxlint + Oxfmt + parser) makes more sense.
Biome is very opinionated by default, something many of us wished Meteor to be (again). At the same time, biome rules comply with rspack requirements. To me the biggest pro biome point is, that it’s not only a linter but also formatter and extends beyond js, if desired.
I researched OXC a bit, and it seems it could be the tool that best fits us now and later. It implements many components, all written in Rust, that could be useful not only to ensure linting and formatting, but also as tools that can be used as part of the bundler to get more out of it.
As you know, we adopted Rspack in Meteor 3.4, which uses SWC via builtin:swc-loader. The builtin: part means SWC runs entirely inside Rspack’s Rust process with no JS bridge overhead. Rspack has shown some interest in OXC recently. It used OXC’s resolver but later forked it, and community packages let you use OXC as a transformer (oxc-webpack-loader or unplugin-oxc), but they lose the builtin: advantage through the JS bridge. Rspack’s 2.0 roadmap does not mention OXC for core transpilation, and the team seems more inclined to build its own tooling. It could happen that other tooling like Rslint use directly OXC at some point. Deeper integration may or may not happen, but at least there have already been moves toward its benefits in some bundler parts.
Worth noting that Rolldown, Vite 8’s bundler, already bets on this fully, using OXC for parsing, transformation, and minification. This is where toolchain fatigue feels real. Babel to SWC was 20x faster. Webpack to Rspack was 23x faster. Now OXC is apparently 3x faster than SWC. Each leap is meaningful, but none of them are just optimizations. They are architectural rewrites that result in better memory allocation, unified ASTs, and tighter coupling from day one. A newer tool starts with the lessons of the previous one, and the cycle repeats.
That makes doing this at the Meteor level worthwhile on its own. By adopting it as the linter, it would be good to start experimenting with the tool. It may or may not become part of Rspack at some point, officially or through the community, as already happens today. If it really claims to be faster and users can measure that, it can be a tool ecosystem worth investing resources in. I can also see OXC being part of Meteor atmosphere package processing as a replacement for SWC, to theoretically gain 3x faster builds in package compilation or in Meteor apps using the pure bundler. I am not sure yet about SWC/Babel plugin support for the transpiler, though. Anyway, for the moment, and seeing how quickly the ecosystem evolves, that 3x gain may not be worth it yet. We could wait and see what direction Rspack takes regarding OXC adoption before making a core decision.
With this, I just want to say that OXC is a really interesting tool that we could explore and gain experience with for later benefit, even for Meteor core integration. I remember some community member already shared it before or even opened a PR recently adopting the parser (experiment(isobuild): Isobuild Performance Optimizations by mvogttech · Pull Request #14218 · meteor/meteor · GitHub), so now that we have the chance to adopt it, I would go with it.
So after all this discussion, my preference would be to focus on adopting OXC as the linting and formatting tool, with the possibility of benefiting from other areas it touches later, and knowing it’s the approach followed by Vite’s next-gen bundler.
What do you think?
I opened the Isobuild experiment PR – I chose to implement OXC during my experiment to modernize the build tool because of Vite’s adoption.
Let’s vote and hit the hammer
I appreciate all the work y’all have put into making Rspack work with Meteor. Fwiw, it seems to me OXC / Vite ecosystem is the better long term bet.
It can be. When integrating Rspack, Vite did not look promising, neither in speed nor in how easy it was to integrate and make it work smoothly with the Vite-Meteor HMR server, without hard rewrites to perserve Meteor’s specifics and similar changes. I talked about it in this Twitter thread: https://x.com/nachocodoner/status/2022270373216108945
In parallel, Vite v8 has made huge efforts to add Rolldown and integrate the OXC ecosystem. So the approach followed with Rspack for a smoother and easier integration could be revisited, and it may be possible. Anyway, Meteor 3.4 was focused on making sure we got the gains the community wanted so their apps could evolve on the bundler side. That was the best reason to move forward, making sure we could deliver the best speed, but also all the other features around it. Rspack passed that test easily.
Anyway, we will see what the future brings to the JS ecosystem. The fatigue and hype around tools is real. Every time, a new tool appears that beats the previous one in speed, resource usage, or features. It’s crazy.
Nowadays we are in a really good spot on bundler features, but it’s good to see opportunities on the horizon. More importantly, what matters is how easily those tools can be integrated with Meteor’s specifics.
Maybe at some point, once we are further along with the next roadmap items (native, ddp, testing infra rework, core code quality and so on), we can see whether Vite v8 with its latest improvements could be an Atmosphere package option like rspack, mirroring the approach of this package but with Vite.
JS fatigue is definitely real 
. Feels like it’s been this way for ~15 years or so.
Don’t worry just 10 more years and it’ll be fixed… maybe… hopefully 
FIY: I’m preparing a PR with the base OXC config where we will be able to discuss about the best formatting config
[edit]
Invite all to review and let your comments and preferences
Phase 1 PR
| Package | Subphase A | Subphase B | Subphase C |
| mongo-decimal | | | |
| xmlbuilder | | | |
| bundle-visualizer | | | |
| facts-base | | | |
| facts-ui | | | |
PHASE 2 PR
this one will demand a better testing and review attention
Low-complexity packages with no critical runtime dependencies.
| Package | Subphase A | Subphase B | Subphase C |
|---------|------------|------------|------------|
| base64 | | | |
| binary-heap | | | |
| diff-sequence | | | |
| callback-hook | | | |
| ejson | | | |
| id-map | | | |
| ordered-dict | | | |
| rate-limit | | | |
| retry | | | |
| logging | | | |
| session | | | |
| test-in-console | | | |
| webapp-hashing | | | |
Note, that I opened an issue in the Blaze repo, because we should decide for a code quality tool there as well. My personal point here is, that we should go with whatever will be used in Meteor Core.
From what understood this will definitely be OXC, right @italojs ?