Small server runtime modernization PR (if you want)

core
1

Hi folks,

This sunday I went down the rabbit hole of Meteor’s server runtime, bundle format, and boot sequence, an area I still felt weaker on and wanted to understand better because why not ? :man_shrugging:

After reading through the code, sketching a few diagrams, asking Claude way too many questions, and sanity-checking some ideas with ChatGPT, I ended up spotting a few places where the current server runtime still reflects older Node-era constraints, even though modern Node now gives us better native tools for some of these cases :+1:

So I’m starting a small PR series focused on a few very small, pragmatic cleanups in the current Node server runtime :smiling_imp: changes that seem useful on their own, with a good signal/risk ratio, and that should be easy to review independently :pray:

The goal is simple: make a few parts of the current runtime a bit more modern, a bit less fragile, and a bit easier to reason about.

First PRs

  1. Add sourceURL pragma to vm-evaluated server packages
    PR: Add sourceURL pragma to vm-evaluated server packages by dupontbertrand · Pull Request #14282 · meteor/meteor · GitHub
  2. Lazy-load cluster in webapp when UNIX_SOCKET_PATH is used
    PR: Lazy-load cluster in webapp when UNIX_SOCKET_PATH is used by dupontbertrand · Pull Request #14283 · meteor/meteor · GitHub

Validation so far

I validated both changes locally. Current results:

  • sourceURL pragma present in modified bundle
  • baseline and modified bundles boot and return HTTP 200
  • stack traces captured successfully in both bundles
  • stack trace attribution remained equivalent in my local check
  • UNIX_SOCKET_PATH still works
  • meteor run still boots correctly

I’ll use this thread for any broader discussion/questions about the overall direction, so the PRs can stay focused on the diffs themselves :blush:

Thanks!

2 Likes