Laravel Source Generator Laravel Package

Technical Evaluation

Architecture fit. jumilla/laravel-source-generator is a fluent, method-chained PHP source code emitter — it builds class/interface/trait source strings programmatically rather than parsing or reflecting existing code. In a Laravel codebase this positions it as a build-time scaffolding primitive, not a runtime library: it belongs in the same conceptual slot as custom artisan make:* stubs, nette/php-generator, or hand-rolled template strings. It is therefore a poor fit for anything on the request path, and a plausible fit for internal developer tooling (module generators, CRUD scaffolders, domain-class bootstrappers, migration/seed emitters). Any architectural decision should be framed as "do we adopt a code-generation layer at all," not "do we adopt this package."

Integration feasibility. Mechanically trivial: MIT license, Composer-installable, no native extensions, no external services. The realistic path is composer require --dev, a service provider (or plain instantiation), and a thin internal wrapper. The blocker is not effort — it is provenance.

Technical risk — high, and concentrated in three places:

1. Archived upstream. No security patches, no PHP/Laravel compatibility updates, no bug fixes. Every future upgrade of our runtime becomes our problem, not theirs.
2. Zero dependents, 1 star. There is no evidence of production use anywhere. We would be the first meaningful consumer, which means we absorb all the latent defects. No Stack Overflow corpus, no issue history to mine.
3. Abandoned-package signalling. Packagist marks archived packages as abandoned; composer audit, Dependabot, and most enterprise SCA gates surface this. A dev-only dependency can still fail a CI security gate or a procurement review, which converts a technical choice into a process fight.

Offsetting factor: because it is MIT and small, vendoring or forking is genuinely cheap. The correct risk posture is "we may consume the ideas, but we should not consume the supply chain."

Key questions for the maintainer/spike:

• What PHP and Laravel versions are supported, and does it emit PHP 8.2+/8.3-valid syntax (typed properties, enums, readonly, constructor promotion, attributes)?
• Is output PSR-12/PSR-4 conformant, and is it deterministic (stable ordering, no timestamps) so generated files don't churn in diffs?
• How does it handle target-file collisions — overwrite, skip, abort, or merge?
• Does it have a test suite, and how much of the fluent surface does that suite actually cover? (This determines fork viability.)
• Is the fluent API complete enough for our templates, or will we be extending the builder immediately — and if so, we are forking on day one.
• What is the last commit date, and is there a successor package or upstream author intent?

Recommendation to the decision forum: treat as do-not-adopt-as-a-dependency, and evaluate as vendor/fork candidate or reference implementation. Run a one-week timeboxed spike; if the spike shows the API surface is thin relative to nette/php-generator (which is maintained and widely depended upon), close the evaluation and standardize on the alternative.

Integration Approach

Stack fit. PHP/Laravel, dev-dependency only. It should never land in require (production) — generated source is the artifact, the generator is not. Enforce this with a Composer constraint and a CI check that the package is absent from the production lockfile. If any code path would need it at runtime, that is a design smell and the requirement should be rejected.

Migration path. There is nothing to migrate from — this is greenfield. The migration that matters is the reverse: off this package if it is ever adopted. Design for that on day one by hiding it behind an internal interface:

• App\Generators\SourceBuilder (interface) with methods we actually need: class(), method(), property(), use(), namespace().
• JumillaSourceBuilder implements it in the spike.
• NetteSourceBuilder and StubSourceBuilder are drop-in alternates.

Because the package is archived, budget the fork on adoption, not "if needed." A vendor fork pinned in composer.json via a VCS repository, with our own phpunit suite asserting on generated output strings, is the only version of adoption that survives contact with a Laravel major upgrade.

