#14267 — Improve v3 migration guide with real-world migration insights — The final brick in the wall, where I took all of the learnings I had accumulated over my many Meteor migrations, especially the latest WeKan migration, and centralized them in one place. I even got Nacho’s stamp of approval, which makes me a tiny bit happier.

#14321 — Replace node-2fa with OTPAuth in accounts-2fa — Another mini PR that I’m proud of. While delving deeper into Meteor accounts, I noticed the usage of an old and unmaintained library, so I decided to replace it with a modern alternative. This is where LLM power shines the most. A contribution like this might have taken me a day or two, but thanks to LLMs, it was done in 10–20 minutes, most of which went into actually planning out the change, picking the alternative library, and deciding on the migration strategy, where I, of course, emphasized the importance of backward compatibility. A case in point for proper usage of LLM-powered development.

#14069 — Asyncify client-side calls — One of the biggest PRs that I’ve been waiting for and actively trying to push finally made it into 3.5. This is another step toward a truly async-compliant and ES6-friendly framework.

#14070 — Add loginWithTokenAsync, loginWithPasswordAsync — The third Meteor accounts contribution that helps us move the needle and make the DX of working with Meteor accounts in an async environment a true joy!

That was it for core. Now onto the Meteor Community Packages.

meteor-mocha #188 — Deps: meteor 3.4 — Jan updated the dev dependencies, bumped Meteor to 3.4, moved CI to Node 22 and Meteor 3.4, and updated the test drivers. Testing packages are never the flashiest part of the ecosystem, but if they lag behind, everyone else feels it.

meteor-timesync #60 — Meteor 3 compatibility release — This one has been around for quite a while, but it got another push. The PR targets Meteor 3 compatibility, and 1.0.0-beta.2 was published thanks to BastienRodz’s contribution. The Cordova/Capacitor path got special attention, with tests ensuring mobile clients force DDP transport while regular browser clients still use HTTP.

Lastly, general community packages:

quave:synced-cron #21 — Preserve synced-cron userId in nested method calls — This came out of a subtle context problem. Cron jobs were executed directly through entry.job(...), so nested server-side Meteor.callAsync calls didn’t have a current DDP method invocation. The result: this.userId inside the nested method became null.

The PR preserves the cron job userId across nested server-side method calls and adds a regression test to make sure the context doesn’t get lost again.

quave:slingshot #22 — Replace deprecated Buffer constructors in meteor-slingshot — Very small, very clean. Replaced deprecated Buffer() / new Buffer() usages with Buffer.from() and bumped quave:slingshot to 2.0.4.

This is the type of change that won’t make anyone clap, but it removes warning noise and keeps packages healthier on newer Node versions.

redis-oplog #424 — Meteor 3.4 compatibility — Still open, but I pushed follow-ups here too. The main work rewrites ObserveMultiplex.js to match Meteor 3.4’s callback semantics, updates observeChanges to the newer signature, and uses collection.direct to avoid collection hooks re-triggering on already-processed selectors.

I also added a regression test for direct collection refetch, fixed optimistic update ordering so it no longer flickers, replaced the old Redis GitHub Action with a native Redis service, and added Meteor 3.4 to the CI matrix. Locally, tests pass on 3.1.2, 3.2, and 3.4. Hopefully this gets reviewed soon because redis-oplog remains important for serious Meteor apps.

Monti APM agent #149 — Skip pubsub error tracking for deactivated subscriptions — A tiny PR against the fiberless branch. The fix avoids tracking pubsub errors when the session or subscription has already been deactivated. In practical terms, don’t try to report useful subscription error metadata after the subscription is already gone. Sometimes the best fix is just refusing to pretend dead state is alive.

There was also a small Android side quest.

capacitor-meteor-webapp #1 — Use AGP 9 compatible default ProGuard file and capacitor-community/keep-awake #87 — fix: AGP 9.0 no longer supports proguard-android.txt — Both PRs switch Android library config to getDefaultProguardFile("proguard-android-optimize.txt").

Android Gradle Plugin 9 rejects proguard-android.txt because it bundles -dontoptimize, which can make project configuration fail before you even get to the build. I hit this while testing downstream mobile work, fixed it in keep-awake, and opened the same fix for capacitor-meteor-webapp.

