pc.app - is not available. Breaking projects.

[Maksims]

Since 2.19, using pc.app is null, which breaks many of our projects, as we have use it a lot.

[LeXXik]

Personally, I think we should start deprecating pc namespace at some point. Maybe 3.0.0 is a good place? Users would then stay on 2.x engine, or create window.pc proxy themselves, if they wish so.

[Maksims]

I don't believe we should force some behaviors on users, leading to breaking changes.

[OlegGedzjuns]

pc.app is null if playcanvas-2.19.2.dbg.js is used
playcanvas-2.19.2.dbg.mjs - pc.app is available

[LeXXik]

Doesn't pc proxy now makes Editor projects larger, because it has to pull everything from the engine? No treeshaking.

[AlexAPPi]

Doesn't pc proxy now makes Editor projects larger, because it has to pull everything from the engine? No treeshaking.

I agree. That is why I use an abstraction layer in the form of engine.ts across all libraries, so engine exports can be centrally overridden, proxied, or adapted for the user. As an alternative, we could introduce a dedicated import utility that resolves dependencies for different integration patterns. In this regard, a global export remains a relatively expensive mechanism in terms of maintainability and flexibility.

[mvaligursky]

I tracked this down — fix in #8837.

Root cause: the regression came in with the esbuild build migration (#8722) in 2.19.0, not from any runtime change. The UMD build (playcanvas.js) wraps the engine as an esbuild IIFE whose exports are live getters (app: () => app), then bridges that namespace onto the global exports (= window.pc) with a hand-written footer:

var pc = (() => { … __export(index_exports, { app: () => app, … }); return __toCommonJS(index_exports); })();
Object.assign(exports, pc);   // ← snapshots every getter to its load-time value

Object.assign invokes each getter once and copies the value. At module-load time no application exists yet, so app is null, and window.pc.app becomes a frozen null data property. When an app is later constructed and the engine sets its internal app = this, window.pc.app never updates.

This is why:

• It only affects mutable exports — app is the one that matters in practice.
• The ESM build (.mjs) is fine — native ES live bindings (matches @OlegGedzjuns' observation that .dbg.mjs works but .dbg.js doesn't).
• Scripts using this.app are unaffected; only code reading the global pc.app breaks (e.g. the classic orbit-camera mouse-input script, which is what surfaced it via the WebXR AR Starter Kit and forum thread #42337).

Fix (#8837): preserve the getters when bridging to the UMD namespace —

Object.defineProperties(exports, Object.getOwnPropertyDescriptors(pc));

Verified by loading both UMD bundles as a browser global and constructing an AppBase: before, pc.app stays null; after, pc.app === app. No effect on the ESM build.

[Maksims]

Doesn't pc proxy now makes Editor projects larger, because it has to pull everything from the engine? No treeshaking.

You can tree-shake ESM builds, with import/export.
But this change broke existing functionality for CJS builds, which is not treeshakeable regardless of global pc.

[mvaligursky]

Heads-up: the fix in #8837 (shipped in 2.19.3) has an unintended side effect — copying the export descriptors made every UMD export getter-only, which breaks code that reassigns members of the global pc namespace. The Editor's classic-script worker does exactly this (pc.createScript = … / pc.registerScript = …), so after 2.19.3 those overrides fail and the engine's real registerScript runs in the worker → Cannot read properties of undefined (reading 'scripts') (no application exists in the worker, so AppBase.getApplication() is undefined).

Follow-up #8839 keeps pc.app live and restores writable/overridable exports (get + set accessor), matching the pre-2.19 UMD behaviour.