- What is nunomaduro/yorn and what does it do?
- Yorn is a small, focused package from Nuno Maduro that adds JavaScript-style import and export syntax to PHP, so files can declare explicit module contracts instead of relying on namespaces and PSR-4 conventions. It works by changing the language surface through a custom runtime layer rather than changing your application architecture. It is best understood as a working demo of what stricter module boundaries could feel like, not as a Laravel module system or a Composer replacement.
- How do I install nunomaduro/yorn in a Laravel application?
- You can pull it in with Composer, but it is not a composer require and go package. A working demo requires compiling or building a nonstandard PHP runtime or loader inside a container before you can prove the rest of your toolchain still works. Treat installation as a sandbox spike, pin your PHP, Composer, Laravel, and Yorn versions explicitly, and confirm that Composer autoloading, PHPUnit, and your CI images survive the change.
- Does Yorn replace Composer autoloading or give Laravel a native module system?
- No. Yorn does not replace Composer autoloading, service providers, the container, package discovery, config, routes, or migrations, and it does not provide a Laravel-native module system. It only changes how files declare their imports and exports at the language level. If you need enforced module boundaries inside a Laravel monolith, architecture tests and static-analysis rules are the lower-risk option.
- Which PHP and Laravel versions does Yorn support?
- The package's shipped documentation is unreliable, so the supported PHP version matrix should be verified directly in the source and test suite rather than trusted from the README. Pin PHP, Composer, Laravel, and Yorn versions explicitly in any evaluation and confirm behavior on the exact versions you run in production. Do not assume an upgrade policy exists until you find evidence of one.
- Will Yorn break PHPUnit, PHPStan, Pint, or IDE navigation?
- That is exactly the question to test, because source transformation tends to blind static analysis and confuse IDE navigation. Validate Composer, Laravel's autoloader, PHPUnit, PHPStan or Psalm, Pint, your editor, Docker and CI images, opcache and preloading, and deployment artifacts before drawing any conclusion. The real feasibility question is not whether the demo runs, but what breaks around it.
- Is Yorn production-ready for a Laravel application?
- The honest assessment is low fit as a production dependency and moderate fit as a sandbox spike. Adoption signal is effectively zero, with no dependents and very few stars, so there is no downstream field validation or bug-fixing pressure from other consumers. If you use it at all, confine it behind a build step for bounded, non-critical modules and keep application code, service providers, Eloquent models, config, and package discovery as vanilla, upgradeable PHP.
- How does Yorn affect debugging, stack traces, and __FILE__ or __DIR__?
- Because Yorn transforms source, stack traces and __FILE__ or __DIR__ may point at transformed output rather than the file you actually wrote, which complicates debugging and reproducibility. Builds also risk becoming non-deterministic. Before committing to anything, ask whether there is a cache, source map, or debug story, and test a real failure scenario to see what the developer experience looks like.
- Is Yorn compiled ahead of time or parsed at runtime?
- A working demo requires compiling or building a nonstandard PHP runtime or loader, and whether that happens ahead of time as a build artifact or per request at runtime is a critical distinction you must confirm yourself. Runtime parsing raises performance and reproducibility concerns, while ahead-of-time compilation raises questions about deployment artifacts and cache invalidation. The documentation does not reliably answer this, so verify it in the source.
- Can I confine Yorn to one module or subtree of an existing Laravel app?
- That is the right instinct, but the package does not document a supported way to confine itself to a subtree, so you would have to prove it yourself in a spike. The realistic approach is a side-by-side comparison: implement the same small module once with PSR-4 and namespaces and once with Yorn's import and export syntax, then measure what you actually gained in readability, onboarding time, or refactor safety. If the gain is not measurable, skip it.
- What are the alternatives to Yorn for stricter module boundaries in Laravel?
- The pragmatic alternative is userland boundary enforcement: architecture tests plus static-analysis rules such as PHPStan or Psalm boundary checks, at a fraction of the risk. That approach keeps Composer, PSR-4, the container, and your entire toolchain untouched while still catching cross-module coupling in CI. Yorn is useful as evidence in that architecture decision, but it should inform the decision rather than become a build dependency.