Wekan 3.0 Migration

harry97 · March 1, 2026, 9:01pm

Hello guys,

I just wanted to showcase the progress we’ve made progress on Wekan migration to 3.0. Instead of the usual linkedin post I thought to post here on the forums

harry97 · March 24, 2026, 8:04pm

github.com/wekan/wekan

Incoming Impact ☄️☄️☄️☄️

wekan:main ← harryadel:meteor-3-migration

opened 11:55PM - 23 Mar 26 UTC

harryadel

+65927 -14525

I had a few days left before my Claude and Codex subscriptions ran out, so I dec…ided to put what remained of them to good use. 😄 We could've attempted jumping straight to 3.0 and then to 3.4, but that would've only lengthened the pain — death by a thousand paper cuts. The application restructuring was by far the lengthiest and most annoying 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). These steps could've technically been split into separate PRs, but here we are. --- ### Client Boot and Entry Points We replaced the old eager client import graph with explicit feature entry points under `client/features`. Each feature now owns its template, logic, and style loading order instead of relying on Meteor 2's permissive global/eager behavior. - `client/imports.js` now imports feature entry modules instead of a flat list of component files - `client/styles.js` centralizes stylesheet loading - `client/main.js` boots styles and client features in a controlled order - Shared sidebar access moved behind `client/features/sidebar/service.js` to break circular imports --- ### Shared Model and Server Boundary Split We split the old hybrid `models/*.js` design into a cleaner shared/server architecture. The pattern introduced: - Shared collection definitions remain in `models` - Server-only methods, hooks, startup, indexes, routes, and side effects moved into `server/models` - Permissions moved into `server/permissions` - Server boot wiring consolidated in `server/imports.js` --- ### Removal of Implicit Globals A major migration theme was eliminating Meteor's ambient-global assumptions. What we cleaned up: - Explicit imports for `Template`, `Meteor`, `ReactiveVar`, `Session`, `ReactiveCache`, `EscapeActions`, `Utils`, `Swimlanes`, and `TAPi18n` - Client route and popup code no longer assumes Blaze globals or that a current view context will always exist - Model/schema code no longer treats `SimpleSchema` as an ambient global owned by `imports/collectionHelpers.js` --- ### Asyncification for Meteor 3 A large portion of the work involved converting server code away from Meteor 2's synchronous Mongo APIs: - `findOne` → `findOneAsync` - `count` → `countAsync` - `fetch` → `fetchAsync` - `insert` / `update` / `remove` → async variants where needed on the server - Direct collection operations and hook bodies updated to properly `await` async writes - Synchronous callback patterns like `forEach(async ...)` rewritten to `for...of` where required --- ### SimpleSchema & Collection2 Compatibility - **SimpleSchema v2 migration** — switched from a named export to the default import, registered custom schema extensions (`denyUpdate`, `denyInsert`), and added missing parent object declarations in schemas. - **Centralized `collection2`/`SimpleSchema` setup** — `imports/collectionHelpers.js` shim ensures Collection2 and SimpleSchema are loaded exactly once before any model file calls `.attachSchema()`. --- ### Synced Cron Dormant Bug There was a dormant bug that manifested as a server crash with no clear error output — it looked like Mongo, SockJS, or DDP instability. The actual root cause was buried: - `quave:synced-cron` was still in the boot path - Unhandled rejections in cron-related code caused the package to exit the process - The browser only showed the downstream effects: WebSocket closed, SockJS JSONP failed, and HTML error pages appeared where JS/JSON was expected What we changed: - Centralized cron access in `server/cron/syncedCron.js` - Removed scattered startup ownership of cron behavior - Changed the wrapper to lazy-load `quave:synced-cron` instead of importing it eagerly at normal app boot - Replaced some automatic housekeeping behavior with simpler non-cron paths - Fixed the real fatal unhandled rejection in `server/notifications/outgoing.js` that cron was surfacing --- ### The Markdown Package Problem The app depends on `wekan-markdown`, which: - Exports a global `Markdown` - Wires client behavior through `api.addFiles('src/template-integration.js', 'client')` - Relies on legacy package-loading semantics rather than explicit ES module imports Under Meteor 2, this mostly worked because package/global loading was eager and forgiving. The tricky part was that this package sat in an awkward middle ground: not a normal app module, not a fully modernized Meteor package, and still relying on client integration happening as a side effect. So when the client boot graph was being cleaned up, markdown appeared broken even though the package still existed and its name in `.meteor/packages` was still correct. The real problem was that package side effects could no longer be casually assumed to happen at the right time. This was a huge learning moment. I had assumed that migrating a Meteor package was all about `versionsFrom` and converting synchronous code — but it's also about structure and the implicit guarantees Meteor 2 provided that simply no longer exist in the Meteor 3 world. --- ### Meteor Packages - `packages/meteor-autosize/` — replaced with the npm `autosize` package - `mquandalle:jade` — replaced with `meteor-jade-loader`, a custom rspack Jade loader - `meteorhacks:subs-manager` — replaced with `jam:offline`, `jam:method`, and `jam:pub-sub` - `simple:json-routes`, `simple:rest-accounts-password`, and `communitypackages:picker` — replaced with a custom implementation using the native WebHandler approach. I did actually migrate the `simple` packages [here](https://github.com/Meteor-Community-Packages/meteor-rest), 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.0 directly instead of doing mini-PRs as some changes can only be done when you've already upgraded to 3.0 and cannot be done on 2.0. Maybe the core team is ought to move the express change to 2.0 to ease this burden a bit. --- ### Removed NPM Packages | Package | Notes | |---|---| | `flatted` | devDep | | `@mapbox/node-pre-gyp` | | | `ajv` | | | `bcryptjs` | | | `chart.js` | | | `es6-promise` | | | `fibers` | Core Meteor 2 dependency, not needed in Meteor 3 | | `ldapjs` | | | `os` | | | `qs` | | | `simpl-schema` | | | `source-map-support` | | | `to-buffer` | | | `uuid` | | ### Added NPM Packages | Package | Notes | |---|---| | `@meteorjs/rspack` | devDep — new Meteor 3 bundler | | `@rsdoctor/rspack-plugin` | devDep | | `@rspack/cli` + `@rspack/core` | devDep — rspack toolchain | | `css-loader` + `style-loader` | devDep — rspack CSS pipeline | | `@swc/helpers` | Runtime helpers for the SWC transpiler | | `autosize` | Replaces the `meteor-autosize` Atmosphere package | ### Upgraded NPM Packages | Package | Old | New | |---|---|---| | `@babel/runtime` | 7.28 | 7.29 | | `bson` | 4.x | 7.x | | `dompurify` | 3.3.2 | 3.3.3 | | `filesize` | 8.x | 11.x | | `hotkeys-js` | 3.x | 4.x | | `i18next` | 21.x | 25.x | | `limax` | 4.1.0 | 4.2.3 | | `markdown-it` | 12.x | 14.x | | `markdown-it-emoji` | 2.x | 3.x | | `markdown-it-mathjax3` | 4.x | 5.x | | `pretty-ms` | 7.x | 9.x | | `sinon` | 21.0.1 | 21.0.3 |