Again, not Meteor core directly, but this is the kind of ecosystem papercut that matters if we want Meteor apps to keep working well on mobile.

I noticed that I had already been implementing most of the points mentioned in one way or another, but the article elegantly highlighted them in a way that made me want to pinpoint how I’ve been executing on them.

Hopefully, this can serve as an example for future developers looking to improve their position among their peers.

1.1 A Dedicated Website

It’s quite ironic when I see people tout themselves as web developers yet have no dedicated online presence!

I’m not talking about X, LinkedIn, or even GitHub, but an actual dedicated space that you fully own and no one can take away from you. This also has the added benefit of letting you use your secondary social media presence to funnel an audience into your website, instead of other websites using you, or whatever you write, for their own benefit.

Now you can write whatever you wish on your website and merely use other platforms for wider exposure.

Getting started is trivial. You can use GitHub Pages, grab any Jekyll theme, and use it. You can even purchase the domain at a later step!

1.2 A Hire Me Page

The requirements are pretty straightforward:

The important basics of such a page:

• It should be short and concise; this is a decent business proposal, not a novella.
• A way to contact you, i.e. your e-mail address.
• Describe what you can do. In my case, it was programming in Go.
• Provide proof that you’re good at it. In my case, I linked to my past writing about Go, my open source Go libraries, and a Go contract I successfully completed.
• Social proof, such as a list of well-known companies I worked at.
• My time zone, because it’s important in remote work.
• A photo for that human connection.

Here’s mine for reference.

2. Publish Technical Articles

Now that you’re landed gentry, your next step is to start cultivating that land website.

Start by publishing tutorials and technical articles. People often have a hard time figuring this part out, but it’s incredibly trivial.

Here are multiple ways I use to find ideas for what to post:

• What would your former self have wanted to know but didn’t? What would you explain if you could travel back in time?

Picking and choosing the right path and the right web courses to follow was a tiring process for me, so I put together what I’d mark as an ideal path for others to tread on:

JS Roadmap

• What is a piece of information you recently stumbled upon and found interesting?

While poking around Meteor internals, I came across a few interesting pieces of information about how Meteor publications work, so I put it in writing in case someone else finds it useful:

Meteor’s Hidden Auto Publications: The Free Data You Never Asked For

• Is there something that has been on your mind and you want to get out? Get it out in writing.

The relationship between open source and how others perceive the developers maintaining it. Should they be grateful? Should they not be? I was so frustrated with this that I put it into writing:

Open Source, Gratefulness and Self-interest

2.1 Turn Experience Into Lead-Generating Artifacts

AKA the “describe” method: just describe what you did recently in layman’s terms. Nothing fancy!

This shows up in two main ways for me:

Dev Diary

By far, this is the best and easiest way to do it, especially if you’re an active OSS developer like me.

I basically take all of my monthly contributions and put them into article form to share with the community at the end of each month. I literally describe what I did, no more, no less, and it has been amazing for getting me more exposure and letting others know about the work that always often goes unnoticed each month.

Here’s the latest dev diary:

Dev Diary #27 - Async Accounts, OTPAuth, Migration Docs, and Ecosystem Maintenance

Migration Stories

Another one I tend to enjoy the most is taking a very lengthy and huge Meteor migration and distilling that knowledge into articles describing what I did, the problems I went through, and how I overcame them.

I did WeKan recently, and also Medbeauty.

3. Specialize

It’s a bit of common knowledge these days that, when promoting yourself as a developer, you shouldn’t tie yourself to a single technology because it might make you look like an “if-else developer.”

But I’m here to offer an alternative path.

There’s a lot to be gained from specializing and promoting yourself as an expert in one specific thing.

Imagine someone looking for a Meteor developer. Yes, Meteor developers know Node.js and MongoDB, and you can promote yourself as such, but how likely are they to pick a generalist Node.js developer over someone who clearly labels himself as a Meteor developer?

That generalist might be a very capable Meteor developer, but if he doesn’t label himself as such, he might not even be considered.

