meteorjs oss wekan migration

Dev Diary #25 - WeKan Auth Package Blitz, FullCalendar Migration, and Meteor Security Audits

The WeKan migration train keeps chugging along. This month I tackled the authentication packages, which are the gnarliest part of any Meteor app because they tend to rely on Fibers, Meteor.wrapAsync, and synchronous HTTP calls – all things that Meteor 3.0 wants nothing to do with.

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.

try my software

Firely - a personal Saas application to track your spending