Definitely Not V3 Laravel Package

Getting Started

What you are actually installing. Nothing. Read the source before reaching for Composer. statamic/definitely-not-v3 is a four-file Statamic addon skeleton — a composer.json with PSR-4 autoloading, a service provider, and a joke in the name. It is archived (last release 2018-11-07), has 4 stars and zero dependents, and its 3.0.2 changelog reads, in full, "Stuff." The version number is the punchline, not a compatibility contract.

Where to look first. In the repo, in this order:

1. composer.json — the autoload.psr-4 mapping, the extra.statamic / addon-discovery block, and the declared require constraints. Note the Laravel/Statamic/PHP ranges; they will be 2018-era.
2. The service provider — how it registers, whether it binds anything into the container, what it publishes.
3. Anything else — there almost certainly isn't anything else. That is the point.

If you want a working reference, clone it read-only and keep it out of composer.json:

git clone https://github.com/statamic/definitely-not-v3 /tmp/reference-addon

First use case. Open the current official scaffolding side by side with this repo and diff the shape:

statamic make:addon acme/my-addon
diff -ru /tmp/reference-addon acme/my-addon

The useful artifact is the diff — what the skeleton did in 2018 versus what the framework expects now. That fifteen minutes tells you where addon bootstrapping changed and gives you a template you control. Do not composer require it; a zero-feature archived dependency node is a liability with no offsetting value.

The one thing worth carrying forward is the premise, not the code: downstream consumers read your addon's major/minor/patch numbers and changelog as a promise. A one-word changelog is the failure mode this package is satirizing. Do not reproduce it in your own addon's CHANGELOG.md.

Implementation Patterns

Fork the files, not the dependency. The only defensible day-to-day use is vendoring the structure into your own namespace:

src/
  ServiceProvider.php
  Listeners/
composer.json          # rewrite: name, autoload namespace, constraints

Rewrite name to your vendor namespace, re-point autoload.psr-4, and replace the require block with ranges that match the framework generation you are actually on. Then pin nothing external — you now own the skeleton.

Use it as a teaching reference, not a starting commit. When onboarding a developer to "how does a Statamic addon get loaded," this repo is a two-minute read: PSR-4 map → auto-discovery → service provider boot()/register(). That is the whole mental model, and a four-file repo demonstrates it without the noise of a real addon. Pair it with the current official scaffold so they see the delta.

Pattern: changelog discipline as an actual workflow. If your team ships addons, turn the joke into a convention. Enforce it in CI:

# .github/workflows/changelog.yml (sketch)
- name: Changelog must describe the release
  run: |
    test -s CHANGELOG.md
    ! grep -qiE '^\s*-\s*(stuff|misc|various|fixes)\.?\s*$' CHANGELOG.md

Crude, but it catches the "Stuff." release before a customer reads it.

Pattern: version-drift assertion, done properly. The package's stated (if largely hypothetical) purpose — asserting the app's Statamic version — is a legitimate thing to want, but implement it yourself where you control the failure message:

// in a service provider or a health check
if (version_compare(Statamic::version(), '4.0', '<')) {
    throw new RuntimeException('This addon targets Statamic 4+; found '.Statamic::version());
}

Do this in your own package. Do not delegate it to an archived dependency whose own version number is deliberately meaningless.

Integration tip — if you inherit it. If you find it already in a composer.json (unlikely, zero dependents, but archives get copy-pasted), the removal path is: copy the provider into app/ or an internal package, delete the require line, composer update, and confirm no extra.statamic discovery entry still references the vendor name.

Gotchas and Tips

The version number means nothing. A 3.0.2 tag on an archived joke package is not evidence of semver maturity, and reading it as one is the exact confusion the repo is mocking. If a dependency review flags this as "a stable 3.0.x package," correct the record.

The constraints are stale, so the skeleton may not boot. Anything from 2018 targets the Statamic v2 / Laravel 5.x era. Addon bootstrapping, service-provider conventions, and package layout have moved. Copying the files verbatim into a modern addon will likely fail at discovery or at the require resolution step. Compare against make:addon output first; take the diff, not the files.

Auto-discovery is the silent failure mode. If a copied skeleton does not appear in the control panel, check the extra block in composer.json before you debug PHP. Discovery is name-and-path-based; a renamed namespace with an un-updated extra entry loads nothing and logs nothing useful. composer dump-autoload after any namespace change.

Archived means no security channel. No CVE feed, no disclosure path, no maintainer to ask. The code is four files and touches nothing sensitive, so the practical risk of the skeleton is near zero — but any code you write on top of it gets no upstream review, and scanners will flag the package itself as unmaintained. Vendoring sidesteps the scanner noise entirely.

Do not let it deflate the wrong estimate. The mechanical cost of an addon is indeed near zero — that is what this repo accidentally proves. The estimate that matters is domain logic, admin UI, permissions, migrations, and support burden. Use the skeleton to zero out the boilerplate line item only.

Extension points: there are none. No hooks, no config file, no published assets, no events. "Zero configuration" here means zero surface area. If you need any of that, you are writing it yourself — which is fine, because you were going to anyway.

Disposal plan, written down at adoption time. If you fork it as a template, name an internal owner in the same commit. The real long-term risk is not the code — it is a future engineer finding an unexplained joke-named package in the dependency graph six months later and being afraid to remove it. Record the decision as "reference only, not a dependency" and move on.