I’m not against the generalist path per se, and I believe there are multiple ways to skin the cat. What I’m highlighting here is that it’s okay to promote yourself as a specialist in a certain topic, and sometimes in that topic only.

4. Enjoy the Fruits of Your Labour / Promote Your Stuff

Did you try out Firely yet?

It’s my awesome personal finance app. I bet you didn’t know about it, but now you do.

Thanks to the previous steps I took to build a dedicated online presence, I can now promote my stuff in a way that feels earned rather than random.

And that’s exactly the point.

The first order of business was continuing the package removal spree that started last month. Meteor 2 apps tend to accumulate Atmosphere packages the way old houses accumulate junk drawers – you don’t notice how many there are until you try to move.

1. #6173 — Fix FilesCollection findOneAsync errors for Avatars and Attachments — Quick fix to kick things off. ostrio:files’s FilesCollection provides findOne(), not findOneAsync(), so we were calling a function that didn’t exist. Switched to the sync method and moved on.
2. #6174 — Replace konecty:mongo-counter with inline implementation — Removed the package and replaced it with a minimal incrementCounter function using raw MongoDB findOneAndUpdate. Also added an async version for Meteor 3.0 compatibility.
3. #6175 — Replace templates:tabs with inline Blaze implementation — Swapped the templates:tabs Atmosphere package for a lightweight inline basicTabs/tabContent Blaze template pair. Zero changes to consumer templates – drop-in replacement.
4. #6178 — Remove peerlibrary:blaze-components — This was a big one. Removed the unmaintained peerlibrary:blaze-components and all six of its peer dependencies. Migrated every component from BlazeComponent.extendComponent() to native Meteor Template.onCreated/helpers/events patterns. Replaced the Mixins global with standalone utility modules.
5. #6188 — Fix list add-card actions and sort persistence — The blaze-components migration (#6178) broke list header and popup add-card actions. This PR restored them, fixed the inlined add-card form reopening, and removed duplicate list sortable initialization so list moves persist correctly.
6. #6190 — Replace underscore with native JavaScript utilities — Replaced ~250 underscore.js calls across ~45 files with native JS equivalents. Added a small shared helper module for patterns that don’t have a clean native one-liner. Removed underscore from local packages and .meteor/packages.
7. #6191 — Remove raix:handlebar-helpers — Removed the package and re-implemented the operator helpers ($eq, $neq, $gt, $lt, etc.) as native Blaze helper registrations in a new blazeHelpers.js file.
8. #6195 — Replace useraccounts packages with communitypackages alternatives — A big step for both WeKan and the community. Migrated from the unmaintained useraccounts:* packages to community-maintained communitypackages:* drop-in replacements. I migrated all three packages and chose Meteor Community Packages as their new home so the community can benefit and carry the torch. Also took the opportunity to remove dead packages like coffeescript which was no longer needed after the blaze-components removal.
9. #6196 — Remove unused meteorhacks:aggregate — The only aggregation call was already using rawCollection().aggregate() directly, so the package was dead weight. Also converted getBoardTitleWithMostActivities from Promise.await to async/await.
10. #6197 — Replace Email.send with Email.sendAsync — Replaced all Email.send() calls with await Email.sendAsync(). This also fixed a bug where email sending errors were silently swallowed as unhandled promise rejections instead of being caught by surrounding try/catch blocks.

And then came the big one.

#6205 — Incoming Impact — This is the PR that bumps WeKan to Meteor 3.4. I had a few days left before my Claude and Codex subscriptions ran out, so I decided to put what remained of them to good use. We could’ve attempted a gradual bump, but that would’ve only lengthened the pain – death by a thousand paper cuts. The application restructuring was by far the lengthiest part of this whole migration journey, mostly because of the overuse of globals and the lack of separation between server and client responsibilities (the classic isomorphism trap).

I don’t want to restate what is already in the PR description — I highly recommend reading it, it’s almost another dev diary of its own! What I’d like to highlight though is I did actually migrate the simple REST packages over at Meteor Community Packages, but ultimately decided it was better for WeKan to drop them entirely. This change specifically is partially why I was itching to bump to 3.4 directly – some changes can only be done when you’ve already upgraded and cannot be done on 2.0. Maybe the core team ought to move the Express change to 2.0 to ease this burden a bit.

