RecompileFrontendAssets
class RecompileFrontendAssets
Constants
| REBUILD_LOCK_SECONDS |
How long one request may hold the rebuild lock. A process killed mid-rebuild — OOM, an evicted container, a deploy — never releases the lock, so this is also the longest anything can go un-rebuilt after a crash. Sixty seconds is roughly twice the slowest full rebuild measured against remote storage, where every compiled file costs a network round trip. Both failure modes degrade to the behaviour that existed before this lock, never to anything worse: the dirty flag outlives the lock, so after a crash the next request past the TTL rebuilds, and a rebuild that legitimately outruns the TTL simply lets a second request start one. |
Methods
No description
Flag this asset set as needing a rebuild, without touching the compiled files or their manifest revisions.
Rebuild this asset set in place if it has been flagged dirty, then clear the flag. Runs early in a freshly-booted request — one whose container reflects the current extension state — so the rebuilt output is correct.
Scoped to this asset set: the sets are independent, so forum, admin and common rebuild concurrently rather than queueing behind one another.
Details
at
line 42
__construct(Assets $assets, LocaleManager $locales, Dispatcher|null $events = null, SettingsRepositoryInterface|null $settings = null, Repository|null $cache = null, VersionerInterface|null $versioner = null)
at
line 67
void
markDirty()
Flag this asset set as needing a rebuild, without touching the compiled files or their manifest revisions.
The rebuild itself is deferred to the next request (see {\Flarum\Frontend\recompileIfDirty}): a request that toggles an extension booted before that extension's extenders were applied, so rebuilding here would bake the old sources — e.g. locale bundles without a newly-enabled extension's keys — into the manifest, and with the revision then matching, nothing would ever rebuild them. Deferring also means nothing is deleted or unset in the meantime: already-served asset URLs keep resolving, and the asset revision token doesn't flicker, so connected clients aren't prompted to reload for a rebuild that may not change anything they load.
at
line 85
void
recompileIfDirty()
Rebuild this asset set in place if it has been flagged dirty, then clear the flag. Runs early in a freshly-booted request — one whose container reflects the current extension state — so the rebuilt output is correct.
at
line 137
protected void
rebuildAndClear()
Rebuild the set, clear the flag, then announce.
The flag is cleared before announcing: if the process dies mid-rebuild the flag survives and the next request simply rebuilds again (a cheap no-op when the output already matches), while the event only ever fires once everything — including the bookkeeping — has settled.
at
line 150
protected string
rebuildLockKey()
Scoped to this asset set: the sets are independent, so forum, admin and common rebuild concurrently rather than queueing behind one another.
at
line 155
protected string
dirtyKey()
at
line 160
protected SettingsRepositoryInterface
settings()
at
line 181
void
recompile()
Rebuild the compiled assets in place.
Unlike {\Flarum\Frontend\flush}, nothing is deleted up front: each compiler renders its output and only overwrites the file (and its manifest revision) when the result actually differs. That means there is never a window where an already-served asset URL points at a missing file, and never a gap in the revision manifest that would flicker the asset revision token and fire a spurious "new version available" prompt on connected clients. A rebuild that produces identical output is a complete no-op. {\Flarum\Frontend\Event\AssetsRecompiled} is dispatched once the rebuild has finished, so consumers (e.g. the realtime broadcaster) read a settled revision.
at
line 188
protected void
commitAll()
at
line 220
void
flush()
deprecated
deprecated
at
line 231
protected void
flushCss()
deprecated
deprecated
at
line 243
protected void
flushJs()
deprecated
deprecated