Mobile editors: fix not-loading + ES2022 target / i18next crash

[moodyjmz]

Two mobile fixes that landed together.

1. Mobile editors don't load — reported in Regression: mobile editor doesn't load in latest-dev DocumentServer#258. The grunt→pipeline migration dropped the mobile deploy step, so the mobile folder shipped with only resources/ (404). Ported as deploy-mobile.js + verify-deploy assertions.
2. ES2022 target / i18next crash — the mobile bundle built at esbuild target:'es2015' throws TypeError: we is not a function on launch. Fixed by centralising the browser target to ES2022.

Root cause + validation

Crash cause. The esbuild minifier swap (f0e183749c) set target:'es2015', which downlevels the whole bundle — including i18next 25's class-based internals. esbuild's ES2015 class-field lowering mis-compiles a Translator internal → we is not a function. Not webpack-vs-grunt and not the i18next dep bump (it ran fine under grunt's Terser build) — mobile was always a webpack build; only the minifier changed.

Fix. Collapse the four scattered, contradictory browser targets (babel >0.25%, esbuild es2015, postcss Chrome 49, decided floor) into a single source of truth build/browser-floor.mjs at ES2022 (Nextcloud floor: iOS 17 / Safari 17; Android 9 = updatable WebView). ES2022 keeps class fields native, so the breaking transform never runs. Also: restore drop_console (the esbuild swap silently dropped Terser's), make build mode explicit + echoed in the pipeline banner, decouple mobile watch to WATCH=1, and add a verify-browser-target gate that fails the build if a target literal (string/array/object) is hardcoded in a config instead of imported from browser-floor.mjs. (It's a static-source check — it asserts the import + absence of a literal, not that the imported value is the one wired in.)

Validation (production build in the eo dev container):

• __publicField (esbuild class-field lowering helper) = 0; 79 native # private fields retained → the es2015 transform is gone.
• i18next is ready = 0 in all four mobile bundles → drop_console restored.
• All four mobile editors load and render in-browser (confirmed manually).
• verify-browser-target passes, and fails on a planted hardcoded target (string, esnext, and array-literal shapes).

Review follow-ups (addressed): the two verify gates were hardened after review —
verify-browser-target now rejects array/object/esnext target literals (not just
ES-year strings), and verify-deploy asserts the actual dist/js/app.js entry rather
than only the directory. The build/README pipeline reference was also brought up to the
current 5-phase structure.

Fixes Euro-Office/DocumentServer#258
Follow-ups: #154 (CI mobile validation), Euro-Office/DocumentServer#259 (Makefile dev/prod targets)

---

Commits are AI-co-authored (Claude Sonnet 4.6) and adversarially reviewed/verified (Claude Opus); the fix was validated against a real production build + browser load. Human diff review still wanted.

[MonaAghili]

Hey @moodyjmz reviewed it with help of Claude and I share it's findings with you

Reviewed the branch diff directly against the grunt configs it replaces and ran the browserslist query live. Two core fixes are correct. One real bug. One new behaviour worth flagging.

---

Core fix 1: deploy-mobile.js — correct

Cross-checked every copy step against build/documenteditor.json (the grunt config this replaces):

What gets copied	grunt	deploy-mobile.js
index.html → index.html + index_loader.html	copy.index-page — both map to same source	copyFileSync twice from same source ✓
css/*.css (no maps)	copy.assets src: '*.css'	copyDirFiltered({ include: ['*.css'] }) ✓
dist/**	copy.assets src: '**'	copyDir(distSrc, dest/dist) ✓
locale/*	copy.localization src: '*'	copyDir(localeSrc, dest/locale) ✓
resources/img/** (per-editor)	copy.images-app	copyDir(imgSrc, dest/resources/img) ✓
apps/common/mobile/resources/img/**	copy.images-common[0]	copyDir(commonMobileImg, ...) ✓
apps/common/main/resources/img/about/**	copy.images-common[1]	copyDir(aboutSrc, .../about) ✓

resources/css/ not copied — that directory doesn't exist in the source tree; grunt's mobile.css task was a no-op. Not a gap.

The .gz files in the v9.3.2 image (index.html.gz etc.) come from documentserver-static-gzip.sh in document-server-package, which gzips everything in web-apps/ during packaging — not the web-apps build's job. Not a gap here either.

Phase ordering is correct: deploy-mobile (Phase 2) runs strictly after webpack writes to the source tree (Phase 1) and strictly before deploy-theme-images (Phase 3), which overwrites the same resources/img/ paths and must win.

---

Core fix 2: ES2022 target / i18next crash — correct

target: 'es2015' made esbuild emit __publicField() helpers to downlevel class fields. i18next 25's Translator uses native class fields. __publicField corrupts the prototype chain → TypeError: we is not a function. Moving to ['safari17', 'chrome111'] (ES2022) keeps class fields native. Right fix, right signal to check (__publicField count = 0).

dist/js/app.js stable-name assertion in verify-deploy is correct — webpack config confirms filename: 'dist/js/[name].js' with no hash, entry name app.

---

Bug: and_chr >= 111 doesn't work as a version floor

build/browser-floor.mjs:

export const BROWSERSLIST = ['iOS >= 17', 'Safari >= 17', 'and_chr >= 111', 'not dead'];

Ran this live against the installed browserslist:

and_chr >= 111  →  ['and_chr 132']   // single current version only
chrome >= 111   →  23 entries        // actual floor

browserslist does not track historical and_chr versions. and_chr >= 111 resolves to whatever the current and_chr is — not "Chrome 111 and above as a floor." The correct query for Android Chrome version floors is chrome >= 111 (browserslist resolves desktop Chrome historically, and it's the right V8 proxy for Android Chrome).

The verify-browser-target gate only checks that and_chr appears in the array — it doesn't validate that the version constraint resolves. So the gate passes and this is invisible.

Functionally harmless today (current Chrome >> 111, both support ES2022 natively, so babel/postcss output is identical). But the intent isn't landing.

Fix: 'and_chr >= 111' → 'chrome >= 111'

---

New behaviour: drop: ['console', 'debugger']

-new EsbuildPlugin({ target: 'es2015', css: true })
+new EsbuildPlugin({ target: ESBUILD_TARGET, css: true, drop: env === 'production' ? ['console', 'debugger'] : [] })

This was not in the webpack config on main (verified). esbuild's drop: ['console'] removes the entire call expression including arguments — console.log(fn()) silently drops fn() in production. Intentional for a production bundle, but it's a new behaviour in this pipeline, not a restore.

---

Verdict: approve. Fix and_chr >= 111 → chrome >= 111 inline or as immediate follow-up.

[moodyjmz]

Thanks @MonaAghili — the and_chr >= 111 catch was right and is fixed in 700138d (chrome >= 111, which resolves as a real historical floor; and_chr is latest-only). Everything else corroborates too.

One point I'd push back on: the drop: ['console', 'debugger'] "new behaviour, not a restore" framing measures against the wrong baseline. main is already post-regression — the esbuild swap is what removed the console-dropping. The config immediately before that swap had it under Terser, so re-adding it restores prior pipeline behaviour rather than introducing new behaviour.

The side-effect caveat (console.log(fn()) drops fn()) is real but not new — Terser's drop_console did the same thing, so this reintroduces known behaviour, not a novel risk. Production-only, so no dev impact.

Evidence

f0e183749c^:vendor/framework7-react/build/webpack.config.js:88 (config just before the esbuild swap):

new TerserPlugin({ terserOptions: { compress: { drop_console: env === 'production' } } })

The swap replaced Terser with EsbuildPlugin({ target: 'es2015', css: true }) (now on main, no drop). This PR re-adds drop: ['console','debugger'].

_{Comment prepared with Claude (Opus), verified against the branch.}

[MonaAghili]

LGTM!