On the Meteor core side, this was a busy month too:

#14222 — Fix puppeteer test runner console output — When puppeteer was bumped from 20.4.0 to 23.6.0, msg._text (underscore-prefixed property) became a private ES2022 #text field. This meant test names and pass/fail results were never printed in CI logs – you’d just see “Test number: N” with no useful information. Tracked it down and fixed the property access.

#14223 — Docs: guide LLMs to use test-in-console for package tests — Added documentation directing LLM agents to use ./packages/test-in-console/run.sh instead of ./meteor test-packages, which hangs waiting for a browser connection and produces no terminal output.

#14224 — Add test-headless driver for headless package testing — Born out of the frustration with test-in-console. This is a new test driver package that doesn’t rely on console scraping – results flow via DDP methods instead. Server calls Tinytest._runTests() directly, and if no browser connects within 10 seconds it gracefully prints server-only results. Supports TINYTEST_FILTER for regex filtering. Still open.

#14221 — Remove unused ejson dependency from packages — Removes direct ejson dependency from accounts-password, accounts-passwordless, and session since they get it transitively. Still open.

#14234 — Integrate collection hooks into core — This one’s been brewing in my mind for a while. Over the course of 3.0 migrations, I kept running into collection-hooks everywhere – it even turned up inside redis-oplog. The depth of its penetration into third-party packages made it clear this belongs in core. Bringing it in means it won’t get left behind in future migration cycles (as happened with the fibers/async transition), and we get to shed the monkey-patching workarounds the community package relied on. Still open.

#14262 — Backport express for 2.17 — This one came directly out of the WeKan migration pain. Every time I do a 3.0 migration, the same problem stares me in the face: communitypackages:picker and WebApp need Express, but you can’t use Express until you’re on 3.0. This PR ports the Express change back to 2.x (targeting a possible 2.17 release) so apps can adopt the new WebApp API before making the full 3.0 jump. Still open.

And finally, some community package work:

meteor-partitioner #38 — Meteor 3.0 migration — Work in progress on migrating the meteor-partitioner package to Meteor 3.0. This is the package that enables multi-tenant data partitioning in Meteor apps.

meteor-streamer #44 — Upgrade to Meteor 3.0 — A substantial migration of RocketChat’s meteor-streamer package. Converted permissions, methods, and emit to async/await, replaced findOne with findOneAsync, restructured the repo with a separate test app, wrote 87 new tinytest tests, added ESLint config, and removed the arunoda:streams dependency. This one lives in my fork for now while the PR is reviewed.

Looking back at this month, the numbers tell the story: eleven WeKan PRs, five Meteor core PRs (two merged, three open), and two community package migrations. LLMs have been a huge factor in this. I don’t want to use the term “AI” as there’s no inherent intelligence, just cool mathematical tricks that have been there for a long time, only enabled by the massive leap in data and processing power. Yet it’s an incredible tool in our arsenal as developers. We like to think of ourselves as great engineers — which we are in a sense — but our work also contains lots of grunt work like copying files, moving directories, validating words. Stuff that’s not only better suited for a computer but that also frees us to think more about the critical stuff. So don’t get trapped in the doom and gloom as I was, pondering my future as a software developer in the new era, but be optimistic. Think about all the new doors that’ve been opened instead of the closed windows!

I went through them one by one:

1. #6111 — Migrate wekan-oidc to async API for Meteor 3.0 — Fairly straightforward. Replaced the deprecated HTTP package with fetch and asyncified the server-side calls. Nothing too wild.
2. #6112 — Migrate wekan-accounts-sandstorm to async API for Meteor 3.0 — Similar treatment here. Added missing await statements and converted HTTP to fetch. Sandstorm is a niche platform but WeKan still supports it, so it had to be done.
3. #6114 — Migrate wekan-accounts-cas to async API for Meteor 3.0 — This one was more involved. Had to rip out the Npm.require('fibers') call entirely, switch the login handler to async/await with findOneAsync, and wrap the WebApp handler with Meteor.bindEnvironment. Also replaced underscore with native JS while I was at it. Bumped it to 0.2.0.
4. #6115 — Migrate wekan-ldap to async API for Meteor 3.0 — The biggest of the auth package migrations. Replaced Meteor.wrapAsync with native Promises, swapped ldapjs for ldapts (v4.2.6 to stay compatible with WeKan’s current Node version), and replaced the slugify dependency with limax. Bumped to 0.1.0.