Compatibility. Unverified and the single largest unknown. Concretely: confirm it installs cleanly on our current PHP/Laravel matrix, and — more importantly — confirm it does not install on the next one, so we know the clock is already running. Check for Laravel-version-coupled dependencies (a service provider binding to container internals is the usual rot point). If the package pins illuminate/* broadly, it may install but emit invalid code; if it pins tightly, it will refuse to install and force the fork decision early. Either is acceptable — silence is the bad outcome.

Sequencing.

1. Week 1 — sandbox spike. Separate repo, current Laravel version, generate three representative artifacts: a domain model with properties and one relation, a form request with rules, and a service class with a constructor. Commit generated output and diff against what we'd write by hand.
2. Week 1 — parallel bake-off. Same three artifacts via nette/php-generator and via Laravel's native custom stubs (artisan stub:publish + make:*). Score on output fidelity, API ergonomics, and lines of glue code.
3. Week 2 — provenance check. Run composer audit and our SCA scanner against the install; confirm whether "abandoned" trips a gate. This is a go/no-go independent of code quality.
4. Week 2 — fork feasibility. Assess the source size, license headers, and test coverage. If the builder is under a few thousand lines and the test suite is meaningful, a fork is a bounded task; if not, discard.
5. Week 3 — decide and wrap. Whichever backend wins, ship it behind SourceBuilder with golden-file tests. Adopt into one generator command only, as a canary, before broad use.
6. Deferred. Do not integrate into CI codegen or any pipeline that runs unattended until the canary has produced a few hundred files without a malformed-output incident.

Operational Impact

Maintenance. This is the dominant cost and it is entirely ours. An archived package has no upstream to absorb PHP deprecations, Laravel major-version breaks, or security reports. If we fork, we own a permanent, if small, maintenance line item: a quarterly "does this still emit valid PHP on the current runtime" review, plus ownership in the package manifest. If we adopt without forking, we own an unbounded upgrade risk with zero leverage. Assign a named owner before adoption; the most likely failure is not a bug, it is orphaning — nobody notices the generator is broken until a new hire runs make:module and gets a fatal.

Support. None. No maintainer response, no issue tracker triage, no security advisories. Internal support burden falls on the platform team. The practical mitigation is documentation of the wrapper interface plus a golden-file test suite, so that a future owner can swap the backend without reverse-engineering intent.

Scaling. Low risk by construction. Generation runs on developer laptops and, at most, in CI — throughput is irrelevant at any realistic file count. The scaling concern is not performance but blast radius: a generator change propagates to every generated file in the codebase. Mitigations are determinism (stable output ordering so regenerating produces no diff), a golden-file suite that fails on unintended output drift, and a policy that regenerated files are reviewed like hand-written code. Do not build a "regenerate everything" CI job on top of an unmaintained emitter.

Failure modes. Ranked by likelihood × impact:

• Silent malformed output (highest risk). Emits PHP that parses but is subtly wrong, or that fails php -l only on the next runtime version. Detected late, produces confusing failures downstream. Mitigate with a php -l (or pint --test) gate on every generated file in the generator's own test suite.
• Collision/overwrite. A regeneration silently clobbers a hand-edited file. Must be resolved by policy: generators write only to fresh paths, or refuse to overwrite without an explicit flag. Verify the package's behavior here before adoption — this is a data-loss class of bug.
• Supply-chain gate failure. "Abandoned" flagged by SCA blocks a release at the worst possible moment. Cheap to pre-check, expensive to discover during a release freeze.
• Version-lock cliff. Package refuses to install after a Laravel/PHP upgrade, blocking the upgrade itself. Mitigated by the wrapper interface and by never letting generated-code tooling gate runtime upgrades.
• Orphaning. Owner leaves; the generator rots; teams quietly revert to copy-paste. Mitigated by the golden-file suite and a manifest owner.

Ramp-up. The fluent method-chain API is approachable — a mid-level PHP developer reads the source in under a day, and the concept (build a class by chaining calls) transfers immediately from any template-engine experience. Expect ~1 day to first useful output, ~1 week to a production-grade generator command with tests. The hidden cost is that with no documentation and no community examples, all learning is from source, and any non-obvious behavior is tribal knowledge. Budget for writing the internal README as part of the spike, not after.

Net TPM position. Score and signals (1 star, 0 dependents, archived, 0.0025) align with the code-level assessment: this is a reference implementation, not a dependency. The idea — fluent, chainable source generation hidden behind an internal builder interface — is worth adopting. The package is not. Close the evaluation with a recommendation to standardize on nette/php-generator behind our own SourceBuilder abstraction, and keep this repo as a design reference only.