its-done

harry97 · March 24, 2026, 8:14pm

alimgafar · June 22, 2026, 6:33pm

Well done, @harry97! I hope @xet7 agrees! Love to hear his thoughts on the migration.

xet7 · June 22, 2026, 7:27pm

@alimgafar

Originally, I was pushing Meteor as far as possible, being on newest beta versions etc. But I could not get upgrading to Meteor 3 working, so I was rewriting WeKan to various different programming languages etc. But @harry97 somehow got WeKan upgraded to Meteor 3, so it has been possible for me to continue pushing Meteor as far as possible.

Current status:

WeKan uses newest Node.js 24.x and MongoDB 7.x, or alternatively FerretDB 2/PostgreSQL.
When I make new WeKan release, I only change version number, GitHub Actions builds bundle .zip files for Linux amd64/arm64/s390x/ppc64le, Windows amd64, macOS arm64. Then Docker images are built for Linux amd64/arm64, and pushed to docker registries: GitHub, Docker Hub, Quay.io . Snap images are built for Linux amd64/arm64 and pushed to Snap Store. Both Docker and Snap use Ubuntu 26.04 base. Because Snap still has 26.04 base available only for beta and edge channels, I can’t yet update Candidate and Stable channel, unless I downgrade back to 24.04 base.
WeKan now has 800 tests, that are running at parallel groups at GitHub Actions.
It is now possible to import all boards from Trello etc at once to WeKan. There is also new features to be able to import more data, like Stickers (implemented with similar Font Awesome Icons), Background Images, etc. Also, there is now import from Jira, Kanboard, etc, more export options, export card to Excel with images, etc.
Admin Panel / Attachments now has possibility to move all attachments from MongoDB CollectionFS and Meteor-Files to Filesystem. So when my MongoDB size was 25 GB (command: show dbs), after moving 24 GB of files to filesystem, and at “Admin Panel / MongoDB GridFS Storage / Compact”, now MongoDB size is only 1 GB. This makes attachments load immediately. Previously loading attachments was slow. It is also possible to move all attachments to S3 compatible storage, Google Cloud Storage, and Azure Blob Storage. At “Admin Panel / Attachments / Default Storage” it’s possble to select where to save files by default.