With the auth packages out of the way, I moved onto other migration work:

1. #6139 — Migrate @wekanteam/meteor-reactive-cache — This was a meaty one. The reactive cache is WeKan’s caching layer that prevents repetitive database calls. I moved the package into the WeKan codebase itself via filesystem path rather than keeping it as an external npm dependency. This lets us iterate faster during the migration without needing separate package releases. Converted all the server-side ReactiveCache methods to async and updated every call site. One snag: allow/deny calls had to stop using reactive cache since those remain synchronous in Meteor 2.x. I also added a METEOR3_MIGRATION.md file at the repo root to track our overall progress.
2. #6153 — Fix unhandled Promise rejection in cron migration job callback — A fun one to debug. The createCronJob callback wasn’t async and wasn’t awaiting this.runMigrationStep(step). This created a floating Promise that, when rejected, triggered the global error handler in quave:synced-cron, which helpfully calls process.exit(0) and crashes the whole app on startup. The fix was just making the callback async and awaiting the promise. Classic async migration gotcha.
3. #6162 — FullCalendar NPM + Moment migration — Discovered that moment.js was being pulled in through the fullcalendar package, so I consolidated the FullCalendar migration and moment removal into one PR. Migrated to FullCalendar v5.11.5 (v6 has ESM/Node constraints that don’t play nice with our current setup, something to revisit post-3.0). Added a template-bound autorun to prevent Blaze errors, cleaned up the calendar UI labels and modal styling, and added missing translation keys.

On the Meteor side, I had a couple of PRs and a nice milestone to share.

#14168 — Add NPM security audit — I introduced automated npm security vulnerability scanning into Meteor’s CI/CD pipeline. Rather than waiting for community reports about security issues, this proactively scans packages like meteor-node-stubs, meteor-babel, meteor-installer, and others. Using a phased enforcement approach where only meteor-node-stubs is currently enforced, with plans to progressively expand as existing vulnerability debt gets resolved.

#14167 — fix(meteor-node-stubs): patch bn.js bundled transitive versions — This one got closed because Italo beat me to it with #14173. Fair enough!

#14153 — Improve LLM access to documentation — Added absolute URLs, enriched metadata, and generated an API reference JSON to make Meteor’s v3 docs more accessible to LLMs. Grubba liked the codegen approach, and Italo requested we dynamically generate version info rather than hardcoding it. Still open, will address the feedback.

And finally, a milestone I’m quite proud of: the Meteor Guide migration is essentially complete. This issue was opened back in July 2025 asking whether the guide was up to date, and the answer was a resounding “no”. Since then, the community has been cherry-picking content from the old guide and migrating it to the new VitePress docs. Collections, publications, methods, accounts, testing, routing, Angular, Tailwind, React Native, hot code push, build system, deployment, and performance – all checked off. I’d say we’ve accomplished this with flying colors.

Over my time in the OSS sphere and lately with the 3.0 migration shenanigans, I’ve found myself becoming increasingly aligned with Joel Spolsky’s stance on rewrites – don’t do it!

I decided to take the plunge and dedicate my OSS efforts for the foreseeable future to migrate WeKan. It’d be immensely beneficial for WeKan itself and for the Meteor community as a whole to witness a 3.0 migration out in the wild and how the sauce is made.

Ideally when starting out with 3.0 migrations, you should aim to first:

1. Get your app to the latest 2.x version, currently 2.16
2. Prune your Meteor packages. Generally speaking, the fewer Meteor packages you have, the better. This includes:
   1. Replacing Meteor packages with NPM alternatives or outright removing them.
   2. Replacing any Meteor packages with either 3.0-friendly alternatives that are better maintained (e.g., kadira:flow-router to ostrio:flow-router-extra)
