Foundation Laravel Package

Getting Started

What you're actually installing. netflex/foundation is a read-only subtree split of a directory inside the larger netflex/framework monorepo (likely src/Foundation). It exists so Composer can resolve that slice independently — it is not the primary distribution channel, and it is not maintained here. Treat the GitHub repo as a mirror: no PRs, no issues, no changelog of its own.

Minimal steps:

1. Don't require it directly unless you have a reason. In a normal Netflex application you get this transitively via netflex/framework. Check with:

   composer why netflex/foundation
   

   If it shows up as a dependency of netflex/framework, you're already using it — you just call into it through the framework.

2. Read composer.json first, not the README. It tells you the PHP constraint, the PSR-4 namespace (expect Netflex\Foundation\), and the exact netflex/framework version it was split from. That version pairing is the contract.

3. Then read netflex/framework. Since this is a split, all history, docs, and discussion live in the parent repo. Search there for the class names you find in vendor/netflex/foundation/src/.

4. First use case: extending a base class. Foundation components are typically the abstract/base layer — entities, structures, exceptions, helpers — that the rest of the framework builds on. Your first real interaction is usually class Foo extends Netflex\Foundation\... rather than instantiating anything directly.

Implementation Patterns

Extend, don't edit. Because this is a generated split, any change you make under vendor/ is lost on the next composer update and can never be upstreamed to this repo. Subclass the foundation types in your own namespace and register the binding or alias in your service provider.

Treat it as the contract layer, framework as the implementation. A useful mental model day-to-day:

• netflex/foundation → base classes, interfaces, exceptions, generic helpers.
• netflex/framework → concrete application wiring, providers, config, runtime.

When you're debugging behavior, the stack trace may land in foundation, but the decision that caused it usually lives in framework. Follow the trace up one level before assuming the bug is in foundation.

Version-lock the pair. If you ever do pin foundation explicitly, pin it to the same release line as netflex/framework. The split is tagged in lockstep with the monorepo; mixing a foundation from one minor with a framework from another is the most common way to get confusing autoload or signature errors.

Integration tips for a Netflex/Laravel-style app:

• Check whether foundation ships a service provider and whether it needs registration in config/app.php or is already pulled in by the framework's provider list.
• Look for a config/ directory and publishes() calls — if config is published, publish it once and commit it; don't rely on package defaults in production.
• Use the container to swap foundation implementations rather than conditionals scattered through application code: bind your subclass to the foundation interface/abstract in a provider.

Testing pattern. Foundation base classes are usually abstract or thin, so test your subclass, not the base. If you need to assert interaction with foundation types, create concrete test doubles that extend them — that keeps you honest about the abstract API surface you actually depend on.

Gotchas and Tips

• The "READ ONLY" banner is the single most important fact. Issues opened here go nowhere. Fork netflex/framework, patch there, and consume via a VCS repository entry or a path repository if you need a temporary fix.
• Zero stars and zero dependents is a signal, not a bug. There is effectively no external validation, no Stack Overflow corpus, and no third-party blog coverage. Budget time for reading source. Pin exact versions ("netflex/foundation": "1.2.3") rather than floating ranges in anything you care about.
• Subtree splits silently drift. If composer why shows two different constraints on foundation in your dependency graph, resolve them before debugging anything else — otherwise you'll be reading source for a version that isn't loaded.
• Debugging by class name is faster than by trace. Because both packages share a namespace root, grep -rn "class YourBaseClass" vendor/netflex/ tells you instantly which package owns the code you're stepping through.
• Check autoload.psr-4 before assuming a namespace. Split repositories occasionally carry slightly different mapping than the monorepo source, and the resulting "class not found" is maddening to chase.
• Extension points to look for: abstract methods on base classes, protected config arrays, container bindings, and any Macroable/__call traits. Those are the sanctioned customization seams; anything else is fragile.
• Don't add it as a direct dependency "for clarity." An unnecessary top-level constraint is one more thing that can conflict during upgrades and one more place the lockstep version pairing can break. Let netflex/framework own it.