Core Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for shared internal foundations. nodes/core is the canonical example of a "shared core" package — the mandatory base layer every sibling package in the Nodes suite depends on. Its shape (contracts, base service providers, common utilities) is a useful reference when deciding whether your own Laravel package suite needs a mandatory base layer or should rely on framework primitives instead.
• Vendor and maintenance risk on the dependency graph. Last release 2020-02-14, archived repository, 3 stars, zero tracked dependents. Any decision to depend on this is effectively a decision to own it. The PM output here is a "do not adopt for new work" ruling plus an exit-plan item for anyone already on it.
• Roadmap sequencing for legacy maintenance. If a product is running on the Nodes suite, decoupling from nodes/core becomes a planned engineering line item (estimate, risk, freeze on new feature work in affected modules), not an ad-hoc cleanup.
• Fork licensing and IP position. MIT license means forking and vendoring is legally clean. The decision is whether to fork-and-maintain, fork-and-replace, or delete — not whether we're permitted to.
• Scope discipline for platform teams. The package is a coupling point: adopting it means adopting the whole archived Nodes ecosystem. It informs the architectural principle that a mandatory core package must ship with a documented exit path and a deprecation policy.

When to Consider This Package

Consider it only when:

• An existing Laravel application already depends on nodes/core transitively, and you need to understand or patch the base layer during an incident.
• You are designing your own internal "core" package for a Laravel package suite and want a concrete, permissively licensed reference implementation of contracts and base service providers.
• You need to fork it for internal maintenance and can assign an owner with a funded maintenance budget.

Look elsewhere when:

• The project is greenfield. There is no maintained release line, no PHP 8+ / current Laravel support commitment, and no security response process.
• You need support SLAs, coordinated security patching, or upstream contributions accepted.
• The actual goal is common utilities or package scaffolding — use actively maintained equivalents (illuminate/support, spatie/laravel-package-tools, orchestra/testbench) instead.
• Your dependency policy requires a maintained release cadence or health signal; a 2020 archive date with zero dependents fails any reasonable threshold.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed foundation library from an abandoned package family — archived in 2020, no support, no security patching, no other consumers we can identify. It costs nothing to use and nothing to leave. We are not adopting it for new products; it is a liability only in that anything already built on it is now unmaintained, and we should budget a short decoupling effort to remove that exposure.

For engineering: Treat nodes/core as a readable architecture reference, not a dependency. It defines the mandatory base layer for the Nodes package suite and is a clean example of contracts-plus-service-provider scaffolding for Laravel packages. Do not pull it into new code. If we inherit a codebase that depends on it, the work is to identify the coupling surface, replace base classes with framework or maintained equivalents, and pin the removal in the plan. The one genuinely valuable thing here is the pattern, not the code — and if we build our own core layer, it ships with an owner, a support window, and a documented migration path so we don't recreate this exact situation.