3. Enable WARN_WHEN_USING_OLD_API, introduced in 2.12, and start migrating your server-side app code to async.
4. Decouple your front end and back end code, and restructure it to allow for separate entry points for client and server. This is a necessity for 3.4 migration.
5. Flip the switch and migrate to 3.0 and do the necessary grunt work. Certain APIs have been outright removed and you can’t do anything about them in 2.16, so you gotta update to 3.0 and flip the switch!

Steps 2 & 3 don’t necessarily need to be done synchronously. You can do them interchangeably. Migrate a package here and some application code there. So adjust accordingly.

I started my work with the lowest hanging fruit to test the waters, then as I gained confidence I moved onto bigger stuff:

1. #6067 — Migrate kadira:flow-router to ostrio:flow-router-extra — Replaced the abandoned kadira:flow-router client-side routing package with ostrio:flow-router-extra, its actively maintained successor that supports Meteor 3.0. A very simple change yet a foundational migration step since the router touches nearly every route in the app.
2. #6072 — Update 2.16 — A broader update PR, likely bumping WeKan’s Meteor version or dependencies to 2.16 as part of the incremental upgrade path toward Meteor 3.0. Thankfully going from 2.x to another 2.x isn’t a challenge since there are no breaking changes.
3. #6080 — Migrate from percolate:synced-cron to quave:synced-cron — Swapped the unmaintained percolate:synced-cron scheduled job runner for quave:synced-cron, its Meteor 3-compatible fork maintained by the Quave team.
4. #6082 — Replace mousetrap — Replaced the Mousetrap keyboard shortcut library with a modern NPM alternative. This is a case in point of how you can decrease your Meteor packages while improving the overall health of your app.
5. #6083 — Remove kadira:dochead — Removed the kadira:dochead package (used for dynamically setting <head> tags like title and meta) and replaced it with a simple document.title.
6. #6084 — Replace cottz:publish-relations with reywood:publish-composite — Replaced the cottz:publish-relations reactive join publication package with reywood:publish-composite, a more widely used and Meteor 3-compatible package for publishing related/nested documents from multiple collections.
7. #6086 — Replace mquandalle:collection-mutations with collection helpers — Swapped mquandalle:collection-mutations (which added mutation methods directly to collections) with a collection helpers approach, removing dependency on an unmaintained package. Hopefully with 3.4 to use the native way. ;)
8. #6087 — Replace ongoworks:speakingurl with limax — Replaced the Meteor-wrapped ongoworks:speakingurl slug generation package with limax.
9. #6088 — Remove mquandalle:autofocus — Removed the mquandalle:autofocus package, which provided auto-focus behavior for form inputs in Blaze templates, replacing it with native HTML autofocus attribute or a simple manual implementation.
10. #6093 — Migrate createIndex to createIndexAsync — Converted synchronous createIndex calls on MongoDB collections to their async counterparts (createIndexAsync), which is required by Meteor 3.0’s move to an async-first MongoDB driver. This is what I mean by doing steps 2 and 3 interchangeably. During the package work I shifted focus to do a little app code change then reverted back to packages without interruption whatsoever.
11. #6095 — Remove idmontie:migrations — Removed the idmontie:migrations package (used for running database schema migrations) and either replaced it with a Meteor 3-compatible alternative or handled migrations differently.
12. #6096 — List on body for global onRendered — Fixed a Blaze template lifecycle issue, likely moving a global onRendered callback to properly attach to the body/list template level, ensuring correct initialization behavior after Meteor 3 rendering changes.
13. #6113 — Migrate wekan-accounts-lockout to async API for Meteor 3.0 — Converted WeKan’s account lockout package (which locks accounts after failed login attempts) from synchronous to asynchronous APIs, required by Meteor 3.0’s async-first architecture.
14. #6120 — Fix async/await in copy/move card operations — Fixed async/await issues in the card copy and move operations, where the migration to Meteor 3’s async MongoDB calls caused unhandled promises.
15. #6126 — Await async setDone before closing popup in copy/move dialogs — A follow-up fix to #6120, ensuring the setDone callback is properly awaited before the popup dialog closes during card copy/move operations, preventing the UI from closing prematurely before the database operation completes.

The work is still far from over, so keep an eye on the WeKan repo for future PRs ;)

