Dev Diary #29 - Reviving Sandstorm and Preserving Meteor's Wisdom
So we meet again.
I was prompted to write this month’s dev diary by my recent contributions to Sandstorm, which I’m very proud of. I’m glad my work on WeKan opened the door to reviving more of the tools underneath the Meteor ecosystem.
sandstorm #3780 — Complete the Meteor 3.4.1 migration with Rspack — The work was mostly cut out for me already. Michael Nutt had done the heavy lifting in the original migration PR, so I continued from there while preserving all 33 of his commits and their original authorship.
Many of the earlier decisions were sound too. One particularly good call was replacing iron:router with vlasky:galvanized-iron-router instead of trying to port the whole application to ostrio:flow-router. That kept the migration focused. It also shows that the work people put into maintaining community packages has real merit: without Galvanized Iron Router, this migration would have required several extra steps.
So, shout-out to Vladimir Lasky for his awesome fork.
From there, the PR grew into much more than a version bump. It moves both the Sandstorm Shell and its embedded test app to Meteor 3.4.1 and Rspack, removes old application-level Underscore and jQuery usage, replaces meteor/http and the deprecated npm request package with Fetch, converts the Sass tree to modules, modernizes the Node 22 toolchain, and strengthens the migration and release checks.
The most important part, though, was proving that the migration works. That meant testing fresh installations, upgrading a real build-308 installation through the MongoDB 2.6-to-7 migration path, preserving an existing grain through the upgrade, exercising multi-replica migration coordination, building real SPKs, and running the full native and browser test suites.
It was a lot, but it was the satisfying kind of work where years of community maintenance suddenly click together and make a revival possible.
While working on the migration, I tried to remove jQuery entirely. It has become optional on the Blaze 3.1 line thanks to Blaze’s new native DOM backend, but I noticed that I could not fully remove it because Galvanized Iron Router still relied on it.
So I decided to lend a helping hand and push things further there too.
galvanized-iron-router #7 — Remove jQuery dependency — This PR removes the router’s strong dependency on Meteor’s jquery package and replaces its delegated location events, template insertion, and hash scrolling with native DOM APIs.
It also preserves the little behavioral details that applications may rely on, such as delegated-link currentTarget behavior and proper listener teardown. Tests and the example application were updated to use native DOM APIs as well.
Published Blaze 3.0.3 still requires jQuery, so applications on that version need to provide it themselves. But for applications moving to Blaze 3.1 and beyond, this removes one more thing standing between them and a jQuery-free codebase.
This is one of my favorite parts of migration work. You start by trying to modernize one application, discover that a dependency is holding it back, then improve the dependency so every application after yours has an easier path.
meteor #14593 — Document sharing code between multiple Meteor apps — This is a tiny PR, but it carries a lot of value for those who know the history behind it.
Theodor Diaconu and Cult of Coders were once household names in the Meteor community. They made Meteor a priority, and Meteor Tuts was their internal doctrine for building serious Meteor applications, much like Kadira’s Mantra.
Some of that knowledge has naturally aged. Frameworks change, APIs move on, and architectural advice is always shaped by the constraints of its time. But their approach to reusing the same codebase across multiple applications was nothing short of genius.
The idea is to keep separate Meteor application roots—for example, a customer-facing app and an admin app—while sharing selected domain code through a local package. Collections, schemas, and common methods can live in one place without forcing every application into one giant deployment.
And this is not just theory. I can attest to it from experience. I have used this pattern across multiple applications, and it substantially reduced the amount of code I had to maintain because collections, schemas, and shared methods could all be reused.
The PR brings that idea out of Meteor Tuts and into Meteor’s official documentation, with updated guidance around code-sharing boundaries, shared collections, deployment, schema coordination, and side effects.
Preserving old technical writing does not mean pretending every line is still current. It means recognizing the ideas that remain useful, polishing them, and making sure they do not disappear just because the original source stopped being maintained.
Finally, back to our favorite Meteor testing ground.
wekan #6413 — Update Meteor to 3.5-rc.2 — This PR was part of my effort to nudge WeKan into trying Meteor 3.5. It moved the app from 3.5-rc.1 to 3.5-rc.2, refreshed the Meteor package pins, aligned the Docker and release metadata with the new runtime, and removed a Node 24 release check for an architecture that upstream no longer publishes.
WeKan has been especially valuable in helping us validate new Meteor versions as soon as they come out. A framework upgrade passing its own tests is one thing. Running inside a large, old, actively used application with a wide range of integrations is another.
That feedback loop benefits everyone: Meteor gets tested against real-world complexity, WeKan stays close to current releases, and other applications get a safer path once the rough edges have been found.
Looking back, this month’s work was about revival in more than one sense.
Sandstorm’s Meteor 3 migration was built on top of work that had already been carefully laid down. Galvanized Iron Router gave that migration a practical path forward, then received another modernization in return. A valuable idea from Meteor Tuts found its way into the official documentation. WeKan once again helped test what comes next for Meteor.
Open source progress is rarely a clean line from old to new. More often, it is a conversation across years: someone builds an idea, someone else keeps it alive, and eventually another person finds the right moment to carry it forward.
The community’s old work still has merit. Sometimes it just needs someone to open the door again.