nodes/core
Core package for the Nodes ecosystem, providing foundational building blocks for node-based content and data structures in Laravel. Ships shared abstractions, base classes, and utilities that other Nodes packages extend, so you can model complex domains on a consistent, extensible foundation.
Before you install anything, read the status line: this package is archived, last released 2020-02-14, with three stars and zero dependents. That does not mean it is broken — it means you are adopting a frozen foundation layer, and you should treat the decision as "vendor a legacy dependency" rather than "add a package."
nodes/core is the bottom of a stack. It exists because the other nodes/* packages declare it as a requirement and assume its plumbing — base service provider, module registration, shared contracts — is present. You will almost never call it directly from application code. You install it because a sibling package needs it, or because you are reviving the Nodes family of packages.
Minimal steps:
composer require nodes/core in a Laravel project whose PHP and framework versions match what the 2020 release supports. Check composer.json for the illuminate/* constraint before you commit; if you are on Laravel 9+, expect a composer update conflict and plan to fork or use --ignore-platform-reqs deliberately, never accidentally.composer.json first, then the package's service provider. In a core/foundation package the provider is the map: it tells you what is registered, what is bound into the container, and what config keys it expects. Read it before the README, because a 2020 README will be stale and the provider will not be.php artisan vendor:publish). That file is the real API surface of a core package — the class names you might extend, the drivers it can resolve, the module paths it scans.First real use case: you are adding one of the sibling Nodes packages, and its provider extends or depends on classes from nodes/core. Get nodes/core booting cleanly on its own first, then add the sibling. Debugging two new packages at once against an archived dependency is how afternoons disappear.
If you are evaluating rather than adopting: clone the repo and diff it against your own framework version's Illuminate\Support\ServiceProvider and container APIs. A core package from 2020 is mostly thin glue, and thin glue is often cheaper to inline into your own app/Providers than to depend on.
Treat it as infrastructure, not as a library. The healthy pattern is: your application code never imports Nodes\Core\* directly. Only your own service providers, module registrars, and config touch it. This keeps the blast radius small when you eventually replace it.
Extend, don't call. Core packages of this shape typically ship abstract base providers or base module classes that siblings extend. If you are writing a new module in the same family, extend the provided base class rather than reimplementing registration — that is the entire reason the package is a hard requirement for its siblings. If you find yourself calling static helpers from it scattered across controllers, you have taken a wrong turn.
Registration order matters. Register nodes/core's provider before any Nodes package that depends on it. In Laravel this usually means it lands early in config/app.php providers (or is auto-discovered and you verify the order with php artisan about / php artisan package:discover -v). If a sibling package throws a "class not found" or "target not instantiable" error during boot, provider ordering is the first hypothesis to test.
Module-style integration. If the package supports scanning a modules directory or a manifest, keep your modules in the location it expects and let its discovery do the work. Fighting the discovery mechanism by manually registering each module's provider defeats the purpose and creates two sources of truth. Where you must deviate (e.g. a package living outside the scanned path), register it explicitly and leave a comment explaining why.
Configuration over code. Anything the core package exposes as config — paths, driver names, class bindings — should be set in config/nodes.php (or whatever it publishes) and committed. Environment-specific values go in .env, but the structural bindings belong in config so they are reviewable in diffs.
Pin and vendor. Given the archive status, pin the exact version in composer.json, commit composer.lock, and seriously consider committing a fork under your own VCS with a replace entry. That is the standard pattern for a frozen dependency you still need: fork it, tag it, point Composer at your fork, and now you can patch a PHP 8 deprecation at 4pm on a Friday without waiting for a maintainer who is not coming back.
Test the seam. Write one integration test that boots the application and asserts the core provider registers and its container bindings resolve. That single test is your early-warning system for framework upgrades — it will fail loudly the moment an illuminate/* change breaks the glue.
Archived means abandoned, and abandoned means the support story is you. MIT license is genuinely permissive — forking is explicitly allowed and is the intended escape hatch. Do not open issues upstream and wait.
Version skew is the primary failure mode. A 2020 core package was written against Laravel 5.x/6.x-era APIs. Signature changes to ServiceProvider, container resolution behavior, and the shift to PHP 8 (deprecations around dynamic properties, ReflectionParameter::getClass(), etc.) are all plausible breakage points. When something fails, check the failing line's framework API against the version in your composer.json before assuming the package is wrong.
Zero dependents is a warning, not a fact. It likely reflects a private or small ecosystem rather than genuine unusability, but it also means there is no community knowledge base — no Stack Overflow answers, no blog posts, no one to ask. Budget for reading the source. Fortunately, "core" packages are usually small; read all of it before you debug any of it.
Auto-discovery can mask ordering bugs. Laravel's package discovery hides provider registration, so a working app can break the instant you switch environments or run a fresh composer install where discovery cache behavior differs. Run php artisan package:discover explicitly after install and inspect what was registered.
Config caching is a classic trap. If you publish the config and then change it, php artisan config:clear before you debug anything. A stale bootstrap/cache/config.php will send you hunting for a bug that is really a cached array.
Don't let it leak into your domain. The most common long-term mistake with foundation packages is letting their base classes become your domain model's parent classes. Wrap their base providers and module classes in your own thin abstractions so that replacing nodes/core in two years is a one-directory change rather than a codebase-wide refactor.
Extension point to prefer: the container. If you need to change behavior the package hardcodes, bind your own implementation over its abstract/interface binding in a provider that runs after it, rather than editing the package in vendor/. This survives composer install and is reviewable.
Watch for replace and provide blocks. Core packages frequently replace older split-out sub-packages. If you have an old nodes/*-core requirement lingering in composer.json, Composer may satisfy it silently through replace, and you will spend time wondering why your new dependency did nothing. Read the full composer.json before you trust composer why.
Final recommendation for a day-to-day assessment: use it only if you are already inside the Nodes ecosystem and need the sibling packages. Otherwise, read its source for the patterns (module registration, base providers) and reimplement the twenty or thirty lines you actually need in your own application. The opportunity cost of adopting an archived, zero-dependent foundation layer is higher than the cost of writing the glue yourself.
How can I help you explore Laravel packages today?