Dev Diary #28 - Meteor 3.5, User Status, SimpleSchema, and More Ecosystem Gardening
This month felt like ecosystem gardening.
Not the loud, dramatic kind of OSS work where you land one huge PR and call it a day, but the quieter kind where you notice a package is stuck, a workaround is sitting in an app, a release is almost there, or a migration is 90% done but still needs someone to push it across the line.
And as usual, once you pull one thread in the Meteor ecosystem, you end up finding five more.
jam:offline #28 — Fix debug suppression when message is missing — I noticed while checking the WeKan changelog that they had implemented a temporary band-aid fix to work around an issue with jam:offline.
The bug itself was refreshingly tiny. The package was doing s?.message.includes(...), which still crashes if s exists but message does not. The fix was simply completing the optional chain: s?.message?.includes(...).
Tiny fix, but useful. These are the exact kinds of papercuts that should live in the package instead of forcing downstream apps like WeKan to carry local patches forever.
Next up was meteor-user-status.
I noticed a bit of action going on around the package, so I decided to help push things forward and wrap it up.
meteor-user-status #183 — Meteor 3 — This PR had been open for a long time, and it was one of those cases where the work was largely there but still needed that final nudge: async updates, dependency cleanup, tests, and release prep.
While working through it, I noticed that meteor-user-status also depends on meteor-timesync, so that had to be tackled too. One package led to another, as is tradition.
The good news is that both packages now have full releases:
mizzao:[email protected]mizzao:[email protected]
meteor-timesync #60 — Meteor 3 compatibility release — This is another big step for a quintessential Meteor package. meteor-timesync is one of those packages you may not think about every day, but plenty of other packages rely on it quietly in the background.
Getting it properly released for Meteor 3 removes one more blocker from the migration path.
Then came Meteor 3.5.
I’ve been anxious for 3.5 to be fully released. It has been in the works for quite a while, and in a sense it had become a blocker for other PRs and downstream work.
So I did what I do best: nagging!
In the Meteor 3.5 release PR, Italo pointed out that we needed to wait for it to be cleared by WeKan, especially given the last round of bugs reported there.
And honestly, dare I say I’m glad WeKan has become a testing ground for new Meteor releases? Kudos to Lauri for doubling down on Meteor and being ready to test things with his amazing product. Large real-world apps are where frameworks either prove themselves or get exposed, and WeKan has been doing a lot of useful exposing.
So I quickly drafted:
wekan #6362 — Upgrade Meteor to 3.5-beta.12 — This bumped WeKan from [email protected] to [email protected], updated the Meteor package pins, and updated the Docker build default. The goal was to test the latest beta without changing the existing DDP transport or reactivity defaults.
Then Italo joined the fray with:
wekan #6365 — Update DDP transport and reactivity order for multi-tenant deployment — This restored uws and changeStreams,oplog,polling as the recommended defaults after the Meteor-side fixes landed. It also added multitenancy Docker docs and examples for running several Wekan tenants on one host.
This was a masterclass in OSS collaboration. Someone reports a real-world issue, core fixes it, the app tests it, then the defaults and docs get cleaned up. I’m really fortunate to be part of Meteor.
Do you believe in miracles?
Thanks to Dr. Dmitry, you should. At least in resurrection!
Meteor-logger #24 — Update package for 3.0 — I submitted this PR ages ago and had honestly long forgotten about it. It updated ostrio:logger for Meteor 3, removed the old underscore dependency from tests, and added CI.
Then, out of nowhere, it finally got merged.
This is one of the funny things about OSS. Sometimes a PR dies. Sometimes it sleeps. And sometimes, after enough time has passed, it wakes up and gets merged like nothing happened.
Now onto the schema side of things.
meteor-simple-schema #756 — Prepare full async SimpleSchema 3.0 release — SimpleSchema, the cornerstone of any self-respecting Meteor application, got a new release.
This PR brought together the async work from several previous efforts and prepared the full 3.0.0 release. The important bit is that aldeed:simple-schema is now much more async-friendly, with promise-based clean and validate flows, async autoValues, async custom validators, and updated tests.
This PR also had a nice little interaction that got me thinking about OSS and what it actually means to preserve people’s work properly.
The short version: sometimes the code is not the only thing that matters. The ancestry matters too. The people who did the earlier work matter. Making sure the final PR carries that history forward is part of doing OSS properly, not just a nice extra.
More on that later, maybe.
Since SimpleSchema got fully released, I thought it was time to move into the murky waters of Collection2.
meteor-collection2 #447 — Add support for Zod v4 — Collection2 has always been tightly coupled to SimpleSchema, which made sense historically. SimpleSchema is deeply tied to Meteor culture, and for years it was the obvious default.
But the JavaScript ecosystem has moved a lot since then. These days, people also reach for Zod, AJV, and other validation libraries. So this PR helps Collection2 take a step toward a more flexible future.
The new 4.2.0 work adds support for Zod v4 schemas, AJV-style JSON schemas, schema adapters, and schema type detection. SimpleSchema remains the compatibility path for existing apps, but it is no longer the only path.
That is a big deal.
Collection2 is one of those packages that sits very close to the heart of classic Meteor app development. Making it less tightly coupled to one validation library opens the door to a more modern and more flexible ecosystem without abandoning the apps that got us here.
Looking back, this month was not about one huge headline feature. It was about removing blockers.
A temporary WeKan patch got pushed upstream. meteor-user-status and meteor-timesync got proper Meteor 3 releases. Meteor 3.5 moved forward through real-world WeKan testing. An old logger PR came back from the dead. SimpleSchema finally got its async-friendly release. Collection2 started opening itself up beyond SimpleSchema.
This is the kind of work that makes an ecosystem feel alive.
Not just new features. Not just rewrites. But maintenance, releases, compatibility, testing, and people showing up to finish what was left half-done.
One PR at a time, the Meteor 3 ecosystem keeps getting sturdier.