Laravel Uninspire Laravel Package

Product Decisions This Supports

• Dependency hygiene / supply-chain surface: this is a micro-utility whose entire job is to remove Laravel's built-in php artisan inspire command (the inspirational-quote command) from the Artisan console. The decision it informs is not "what do we build" but "do we accept one more small third-party package to shape developer-facing ergonomics."
• Developer experience (DX) polish vs. framework defaults: supports a call on whether the team standardises its CLI surface — a clean php artisan list, no novelty commands in demos, screenshots, or customer-facing terminal output, and no confusing entries in onboarding docs.
• Build vs. buy: the functional equivalent is a two-line service-provider override or a Command::forget('inspire')-style call in a local package. This dependency is only justified if you want zero maintenance and versioned upgrades; if you already ship an internal "housekeeping" package, fold it in instead.
• Not a roadmap input: nothing here changes product capabilities, performance, or user-facing behaviour. Treat it as tooling/standards debt, not feature work.

When to Consider This Package

Consider adoption when:

• You run PHP 8.3+ (see breaking change below) and Laravel on the supported version matrix.
• You want the inspire command gone across many applications with a one-line Composer require rather than copy-pasted provider code.
• You value a minimal, single-purpose, easily removable dependency over an internal implementation.
• Your team has a stated convention that default framework novelty commands are removed in production-facing environments.

Look elsewhere / skip it when:

• You are still on PHP 8.2 or earlier — v3.0.0 drops PHP 8.2 support, so you must pin ^2.0 or upgrade PHP first. Do not let a cosmetic package force a runtime upgrade on a service that isn't otherwise ready.
• You already maintain an internal base package or service provider where this belongs; adding a third-party dependency for one forget() call is a net negative on supply-chain review effort.
• Your organisation requires security review, licence attestation, or SBOM entry for every dependency — the review cost will exceed the benefit.
• You need guaranteed long-term maintenance; this is a single-maintainer micro-package with an intentionally tiny scope.

Release note for the record (v3.0.0): the only change is dropping PHP 8.2 support. That is a breaking change by semver, so it should flow through as a major bump in your dependency policy. Concretely: confirm the PHP floor of each app (composer.json require.php, CI matrix, and any Docker base images) before allowing ^3.0; otherwise constrain to ^2.0.1 until the runtime upgrade lands. No new features, no deprecations beyond the PHP floor, no migration steps.

How to Pitch It (Stakeholders)

For executives: This is a small housekeeping package — not a product feature. It removes a novelty command from our developer command line so demos, docs, and screenshots look clean and consistent. Cost is near zero; the only decision is whether we accept one more tiny dependency. The new major version (v3.0.0) simply requires PHP 8.3+, which we should treat as a scheduling input: apps still on 8.2 stay on the previous major version, and nothing breaks either way.

For engineering: Single-purpose package, no runtime footprint, no data or security implications — it only affects the Artisan command registry. v3.0.0 drops PHP 8.2, so bump the constraint to ^3.0 only after the PHP floor and CI matrix are raised; until then pin ^2.0.1. If we'd rather not carry the dependency, the whole behaviour is a forget() call in an existing service provider — flag it in the next dependency review and we'll either adopt at ^3.0 or absorb it into our internal tooling package.