Reference Extension Laravel Package

Technical Evaluation

What this actually is. acmecorp/reference-extension is a Bolt CMS extension skeleton — a starting template intended to be cloned and renamed, not a library to be installed and called. That distinction drives almost every conclusion below. The description ("can be used as a starting point to base your own extensions on") is the maintainer explicitly telling you the artifact has no runtime value of its own.

Architecture fit — poor for a Laravel stack. Bolt is a PHP CMS historically built on Silex and now on Symfony components; it is not Laravel. This package will therefore not expose a ServiceProvider, will not participate in Laravel's package auto-discovery, will not ship migrations, config publishing, facades, or any of the conventions a TPM would expect from a Composer-installable Laravel dependency. Requiring it in a Laravel composer.json yields no wiring and no usable API — at best dead weight in the vendor tree, at worst a conflicting transitive constraint on Symfony or PSR packages.

Integration feasibility — low, and conditional on running Bolt. If the target application is a Laravel service, feasibility is effectively zero: there is no adapter path that makes a Bolt extension callable from Laravel without adopting Bolt's container and event system. If the organization happens to run Bolt for a specific site, feasibility improves to "moderate" — but even then you would scaffold from it rather than depend on it.

Technical risk — elevated, mostly from immaturity and ambiguity.

• Adoption signals are weak. Five stars and zero dependents indicate no production validation anywhere in the ecosystem. The composite score of ~2.06 is consistent with a package that has never been exercised outside its author's machine.
• acmecorp/ vendor namespace. Combined with the upstream bolt/reference-extension reference, this strongly suggests an internally forked or renamed template. That raises provenance questions: is this the canonical Bolt skeleton, a stale fork, or a placeholder published to a private registry and mirrored publicly?
• Template drift. Reference scaffolds rot silently. The real risk isn't a CVE in this package; it's that the conventions encoded here — directory layout, registration calls, event names — no longer match current Bolt core. Copying stale patterns is more expensive than having no template.
• Release-date ambiguity. A last release of 2025-12-04 should be reconciled against actual commit history before anyone treats this as actively maintained.
• Licensing is clean. MIT is compatible with essentially any downstream use, so legal review is not the blocker.

Key questions to resolve before any investment.

1. Which Bolt major versions does this skeleton target, and against which core version was it last verified?
2. Is the intent to require this package as a dependency, or to copy it as a scaffold? (Only the second is coherent.)
3. Why does an acmecorp/reference-extension exist when bolt/reference-extension is the upstream? What was changed and why?
4. Does the repository contain tests, CI, and a documented extension registration contract?
5. Is Bolt itself part of the target architecture at all, or is this being evaluated under a mistaken assumption that it is a Laravel package?
6. What PHP version constraint does it declare, and does that intersect with the platform's supported runtimes?

Verdict. Treat as a documentation artifact, not a dependency. It cannot be scored on the same axes as a runtime library because it isn't one.

Integration Approach

Stack fit. None for a Laravel application. The package assumes Bolt's bootstrap, its extension manager, and its service container. There is no published bridge, and writing one would amount to reimplementing Bolt's extension loading inside Laravel — an unjustifiable effort for a five-star scaffold.

Recommended path — vendor the patterns, not the package. The only defensible integration is a one-time archaeological pass:

1. Read the skeleton to extract its conventions: how an extension declares metadata, registers routes and event listeners, exposes configuration, and structures templates.
2. Translate those conventions into native Laravel equivalents — a ServiceProvider, config/*.php with mergeConfigFrom, published migrations, and EventServiceProvider registrations.
3. Discard the Bolt-specific bootstrapping entirely. Do not add acmecorp/reference-extension to composer.json; do not create a lockfile dependency on it.

If Bolt is genuinely in scope. Scaffold the extension by cloning the upstream bolt/reference-extension at the tag matching your Bolt core version, then pin and vendor it internally. This removes the ambiguous acmecorp fork from the supply chain and gives you a version you can diff against upstream.

Compatibility to verify before any of the above. Bolt major version, PHP constraint intersection, and Symfony component constraints. Because Bolt 3 (Silex) and Bolt 4/5 (Symfony) are structurally different, a skeleton written for one is not a usable template for the other. Getting this wrong is the single most likely way to waste engineering time here.

Sequencing.

1. Confirm architecture. Establish whether Bolt is in the target stack. If not, close the evaluation — this is the highest-leverage step and it precedes all others.
2. Provenance check. Diff the acmecorp fork against upstream bolt/reference-extension; confirm the fork is intentional and documented.
3. Version pin. Identify the Bolt core version in use and confirm the skeleton targets it.
4. Extract, don't install. Produce a short internal note mapping skeleton conventions to the team's Laravel conventions.
5. No production dependency. Nothing from this package enters the runtime dependency graph.

Effort estimate. Under a day for the provenance and version checks if the architecture question resolves cleanly; near-zero ongoing effort thereafter, because nothing is deployed.

Operational Impact

Maintenance. Minimal if the "extract, don't install" recommendation is followed — there is no dependency to patch, no CVE feed to monitor, no version bumps to schedule. If someone ignores that guidance and requires the package, maintenance cost inverts: you inherit an unmaintained template's constraints with none of the benefits, and every future framework upgrade becomes a negotiation with a vendor who has published nothing since the last tag.

Support. There is no support channel. Five stars and zero dependents mean no community, no issue backlog with answers, and no Stack Overflow corpus. The upstream Bolt project has its own documentation and forum, and that is where any real question would land — but it will not answer anything about the acmecorp fork specifically. Internal ownership of the extracted conventions should be assigned to a named engineer, because there is no external backstop.

Scaling. Not applicable in the conventional sense. The package contributes no runtime code path, so it cannot be a scaling bottleneck. The scaled concern is organizational: if multiple teams copy this skeleton independently and each diverges, you accumulate inconsistent extension conventions with no shared source of truth. Mitigate by publishing the extracted conventions once, internally, rather than pointing teams at the repo.

Failure modes.

• Silent convention drift. Bolt core moves; the skeleton does not. Teams copying it six months from now generate extensions against an obsolete contract. This is the primary failure mode and it fails quietly — code compiles, extension loads, behavior is subtly wrong.
• Accidental dependency. A developer adds the package to composer.json because it appeared in an evaluation, and it shadows or conflicts with Symfony constraints later. Cheap to prevent, expensive to diagnose.
• Fork divergence. If the acmecorp fork carries local modifications, upstream fixes never arrive, and nobody remembers what was changed. Document the diff or eliminate the fork.
• Misclassification. The most likely failure is evaluative, not technical: this gets triaged into a Laravel backlog where it does not belong, consuming review cycles repeatedly.

Ramp-up. Low for an engineer familiar with Bolt — the skeleton is deliberately small and readable, which is its one genuine strength. For a Laravel-only team, ramp-up is inverted: the time is spent unlearning Bolt idioms and mapping them to Laravel's, and that translation work is the entirety of the value on offer. Budget a half-day of senior engineer time for the extraction pass and treat that as the complete investment.

Opportunity assessment. The 38.37 opportunity score is generous relative to the evidence. The package's realistic contribution is a small, one-time transfer of structural conventions to an internal Laravel package — worth capturing in a short document, not worth a dependency, an integration project, or a support commitment. Recommend closing the evaluation with that output and revisiting only if Bolt enters the architecture for an unrelated reason.