Use Celilo clientConfig publication and window.__MODULE_CONFIG__ for browser settings #77

New issue

Open

opened 2026-10-24 07:07:06 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-10-24 07:07:06 +00:00

Owner

Lunacycle currently generates config.js itself in celilo/scripts/setup-web.ts (buildClientConfigJs), assigns window.LUNACYCLE_CONFIG, and uploads with the lower-level public_web API. apps/lunacycle-web/src/contexts/AuthContext.tsx reads that application-specific global; index.html loads /config.js.

Migrate to Celilo's standard public_web.publishStaticSite({ ..., clientConfig }) and window.MODULE_CONFIG configuration path. The helper writes public settings into a writable website overlay and uploads them with the built assets. This is a standardization task, not a claim that deployed Lunacycle is broken.

Preserve the existing runtime settings (AUTHENTIK_URL, CLIENT_ID, APPLICATION_SLUG, REDIRECT_URI), apex and www hosting, /api reverse proxies, browser login/callback behavior, and development defaults. Keep credentials out of browser configuration and stop mutating packaged build output to inject settings.

Before switching, verify compatibility between the Celilo version Lunacycle uses, its packaged dist/apps/lunacycle-web layout, and the helper's web-root/overlay contract. Do not assume changing the browser global alone completes the migration. Celilo issue celilo/celilo#1643 tracks the clientConfig/global naming mismatch; coordinate with it without inventing an unsupported name.

Acceptance:

The publication hook uses the supported helper and public configuration input; browser code and declarations read the standard global.
config.js loads before application code; development and deployed configurations both work.
Tests cover the generated settings, upload/publication path, both hostnames and their /api routes, and the real browser OIDC login/callback.
Remove the duplicate generator and obsolete LUNACYCLE_CONFIG references once the migration is verified.

Research was local source inspection, not a test of the deployed fleet.

Lunacycle currently generates config.js itself in celilo/scripts/setup-web.ts (buildClientConfigJs), assigns window.__LUNACYCLE_CONFIG__, and uploads with the lower-level public_web API. apps/lunacycle-web/src/contexts/AuthContext.tsx reads that application-specific global; index.html loads /config.js. Migrate to Celilo's standard public_web.publishStaticSite({ ..., clientConfig }) and window.__MODULE_CONFIG__ configuration path. The helper writes public settings into a writable website overlay and uploads them with the built assets. This is a standardization task, not a claim that deployed Lunacycle is broken. Preserve the existing runtime settings (AUTHENTIK_URL, CLIENT_ID, APPLICATION_SLUG, REDIRECT_URI), apex and www hosting, /api reverse proxies, browser login/callback behavior, and development defaults. Keep credentials out of browser configuration and stop mutating packaged build output to inject settings. Before switching, verify compatibility between the Celilo version Lunacycle uses, its packaged dist/apps/lunacycle-web layout, and the helper's web-root/overlay contract. Do not assume changing the browser global alone completes the migration. Celilo issue https://git.celilo.computer/celilo/celilo/issues/1643 tracks the clientConfig/global naming mismatch; coordinate with it without inventing an unsupported name. Acceptance: - The publication hook uses the supported helper and public configuration input; browser code and declarations read the standard global. - config.js loads before application code; development and deployed configurations both work. - Tests cover the generated settings, upload/publication path, both hostnames and their /api routes, and the real browser OIDC login/callback. - Remove the duplicate generator and obsolete __LUNACYCLE_CONFIG__ references once the migration is verified. Research was local source inspection, not a test of the deployed fleet.

forgejo-admin added the

labels

2026-10-24 07:07:06 +00:00