6, There is now “Red Strings”, so you can draw lines between cards, and select color for each line.

Probably easiest way to know about new features, is at docs Features:

If you need all details, those are at ChangeLog:

github.com

wekan/wekan/blob/main/CHANGELOG.md

[Mac ChangeLog](https://github.com/wekan/wekan/wiki/Mac)

Newest WeKan at these platforms:

- [Upgrade WeKan](https://wekan.fi/upgrade/)
- [bundle zip at releases](https://github.com/wekan/wekan/releases), docs at https://wekan.fi/docs/
  - [Linux amd64, arm64, s390x, ppc64le](https://github.com/wekan/wekan/blob/main/docs/Platforms/FOSS/RaspberryPi/Raspberry-Pi.md)
  - [Windows amd64/arm64](https://github.com/wekan/wekan/blob/main/docs/Platforms/Propietary/Windows/Offline.md)
  - [Mac arm64](https://github.com/wekan/wekan/blob/main/docs/Platforms/Propietary/Mac.md)
- https://wekan.fi/install/
  - Snap Beta amd64/arm64
  - Docker amd64/arm64
  - Kubernetes Docker amd64/arm64
    - Bitnami MongoDB Docker images do not exist anymore. [MongoDump/MongoRestore to groundhog2k MongoDB images](https://github.com/wekan/charts/issues/45)

Versions:

- WeKan 8.75 and newer uses Meteor 3.5-rc.x, [Node.js 24.x](https://nodejs.org/dist/latest-v24.x/),
  MongoDB 7.x (or 6.x), or [FerretDB2/PostgreSQL](https://github.com/wekan/wekan/blob/main/docs/Databases/FerretDB2-PostgreSQL.md)
- WeKan 8.43 upgraded to Meteor 3.x, huge thanks to harryadel:

This file has been truncated. show original

Also, all known vulnerabilities have been fixed:

https://wekan.fi/hall-of-fame/

alimgafar · June 22, 2026, 9:32pm

So you’re satisfied with the migration? Wekan’s future is still with MeteorJS?

xet7 · June 22, 2026, 10:10pm

@alimgafar

There are not any real problems with Meteor 3. It is highly scalable, works fast, etc.

But there are other problems:

No support for SQLite yet. I need it for Sandstorm, Amiga etc.
bundle has 42k files. I need one executeable, like FreePascal:

I need support for Netsurf, Amiga IBrowse, etc all browsers. Not require cookies and js, like FreePascal version of this:

RSPack 2.0 is not yet available:

github.com/meteor/meteor

Support Rspack 2.0

meteor:devel ← meteor:rspack-2.0

opened 03:28PM - 22 Apr 26 UTC

nachocodoner

+543 -2911

Context: https://rspack.rs/blog/announcing-2-0 This PR is an attempt to verif…y and give support for Rspack 2.0.0. Anyone can upgrade their apps to 2.0.0, since we don't limit the Rspack version they can use. The work on this PR is good to ensure our E2E test coverage is not affected by any breaking changes. But it could also show the opposite: that it is necessary to tweak specific configs in the `@meteorjs/rspack` package config to address Rspack 2.0.0 breaking changes and to make it compatible by default in any Meteor app. This is the most likely case because this is a major update, and while anybody could try to adjust their own configs and overrides, the default Meteor behavior in core may need a revision. There are many breaking changes to consider, so the latter is the most likely outcome: https://rspack.rs/guide/migration/rspack_1.x (AI skills to help: https://github.com/rstackjs/agent-skills) This is not definitely for Meteor 3.4.x or Meteor 3.5. ## Summary by CodeRabbit # Release Notes * **Chores** * Upgraded Rspack build toolchain to v2.0 and Meteor-Rspack to v3.0.0-beta.0 across all project templates and dependencies. * Updated related build tool versions including RSDdoctor plugin and TypeScript checker plugin. * **Bug Fixes** * Improved process detection to prevent unintended termination of client connections. * Enhanced error reporting during dependency installation with more detailed diagnostics. * **Configuration Updates** * Refined build cache strategy and module resolution settings for improved build performance.

I need to be able to upgrade Snap from 6.09 to newest, by directly using MongoDB 3.
Node.js does not support armhf, armv7, 680x0, etc. So I’m still looking for programming language that would run at all of my devices.
I need to be able to build offline. And not download half the Internet when building.

xet7 · June 23, 2026, 3:19am

@alimgafar

So you’re satisfied with the migration? Wekan’s future is still with MeteorJS?

For MeteorJS version of WeKan, I’m still in progress of pushing it as far as possible.

Other versions of WeKan are for platforms where Meteor does not currently run at all.

xet7 · June 23, 2026, 3:23am

@alimgafar

For MeteorJS version of WeKan, current target is to get as many WeKan open issues implemented and fixed and closed, as possible, ASAP.

xet7 · July 11, 2026, 12:23pm

My FerretDB v1 SQLite fork with new features

Used at default for all new WeKan installs
Files are saved to filesystem. Not to database.

arm64 Docker: WeKan FerretDB v1 SQlite

s390x Docker: WeKan FerretDB v1 SQlite

xet7 · July 23, 2026, 10:26pm

Snap Stable upgraded ! Sandstorm available !

xet7 · July 24, 2026, 12:54am

Somebody said that my FerretDB v1 Fork works with SQLite and PostgreSQL. But I have not tested MySQL, MariaDB and SAP Hana yet, help welcome.

github.com/wekan/wekan

Feature Request: PostgreSQL Support (was: Fresh v10.27 issue with new board and importing)

opened 04:17AM - 23 Jul 26 UTC

closed 11:30PM - 23 Jul 26 UTC

AmigaAbattoir

Targets:FerretDB2-PostgreSQL Targets:FerretDB1-PostgreSQL

Started with a fresh volumes for wekan and database using (docker with FerretDB …2 + PostgreSQL). I created an admin user and logged. When I logged in and got to the boards page there was this in the console: ``` eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:291 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'remove') at eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:291:11846 at Generator.next (<anonymous>) at n (eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:9:104776) at l (eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:9:104973) ``` I can make a new board, however if I try adding lists they do not show up until I reload the board. If I try adding cards, they do not appear. At that point, if I try going back to my boards, it doesn't show the board. If I try to import a board with out members (and say map later), when the board loads up, only the lists show up, no cards, and then there are console errors: ``` Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'remove') at eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:291:11846 at Generator.next (<anonymous>) at n (eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:9:104776) at l (eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:9:104973) eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:3 Exception from Tracker recompute function: undefined eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:3 Error: Bad index in range.removeMember: 0 at n.removeMember (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:162:6824) at https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:163:23234 at t.withComputation (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:134:4362) at t.nonreactive (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:134:4231) at Object.removedAt (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:163:23125) at Object.removed (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:154:3022) at https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:152:1641 at Array.forEach (<anonymous>) at i.diffQueryOrderedChanges (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:152:1597) at v (https://wekan.<HIDE MY URL>.com/eb8860f2b7f8221773b2c817b9b0116a6bba4a53.js?meteor_js_resource=true:154:2551) undefined ```

harry97 · July 24, 2026, 5:11am

The speed you went from 9.x to 10.33
Ease down on the LLM use, Lauri

xet7 · July 24, 2026, 5:47am

@harry97

Ease down on the LLM use, Lauri

Well, before LLM, I did only 7 releases of WeKan per day. That is very slow.

https://qusaisuwan.github.io/cc-incident/

https://news.ycombinator.com/item?id=48953519

I’m only 1st top GitHub Committer at Finland:

xet7 · July 24, 2026, 5:59am

@harry97

Can you help upgrade Sandstorm to Meteor 3 ?

Currently I’m fixing WeKan drag drop bugs of board icons at All Boards page.

xet7 · July 24, 2026, 6:17am

@harry97

Here is the relevant discussion about upgrading Sandstorm to Meteor 3:

harry97 · July 24, 2026, 6:19am

I sent you a DM on discord. Let’s see what happens

harry97 · July 24, 2026, 2:08pm

For all you sandstorm peeps out there

github.com/sandstorm-io/sandstorm

Complete the Meteor 3.4.1 migration with Rspack

sandstorm-io:dev ← harryadel:meteor-3.4-continuation

opened 06:42AM - 24 Jul 26 UTC

harryadel

+36198 -12061

## Summary This continues #3767 while preserving all 33 of Michael Nutt's commi…ts and their original authorship. The latest `dev` history was incorporated with a normal merge commit; none of Michael's work was squashed or rewritten. The continuation now: - upgrades both the Shell and embedded test app to Meteor 3.4.1 - resolves Blaze 3.0.3, Mongo 2.3.0, and upstream `vlasky:galvanized-iron-router` 2.2.1 - moves both applications to Meteor's Rspack integration - removes `fourseven:scss` and converts the Shell Sass tree from `@import` to modules - removes application use of Underscore, direct jQuery APIs, and `meteor/http` - retains npm jQuery 4 as the single jQuery implementation; Meteor's resolved `jquery@3.0.2` is only the upstream adapter that calls `require("jquery")`, and Galvanized Iron Router is not locally forked - replaces the deprecated npm `request` download path with Fetch streaming - adds DNS-pinned, redirect-aware SSRF-safe Fetch helpers - adds a repository-local Meteor 3 fork of `kenton:accounts-sandstorm` - this was kept local to unblock the migration; publishing a corresponding Atmosphere release still requires the package maintainers - replaces the test fixture's Node 14/Mongo payload with a staged Meteor 3.4.1 Node runtime - makes migrations a top-level startup gate and propagates CI test failures correctly - updates the pinned Chromium Clang toolchain to Clang 22 and the MongoDB 7 artifact to the Ubuntu 22.04/OpenSSL 3 build - modernizes Node 22 dependencies and tooling: `ldapjs` to `ldapts`, OpenID Client 5 to 6, legacy SMTP packages to Nodemailer/SMTP Server, Grunt Webfonts to Fantasticon, and ESLint 8 legacy configuration to ESLint 10 flat configuration - replaces the abandoned GCP ACME plugin with an attributed repository-local npm fork using Google Cloud DNS 5 - removes obsolete direct packages and lockfile-only vulnerable transitive versions where compatible - updates Meteor's generated runtime build helpers to patched releases and enforces a production high/critical audit gate ## Validation completed - native Sandstorm and BoringSSL compilation with the repository-pinned Clang 22 toolchain - production Rspack Shell and test-app builds - real SPK creation, installation, and grain launch with Node 22.22.1 - MongoDB 7 startup and fresh migrations 1–42 - authentic build-308 installation and upgrade through the real MongoDB 2.6 → 7 migration path - preservation and launch of an existing build-308 grain after upgrading to the Meteor 3.4.1 Shell and Node 22 test app - deterministic migration-42 failure before durable mutation, externally unreachable failed startup, and successful explicit restart recovery - multi-replica migration coordination, including both replicas waiting for primary and new-server migrations and race-safe observer cleanup - 38 Meteor server tests - 3 native CLI tests - full native `make test` path with 1,158/1,158 Nightwatch assertions passing - profile propagation for name, avatar, handle, pronouns, and server runtime - OIDC sign-in URL/index migration, LDAP, incoming/outgoing SMTP, router navigation, trash, and payment regressions - Stripe customer creation, card add/primary/delete behavior, last-card protection, existing/new subscription changes, cancellation and repeated cancellation, declined-card handling, webhook replay, and billing data sanitization - real SSRF-safe HTTPS app downloads with DNS pinning - ESLint 10 with zero errors and zodern-generated TypeScript declarations/type checking - zero critical/high findings in application and generated production runtime audits - zero production findings for the test harness, test app, icon toolchain, Sandcats plugin, and staged Node runtime The Shell has one remaining moderate advisory in `qs` nested inside `meteor-node-stubs`; it is inherited from the current Meteor compatibility package and no compatible high/critical issue is present. ## Intentionally deferred / out of scope Per the agreed release-gate scope, this PR does not wait on: - publishing the local `accounts-sandstorm` fork to Atmosphere - byte-identical Sass/CSS equivalence or targeted visual comparison work - Rspack HMR validation These are deliberately deferred rather than uncompleted claims of validation.

harry97 · July 27, 2026, 11:20am

xet7 · August 8, 2026, 12:43pm

WeKan at Free Software Conference Ukraine 2026-07-19: 10 years of WeKan

Video and slides of my talk here:

https://wekan.fi/docs/