The entry above removed the source maps from every platform. A released image then crash-looped:

  Error: ENOENT: no such file or directory,
    open '/build/programs/server/packages/ecmascript.js.map'
    at /build/programs/server/boot.js:101:29

“Nothing on any loading path reads a .map” was true of the client and false of the server. boot.js reads every map NAMED in programs/server/program.json, at boot, unconditionally:

  serverJson.load.forEach(function (fileInfo) {
    if (fileInfo.sourceMap) {
      var rawSourceMap = fs.readFileSync(
        path.resolve(serverDir, fileInfo.sourceMap), 'utf8');

63 of the 102 load entries name one — 60 MiB — so deleting the files left 63 dangling names and the server died before it opened its port.

The names now go with the files: the same pass deletes sourceMap and sourceMapRoot from every load entry. The client was never affected and still is not — its program.json names no maps at all (678 manifest entries, zero sourceMap fields) and webapp reads only program.json itself at startup.

Verified by BOOTING a trimmed bundle rather than by reading the code again: with uWebSockets.js, the legacy client and all 4766 maps removed, node main.js loads the whole server and reaches AccountsServer.init, failing only on the deliberately unreachable MONGO_URL it was given. That is the check that was missing the first time, and tests/bundleTrim.test.cjs now pins the invariant boot.js actually requires — every map the manifest names exists on disk — for both settings of --keep-maps.

An instance serving FerretDB printed this at every restart:

  WeKan: BOTH databases have been written to since the migration.
    MongoDB  last written 2026-08-16 01:41 (WiredTiger.wt)
    FerretDB last written 2026-08-16 01:38

Nothing had opened that MongoDB in a month. The giveaway is in the report itself: the MongoDB timestamp is the minute the snap started, three minutes AFTER the FerretDB it is being compared against.

bin/ferretdb-migration-stale decides MongoDB has been written to from the mtimes of the WiredTiger data files, and its own header admits an mtime cannot tell “somebody used this database” from “this database was started”. bin/database-autopick is the answer to that — it reads both copies and compares their contents. But to read MongoDB it STARTS mongod, and starting mongod does recovery and a checkpoint, which stamps exactly the files the staleness check reads. So the diagnostic manufactured its own evidence: after one run, MongoDB looked freshly written forever and the ambiguity could never resolve, however long nobody touched it.

The read now notes the newest data-file mtime before mongod starts and puts anything newer back afterwards — files mongod CREATED during the read included, since a new journal file is the newest thing in the directory and reports as a write on its own. mongod does not use mtimes, and what it checkpointed is not user data, so the metadata is made to say what is true. Every way out of the read restores, including the failures, because a failing read is exactly when the ambiguity gets reported. A write that happened BEFORE the read still survives it: the point is to hide WeKan’s own read, never somebody’s work.

The same instance went OFFLINE at every restart. wekan-control ran the comparison synchronously and unbounded before anything opened the web port — and it starts each database on a temporary port to read it, which on a real instance is minutes. Until it returned a browser got a connection timeout, and the reason was in snap logs, the last place somebody whose site is down thinks to look.

That is #6592 one step earlier than where it was fixed. The database WAIT already serves a waiting for its database page; the helpers for it were defined 200 lines BELOW the comparison that needed them. They move up, and the comparison uses them — after the same grace period, so a comparison that finishes in seconds does not flash a page up and teach proxies to cache a 503 for a healthy site.

And a bound. WEKAN_AUTOPICK_TIMEOUT is 900 seconds by default; when it runs out WeKan says so, changes nothing, and starts on the database already selected. Stopping the comparison is safe — it never deletes anything on either side, and the merge it may be in the middle of only INSERTS what is missing, so a partial one is fewer documents copied and the next start finishes the job. Serving the site beats finishing the comparison.

WEKAN_AUTOPICK was an env var and nothing else, so an admin whose site was down had no supported way to skip the comparison. It is a snap config key now, with the bound beside it, and the timeout message names both — somebody reading it is somebody whose site just came up late:

  snap set wekan autopick=false
  snap set wekan autopick-timeout=1800

This is the other half of the entry above. Before that fix the comparison ran at EVERY start, so every restart took the site down for a comparison that could never conclude. One stops it recurring; this one makes it survivable.

programs/server/npm/node_modules is 347 MB of an ~850 MB bundle, and measuring its require graph says 206 MB of that is unreachable from any server entry point. Two things cause it, neither a bug in Meteor:

• The tree is outside the bundler’s graph. Meteor 3.5 compiles through rspack — the server output is minified, and programs/server/app/app.js requires only 76 bare specifiers because rspack inlined the app’s real dependencies into it. But this tree is what Atmosphere packages declare with Npm.depends() and load through Npm.require(), which rspack cannot follow. It is largely the INPUT to a build whose OUTPUT ships beside it.
• It is a full npm install, devDependencies included.

Duplication is the smaller half: 586 distinct packages exist as 815 copies, but the redundant copies are only ~28 MB, because Meteor keeps per-package node_modules on purpose so packages can pin conflicting versions.

releases/prune-unreachable-npm.mjs removes 61.3 MiB, in four categories whose reason is PROVABLE rather than merely plausible — the standard the uWebSockets.js removal met: typescript (23.2 MiB, a devDependency of 196 packages here and a runtime dependency of none), openpgp with nodemailer-openpgp (21.3 MiB, reachable only through an optional nodemailer plugin nothing requires), @types/* (9.6 MiB across 24 copies, verified to contain no .js at all) and sinon (7.2 MiB, a test framework).

The remaining 145 MB of unreachable packages STAYS. jquery, hotkeys-js and the @azure storage adapters are almost certainly dead too, but almost certainly is not the standard, and the tail of 590 packages is where a static scan is most likely to be wrong.

Two independent safeties, because this is riskier than the uws removal was. The reachable set is recomputed from the bundle every run and deliberately OVER-approximated — once a package is reached, every file in it is scanned and every require() string literal counts. The policy then only proposes; the graph has a VETO, so an entry whose package is actually required is refused and said out loud rather than applied. And after deleting, every path in the reachable set must still exist or the run fails. Verified on a real bundle: 473M to 410M, with the reachable count 211 before and after.

WeKan ships 246 languages, 37 MB of JSON. What makes that affordable is one character in each of 246 near-identical blocks in imports/i18n/languages.js:

  load: () => import('./data/ace.i18n.json'),

A dynamic import() is a SPLIT POINT. rspack emits each language as its own chunk — measured on a built bundle, 238 chunks and 34 MiB of JS — and a browser fetches exactly one, about 145 KB for the language in use. Written instead as import data from './data/ace.i18n.json', or with require(), the same line stops splitting and 34 MiB joins the main bundle for every user, in every language. That edit is made by hand each time a language is added, which is why it wants a guard rather than a convention.

Seven checks: every entry has a load:, every load: is the dynamic form, none uses require(), no static import of a data file, nothing outside languages.js imports one, every file is claimed and every claim has a file, and a Transifex pull writes the file the app actually loads.

The last two are symlink-aware, and that is the point of them. .tx/config’s lang_map renames most of Transifex’s underscored locales to WeKan’s hyphenated files; for the two it does not — km_KH and ru_RU — the hyphenated name is a SYMLINK to the file Transifex writes. Two names for one file, not two copies. Reading it the other way costs a language its real translations, so both checks compare through realpath and say so.