Definitely Not V3 Laravel Package

Technical Evaluation

What it is, and why the framing matters. statamic/definitely-not-v3 presents itself two ways at once. The description claims a functioning "version guard" addon that asserts your Statamic install is not v3 and "fails loudly" on version drift. The prior engineering assessments read the repo as an empty addon skeleton — PSR-4 autoloading, an auto-discovered service provider, and nothing else. Both cannot be true, and the discrepancy is itself the headline finding: we cannot determine capability from the metadata alone. The only reliable source of truth is the repository contents, which are small enough to review end-to-end in under an hour. Until someone does that, no estimate based on the description's feature list should be trusted.

Architecture fit. Either way, the fit is narrow. As a version guard it is a one-line assertion about a framework version — something we can express in a Composer constraint or a CI check without a dependency. As a skeleton it is a reference layout, not a capability: no admin surface, no auth, no domain logic. It does not occupy an architectural slot we have open, and current Statamic ships first-party addon scaffolding (make:addon, official boilerplate) that covers the same ground with a maintainer behind it.

Integration feasibility. Technically trivial — tiny, zero dependencies, zero configuration. Practically it is a vendor-and-adapt exercise, not an adoption. The archive date and 2018-11-07 release mean it encodes Statamic v2 / Laravel 5.x-era conventions; addon bootstrapping and service-provider registration have moved on since. Expect to correct the manifest constraints rather than reuse them.

Technical risk. Very high as a runtime dependency, near-zero as a one-off read.

• Archived: no security fixes, no dependency bumps, no compatibility work.
• Zero dependents: no ecosystem evidence it boots against any version we would run.
• Version number is explicitly not a contract — that is the joke. A "3.0.2" release whose entire changelog reads "Stuff." is a punchline, not a change record.
• Unverified constraints: the supported PHP / illuminate/* / Statamic range is unpublished.
• Supply-chain friction: an archived 2018 package in composer.json will trip scanners and complicate the next framework upgrade.

Key questions

1. Is the intent a structural template or a runtime dependency? Only the template reading is defensible.
2. Does the repo actually implement the version guard the description advertises, or is it a bare skeleton? Confirm by reading source, not releases.
3. Which Statamic/Laravel generation are we on, and does this layout still match current addon conventions?
4. What does this give us that make:addon or copying four files does not?
5. Is the archive intentional retirement after the joke landed, or abandonment? Either way the operational answer is the same.
6. Has anyone verified it even installs against our pinned framework majors?

Integration Approach

Stack fit. Only relevant to legacy Statamic v2-era applications. On any currently supported stack the fit is coincidental at best. Treat this as a fork-and-adapt question and close the "should we depend on it" question early.

Migration path. Do not composer require into a live application. If the skeleton shape is genuinely useful, vendor it: copy the directory structure, service provider, and composer.json into an internal package under our namespace. We get the reference pattern without inheriting an unmaintained node in the graph. There is no meaningful installed base to migrate — zero dependents — so the "path off it" for existing users is simply inlining the files and dropping the constraint.

Compatibility. Three surfaces, none documented: PHP version; illuminate/* and Statamic range; and whether current addon conventions match this layout. The description's implied modern-compatibility is aspirational copy from 2018, not a verified constraint. With zero dependents there is no transitive signal to lean on — no integrations, no test matrix, no issue history reporting against recent versions.

Sequencing.

1. Hour one: one engineer reads the repo and settles the skeleton-vs-guard question in writing.
2. Diff the skeleton against current first-party addon generator output; keep the diff as the useful artifact.
3. Copy anything worth keeping into an internal namespace with our own constraints and pinned versions.
4. Record the outcome in the dependency register as reference only, not a dependency, with a one-line rationale and a date, so it is not re-litigated next quarter.
5. If any roadmap estimate assumed an addon is expensive to scaffold, deflate only the mechanical portion — the domain logic, admin UI, permissions, and support burden stay in the estimate.

Sequencing caveat. Do not block any roadmap item on this evaluation. It is a sub-day spike with an obvious default answer.

Operational Impact

Maintenance. Zero upstream. The repo is archived; there is no upgrade cadence to track because there will be no upgrades. Anything copied in is self-maintained from minute one. Budget review time once, at the copy-in step, and never again.

Support. Self-supported. No maintainer escalation path, no security disclosure channel, no community, no issue triage. If we vendor code from it, name an internal owner at the moment of adoption or do not adopt.

Scaling. Not a scaling consideration. A skeleton has no runtime footprint beyond the code we write on top of it. If the version guard is real, it is a single assertion at boot — negligible. Performance, queue, and Octane questions belong entirely to our implementation.

Failure modes, ranked by likelihood.

• Inherited obsolescence — the template encodes 2018-era conventions; copying it uncritically spreads outdated patterns into new addons. Highest likelihood, lowest visibility.
• Phantom dependency — adding it to composer.json creates an unmaintained supply-chain entry that scanners flag and that obstructs future framework upgrades. Mitigated by vendoring instead of requiring.
• Misread signal — treating "3.0.2" or the description's feature list as evidence of maturity, or reading a generic build-vs-buy assessment as applicable. This is the failure the earlier assessments committed and the one most likely to recur in a future review.
• Security blind spot — archived code receives no CVE coverage. Low likelihood given the size, but record it if we copy anything touching input, auth, or file handling.
• Joke-dependency ambiguity — a dependency nobody remembers the reason for and everybody is afraid to remove. Avoided entirely by not adding it.

Ramp-up. Minutes for any Laravel developer to read or copy. The genuinely hard organizational work is calibration: ensuring this package is not re-surfaced as a "mature 3.0.x library" on the strength of its version string, and that the description's version-guard claims are not treated as delivered capability. The transferable product lesson is versioning discipline — our own addon releases need descriptive changelogs and a written compatibility policy, because downstream consumers read major/minor/patch as a promise. A release note reading "Stuff." is the exact failure mode this package is mocking; we should not reproduce it in our own artifacts.

Recommendation. Close the adoption question in under an hour. Assign one engineer to read the repo, confirm we are on current first-party scaffolding, and record reference only, not a dependency. Spend the time saved writing the changelog and versioning convention for our own extensions — that is the real deliverable this evaluation surfaces.