Yorn Laravel Package

Technical Evaluation

• Architecture fit: Yorn changes the language surface, not the application architecture. It adds JavaScript-style import/export to PHP via a custom runtime layer so files can declare explicit module contracts instead of relying on namespace + PSR-4 conventions. For a Laravel estate the honest fit is narrow: it does not replace Composer autoloading, service providers, the container, package discovery, config, routes, or migrations, and it does not give you a Laravel-native module system. The realistic TPM framing is architecture-decision input, not a build dependency: it is a concrete, working demo of what stricter module boundaries could feel like, useful when arguing for (or against) investment in architecture tests, static-analysis boundary rules, or a modular monolith refactor.
• Integration feasibility: Low as a production dependency, moderate as a sandbox spike. It is not composer require and go — a working demo requires compiling/building a nonstandard PHP runtime or loader in a container, then proving the rest of the toolchain survives. The feasibility question a TPM must force is not "does the demo run?" but "what breaks around it?" Validate Composer, Laravel's autoloader, PHPUnit, PHPStan/Psalm, Pint, IDE navigation, Docker/CI images, opcache/preloading, and deployment artifacts before drawing any conclusion.
• Technical risk: High on every axis that matters for a platform bet. Adoption signal is effectively zero (0 dependents; 144 stars; composite score ~1.3), meaning there is no downstream field validation and no bug-fixing pressure from other consumers. Runtime/source-transformation semantics introduce debugging and reproducibility concerns: stack traces and __FILE__/__DIR__ may point at transformed output, static analysis goes blind, and builds risk becoming non-deterministic. Mitigating factors: MIT license is permissive and the maintainer (Nuno Maduro) is highly credible, so the directional signal is worth more than the package itself.
• Documentation red flag: The shipped description.md describes a Symfony Console CLI framework ("define commands, arguments and options without boilerplate"), which directly contradicts the package's stated purpose (import/export modules). A TPM should read this as a doc-maturity and maintenance-attention signal — if the front-page description does not describe the product, assume the README, version support matrix, and upgrade notes are also unreliable, and treat tests/ and source as the only source of truth.
• Key questions: Which PHP versions are supported, and what is the upgrade policy? Is compilation ahead-of-time (build artifact) or runtime (per-request parse)? Is there a cache, source map, or debug story? Does it interoperate with PSR-4 and Composer, and can it be confined to a subtree? What is the maintainer's roadmap and bus factor? What is the rollback/exit path if upstream stalls? And critically: what decision will this inform, and what evidence would change our mind?

Integration Approach

• Stack fit: Position Yorn as an R&D artifact and authoring experiment for new, bounded, non-critical modules — never as core Laravel infrastructure. If used at all, confine it behind a build step so application code, service providers, Eloquent models, config, and package discovery remain vanilla, upgradeable PHP.
• Migration path: There is no migration path; there is only an evaluation path. Do not rewrite existing code, shared packages, or anything with multiple consumers. Run a side-by-side comparison: the same small module implemented (a) with PSR-4 + namespaces and (b) with Yorn's import/export, then measure what you actually gained in readability, onboarding time, or refactor safety. If the gain is not measurable, the answer is "userland boundary enforcement" — architecture tests and static-analysis rules — at a fraction of the risk.
• Compatibility: Pin PHP, Composer, Laravel, and Yorn versions explicitly in the spike. Prefer any ahead-of-time compilation mode so production-shaped environments never depend on runtime transformation. Explicitly test CI/CD, Docker builds, opcache/preloading, PHPUnit, and IDE behavior; document each breakage as a cost line rather than working around it silently.
• Sequencing: (1) 1–2 day sandboxed spike in an isolated container, with a written hypothesis and time box; (2) capture findings — DX delta, tooling breakage list, migration cost estimate, performance overhead; (3) present as input to the module-boundary / architecture-tooling decision alongside the userland alternative; (4) default to userland enforcement for anything shipping; (5) re-evaluate only if PHP core or a major framework moves in this direction. Gate any second phase on maintainer responsiveness and released evidence, not on demo enthusiasm.

Operational Impact

• Maintenance: Any adoption adds a compiler/loader and generated-artifact workflow to your ownership surface, plus a permanent pinning-and-upgrade burden tied to PHP releases. With zero dependents you will be the only organization exercising your code path; expertise will be internal-only and concentrated in one or two people. Assign a named owner and a version-pinning policy before writing a single line, and define who deletes the spike when it is done.
• Support: No vendor-grade support, thin community, escalation depends entirely on one maintainer's goodwill. A TPM should not plan a roadmap around a package where the support model is "open an issue and hope."
• Scaling: Build-time transformation can scale if cached and deterministic; runtime transformation on hot paths is a latency and opcache hazard and should be treated as disqualifying for request-serving code. Team scaling is the harder constraint: every new hire pays a permanent tax learning nonstandard syntax with no IDE support, and tooling that normally catches mistakes (PHPStan, Psalm, IDE refactors) silently stops working for those files.
• Failure modes: Broken transformation in CI, stale generated artifacts shipping to production, debugger/source mismatch during incidents, static-analysis blind spots letting real bugs through, PHP/Laravel upgrade breakage, upstream abandonment, and syntax lock-in that makes the code unreadable to standard tooling. Mitigations are golden tests, generated-code checksums, pinned versions, and a written exit plan — but note that these mitigations cost more than the problem Yorn is meant to solve.
• Ramp-up: Moderate-to-high for a Laravel team if the syntax is exposed to developers; near-zero if fully isolated behind a build step nobody touches. Recommendation: do not adopt. Fund a short, bounded spike only to generate evidence for the module-boundary decision, publish the findings, and retire it. Low cost, low commitment, asymmetric upside — the only real risk is scope creep if someone mistakes the demo for a roadmap. Make that boundary explicit in writing up front.