Core Laravel Package

Product Decisions This Supports

• Dependency acceptance policy (build vs. buy vs. borrow). joy/core is a useful negative benchmark for a third-party package checklist. At 2 stars, 0 dependents, a single maintainer, and a last release of 2023-09-06, it fails nearly every adoption gate a PM would set (community validation, release cadence, downstream usage, support surface). Use it as the worked example when writing the policy, not as the thing you install.
• Risk register / tech-debt backlog. The only roadmap action this package justifies is an entry in the dependency risk register — and only when it arrives transitively through a joy/* package. Any such package inherits this package's maintenance risk, so vendor/pin/replace decisions cascade.
• Internal platform architecture. The description ("common config/helpers/code to all joy/* packages") is a real, legitimate pattern: a private core foundation package for a family of internal libraries. The takeaway for a PM is the opposite of adoption — if you build this pattern, publish to a private registry with an explicit internal-only marker, versioning contract, and owner, so it never appears on Packagist as a 2-star orphan.
• Ecosystem triage for joy/* proposals. Before backing any feature that depends on a joy/* package, check whether joy/core is in its require block. If it is, the feature's delivery risk is coupled to a stale, single-maintainer dependency.
• Not a feature enabler. There is no user-facing capability here to put on a roadmap. Do not let a "core package" framing create the impression of shared platform value that the adoption data does not support.

When to Consider This Package

Consider it only in three narrow cases:

• You are already inside the joy/* ecosystem and a sibling package declares joy/core as a hard requirement. Then the decision is not "adopt or not" but "vendor, pin, or replace" — treat it as a transitive dependency to be auditied, not a library to be designed around.
• You maintain a package family yourself and want a read-only structural reference for how to factor shared config/helpers out of individual packages. Read the source; do not require it.
• You are evaluating the author's ecosystem and need to understand what joy/* packages assume is present at runtime.

Look elsewhere — and specifically to the Laravel first-party surface — when:

• You need illuminate/support helpers, service-provider wiring, or config merging. Laravel's framework plus spatie/laravel-package-tools covers the standard cases with a maintained release cadence.
• You need any support commitment, semantic-versioning guarantee, security response process, or documentation. None of that is evident at 2 stars / 0 dependents / 18+ months since release.
• You need PHP 8.3+/Laravel 11+ compatibility assurance. A last release of September 2023 predates current framework majors; verify or assume nothing.
• The functionality is genuinely "common config and helpers." Fifteen lines of your own Support/ classes are cheaper to own than an unmaintained dependency — build it.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is not a strategic dependency and it is not on the roadmap. It is an unmaintained internal-plumbing package from a single author with no downstream users. Our exposure is zero today; the value is as a cautionary example that sharpens our third-party dependency policy. No budget, no decision required.

For engineering leads: Do not add joy/core to any composer.json. If it appears transitively through a joy/* package, treat that as a flag on the parent package — pin it, vendor it, or replace the helper/config surface in-house. The package is MIT-licensed, so forking is legally clean if we ever must, but the maintenance burden would be ours. Prefer illuminate/support and first-party helpers for the same functionality.

Framing the value honestly: the deliverable here is a policy artifact — an acceptance checklist for micro-dependencies (stars, dependents, maintainer count, release recency, license, test coverage, supported framework versions) — with joy/core cited as the fail case. That is the PM-leverageable output. Adopting the package is not.