With WeKan out of the way, I also had the privilege to do some work on Meteor itself.

I revived the async hooks PR. It was mostly done but the tests were failing. Hopefully it gets merged in the upcoming 3.4.1, which I anticipate is going to be an amazing release. I’d also like to highlight Italo’s work in spreading the word about Meteor. The amount of PRs rolling in has been increasing, which is something that Meteor direly needs.

Also, the Meteor docs got some love. Ever since the core team decided to move to VitePress and the 2/3 split, things haven’t been super good for the docs, so hopefully that PR gives the little push needed to close out this chapter. Although I theorize that the docs work will never be over because Meteor is always evolving and the changes to track are a moving target. I hope the new LLM core changes can help us in that regard.

Lastly, Redis-oplog got some 3.4 compatibility fixes. I hope Jan can have a look pretty soon.

Starting off with the meatiest of all is the new release of Packosphere. I was motivated to start this PR since whenever I’m using Claude Code or any other LLM, it fails to notice the latest Meteor package releases as it attempts to do so by a usual search lookup which might not detect the beta releases, which are nothing but PRs on the GitHub repos. So I thought it’d be a good time to do a facelift on the Packosphere repository. It’s now updated to the latest RC 3.4-rc.2. Also, a couple of sub-packages were updated too:

• socialize:base-model
• copleykj:grapher-link-executor
• peerlibrary:meteor-packages

Collection Hooks is nearing another release which attempts to improve its underlying structure to make future improvements much easier. It’s also worth noting that a bug with Accounts.onLogin is now fixed.

Partitioner package also received another mini-update which is aimed at fixing a bug with projection field.

As for Meteor itself, a few PRs were made to help improve the async experience when working with accounts packages:

• Add loginWithTokenAsync, loginWithPasswordAsync
• Asyncify client side calls

Lastly, there’s a very important thing which the community hasn’t been made aware of, which is that Monti APM docs is now open source. These docs represent a treasure trove of Meteor-specific knowledge on how to deal with performance, scaling, and more. It used to be part of the official Meteor docs but wasn’t updated, and now since Meteor gave up its own APM in favor of Monti becoming the de facto APM for the entire Meteor community.

I’m quite grateful for this month’s work as it helped push the narrative of many Meteor packages out there, and I was quite delighted to help out with Packosphere. Be sure to support Kelly so that he may continue his awesome work.

This entry is much smaller in terms of contributions as I’ve been struggling with balancing work commitments.

Add NonEmptyString to check package finally landed. This PR was started on Oct 30, 2023. That’s more than 2 years in the making for a very simple feature. If OSS has taught me any lesson, it’d be patience and perseverance. You can make all the right steps and still your contribution won’t land, as maintainers might have other commitments. So you just have to continue pushing for it, and if the case is in your favor, you might be rewarded someday and get it merged!

I also made two quick contributions in succession:

Document how to work with hash URLs. It was an interesting job finding out how Meteor goes about generating reset URLs. Turns out preceding URLs with hashes forces the browser to handle such calls on the client side instead of server side to avoid sensitive tokens being shown in server logs.

Warn if Accounts.emailTemplates.from isn’t set. This resulted from a real-life problem where email sending was failing, and no matter where we looked, we couldn’t pinpoint the problem until a developer suggested adding Accounts.emailTemplates.from as Meteor defaults to Accounts Example <no-reply@example.com>. While digging, I also came across a change that was undone recently. Hopefully we can get to the bottom of it soon.

It’s a personal SaaS I’ve built to better track my spending. If you’ve followed my writing, you’ll know I’m big on personal finance - I even wrote an article on lending money.

How I discovered FIRE

My journey into financial independence started after being laid off from a job. It got me thinking: would I be working my entire life? Is there an end to this? To live with dignity, do I have to trade my time infinitely, even into old age?

I started looking up resources on managing money better and stumbled upon “Your Money or Your Life”. The book delivers on its title - your relationship with money and how you deal with it can either supercharge or drain your life.

Reading it was a life-defining moment. It reframed everything by equating your hourly rate with how many hours you’re trading for certain items. Does your phone feel worth it when it cost you an entire week of work? Are you happy giving a “friend” a gift worth 10 hours of your life when he wouldn’t give you 10 minutes of his time? Does spending an hour’s worth of money on a personal hobby feel satisfying?

