Exploring an ESM server bundle format for Meteor (meteor build --format=esm, Node + Bun)

core
1

Hi folks,

Quick disclaimer before anything else: this whole experiment was 100% vibe coded :sweat_smile:
So please read this as an exploratory fork / prototype branch, not as a polished proposal or production-ready implementation.

We’ve been exploring whether Meteor could generate a more standard server bundle format instead of always going through the current main.js -> runtime.js -> boot.js path.

What started as a Bun experiment turned into something more interesting:

not “can Bun emulate old Node internals well enough?”
but
“can Meteor produce a built server bundle that modern runtimes can execute more directly?”

So we built an experimental fork branch that adds:

meteor build --format=esm --directory ../output

Branch:
https://github.com/dupontbertrand/meteor/tree/spike/esm-bundle-format

All the .md files created during the brainstorming / prompting / architecture exploration are also in the fork here:
https://github.com/dupontbertrand/meteor/tree/spike/esm-bundle-format/meteor-sandbox/migration-bun

This generates an experimental ESM server bundle path with index.mjs, instead of the legacy server entrypoint chain

What was validated

We first built a manual spike, then integrated it into the bundler, then closed the loop with validation

Current status:

  • legacy meteor build output remains intact
  • --format=esm reproduces the spike behavior
  • Node runs the generated ESM bundle
  • Bun runs the generated ESM bundle
  • HTTP works
  • Mongo works
  • DDP works
  • accounts-password works
  • reconnect works
  • short soak test passes

We also added consolidation tests, and the current result is:

13/13 passed on both Node and Bun

Most important finding

The main result is not “Bun is faster”.

The main result is:

the server bundle format can be moved toward a more standard loader path without rewriting all of Meteor.

And for Bun specifically, the real runtime-specific seam turned out to be:

  • server host
  • DDP transport

not the package bundle itself.

What this is not

This is not a proposal to merge Bun support into core tomorrow.

It is also not a claim that the current experiment is production-ready.

This is an experimental fork proving that:

  • Meteor can generate an alternative server bundle format
  • Node and Bun can both execute it
  • the long-term seam is probably bundle format + host/transport abstraction, not “make Bun emulate every historical Node behavior”

Why this seems interesting

Even if Bun support never ships, this still seems useful because it suggests that Meteor’s current server runtime shape is not the only viable one anymore.

In other words:

this might be less about “Meteor on Bun”
and more about
“Meteor with a more standard server bundle format”

Next step

At this point the experimental branch and validation loop are done

The next logical step would probably be deciding whether this is worth:

  • keeping as a fork experiment,
  • turning into a more formal RFC-style discussion,
  • or exploring further around the bundle format / host seam.
1 Like