Mjr Cache Aware Class Loader Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — answered: borrow. This package is not a procurement candidate; it is prior art. It answers "has anyone solved cache-aware delivery of dynamically loaded ExtJS/MJR classes?" with "yes, once, in 2016, inside a Symfony bundle." The decision it supports is to reimplement the caching contract against our own asset pipeline, not to adopt code.
• Legacy admin frontend: invest or exit. If "our ExtJS/MJR admin panel is slow" is on the roadmap, this repo documents the intended load path (class-name resolution → per-class JS response → ETag/Last-Modified/Cache-Control so repeat loads hit browser, proxy, or CDN cache). That informs the sizing of a performance spike and the sizing of an exit migration — and it argues that the caching win is available without extending the legacy stack's life.
• Vendor and stack due diligence. Useful reference when assessing a Modera-based product or inheriting a Symfony 2/3 + MJR codebase: it shows what the runtime expected of the HTTP layer, and it flags the maintenance exposure we would inherit.
• Supply-chain screening — a decision to record, not act on. Zero stars, zero dependents, last release June 2016, repository read-only. That profile belongs on the "do not adopt" list. Treat its presence anywhere in our estate as a legacy-stack signal, not a dependency to upgrade.
• Metadata integrity. The package's own one-line description bills it as a "Laravel/PHP class loader kept in sync with cache state," which is materially wrong — the code is a Symfony bundle for MJR/ExtJS resource loading. The PM decision here is procedural: any package passing intake on description alone was mis-scored, and a 30-second look at the repo layout would have caught it. Fix that check before the next evaluation cycle.

When to Consider This Package

Consider it only as a reference when all of these hold:

• You are auditing or maintaining a Symfony 2.x/3.x application using Modera MJR / ExtJS, not a Laravel app.
• Your question is "how did the original implementers scope HTTP caching for dynamically loaded JS classes?" — you want a design sketch, not a runtime dependency.
• You need to characterize a Modera-based product's frontend architecture and its maintenance exposure for a portfolio or migration assessment.

Look elsewhere — do not adopt — when:

• You are on Laravel. No service provider, no package discovery, no Laravel-native integration path. Adopting it means adopting Symfony bundle idioms for one asset concern. The description's Laravel framing is not supported by the code.
• You need maintained code. Read-only since 2016 means no patches, no PHP 8 / Symfony 5+ compatibility work, no security response, and no upstream to escalate to. Ownership transfers to us permanently.
• You need modern asset delivery. Vite/AssetMapper, content-hashed or signed URLs, and CDN cache rules solve the same problem with a maintained toolchain and far less custom surface area.
• Compliance requires provenance. An unmaintained read-only mirror with no dependents is exactly what shows up in an audit.

How to Pitch It (Stakeholders)

To executives: This is a dormant 2016 component from a niche Symfony/ExtJS stack, with no maintainers, no users, and no release path — we should not put it in production. Its only value is documentary: it confirms the legacy admin-panel performance problem was real and was partially solved by serving class files with browser cache headers. It is a one-day reference read, not a line item. Worth flagging: our intake summary mislabeled it as a Laravel package, which is a process gap, not a product gap.

To engineering: Do not add this dependency. It is structurally wrong for our Laravel codebase, unmaintained since 2016, and read-only — no patches, no security response. What is worth 30 minutes is the transferable idea: stable class URLs plus content-derived validators (ETag/Last-Modified), a shared cache in front to honor them, and deploy-time invalidation so a release does not serve half-stale Ext.define payloads. If legacy admin performance is on the roadmap, fold that contract into a scoped spike against the current asset pipeline or CDN config. If it is not, close the evaluation, and treat this dependency's presence in the estate as a reason to prioritize the ExtJS exit rather than extend its life.