Building a foundation

My journey then led me to Quit Like a Millionaire and JL Collins’ The Simple Path to Wealth. Both books formed a great foundation and an all-encompassing philosophy without requiring me to grok thousands of pages of literature.

They did arrive at a key point: the need to invest in stocks and bonds. I thought, well, I need to dive even deeper - so I read ETFs for the Long Run and Abner’s The ETF Handbook.

Finding an investment platform was a big hurdle since I’m Egyptian and live in Egypt. Most trading platforms outright ban or don’t allow Egyptians. I’d love to share that experience, but perhaps in another post. With much luck, I eventually found GoTrade and more recently Nsave.

Beyond finances: a life philosophy

Another instrumental book was Early Retirement Extreme, which I consider more of a life philosophy than a finance book. To give you an idea, it lists Miyamoto Musashi’s Book of Five Rings as an inspiration.

I was particularly struck by the concept of being a renaissance man - excelling in multiple areas of life instead of being a one-dimensional cog in our capitalistic society, easily replaced. There’s so much you can discern about someone’s view of life, work, and everything else by how they view money’s role. This is something I’d like to expand on in future posts.

Why I built Firely

Now, back to Firely - sorry, I couldn’t help sharing what led me here!

I’d been tracking my finances for a couple of years in a simple ODS spreadsheet. I like keeping things simple, but this method had a few flaws:

• Memory burden: If I was out, I had to memorize or write things down. I believe cognition is like RAM - it’s not made to hold information, but to quickly process it.
• Complex calculations: Any fancy analysis required equations and formulas - another skill and time investment I wasn’t ready to make.
• Accessibility: I could only access it from my computer.
• No automatic backup: Everything had to be done manually.

Enter LLMs

Thankfully, with the rise of LLMs (thank you, dear Claude), I was able to spin up a prototype during a weekend and host it on Vercel. I believe this is one of the real benefits of LLMs: personal micro-SaaS is the next big thing. Now anybody, developer or not, can spin up an app that solves their niche need.

The very first commit was on January 1, 2025, but I’ve been slowly iterating to reach a stable version. The app may still contain bugs, which I’d gladly like to learn about. You can report any issues via X or email me at harryadelb@gmail.com.

Looking forward to hearing what you think!

This marks the death of a second collections-related package; the first was mongo-collection-instances. This was touched upon in a previous community post where I discussed whether Astronomy should be merged into collection2 or not. But now two of the big collection utilities are offered directly by the core.

wildhart:jobs has been made 3.x friendly. Hopefully the original author has some time to look into it and approve it!

Meteor Grapher is pending quality of life changes.

Orderlion’s ddp-apollo, which is a fork of swydo:ddp-apollo, also got a nice set of updates that should make it more efficient and independent. Their fork had an underlying package that wasn’t published, so I published it under meteor-apollo-link-ddp.

Now onto the changes:

Probably the biggest highlight of this month is the release of Veliovgroup’s Meteor-Files v3.0.1. While my PR didn’t get merged, I’m glad it inspired Dmitriy. Huge shoutout to Dmitriy for his consistent work. You might want to check out his service Ostr.io.

My efforts to migrate Caught to 3.0 are still underway, and thanks to their patronage, I’ve been religiously migrating the Meteor-partitioner package. The latest beta currently out is 0.7.0-beta-12. I’ve noticed that bumping the minor version is suboptimal, so I’ll probably do a major bump once I’m done.

apollo-live-client is now async compliant and ready for Meteor 3.0.

I also decided to do a little side quest and feature Meteor on the parcel-bundler repo: https://github.com/parcel-bundler/watcher/pull/214

A new beta version of collection2 that supports Zod v4 is out: https://github.com/Meteor-Community-Packages/meteor-collection2/pull/447#issuecomment-3250047107 I’m awaiting your feedback so I know what the next steps are.

Lastly, I did fiddle a bit with Meteor packaging system and came up with a PR. It’s still in the works, and zodern’s comment made me doubt it a bit, but hey, it was fun looking into Meteor’s internals.