Forte Laravel Package

Technical Evaluation

Architecture fit. Forte sits in the tooling layer, not the application layer. Nothing in a standard Laravel request lifecycle needs to re-parse Blade into an AST — Laravel's own compiler already transforms views to cached PHP at render time. Forte only earns its place where we need to treat Blade source as data: custom static analysis, house lint rules, automated codemods (e.g., bulk-migrating legacy @include partials to components), documentation generation from templates, or a bespoke templating layer on top of Blade syntax. If no such initiative is on the roadmap, architecture fit is low irrespective of package quality. This is an enabler for a specific class of work, not infrastructure.

Integration feasibility. Mechanically trivial: Composer-installable, PSR-4, MIT-licensed, no runtime service dependency. The real feasibility question is grammar coverage, not installation. Blade is a loosely specified superset of HTML + PHP with directives, components, slots, anonymous components, @props, @verbatim, and user-defined custom directives. Any third-party parser is chasing a moving target.

Technical risk.

• Round-trip fidelity. An AST manipulation framework is only useful if it can serialize back to source without corrupting whitespace, attribute quoting, or formatting. This is the classic failure mode for such libraries and is hard to verify without a test corpus.
• Grammar drift. Blade syntax evolves with each Laravel major. A 67-star package will lag. Our Laravel upgrade cadence would become coupled to this package's release cadence.
• Provenance gap. Repository is listed as unknown, which blocks the supply-chain review we'd normally run (CI status, test coverage, contributor spread, security advisories, release signing). This must be closed before any adoption decision.
• Bus factor. Single-maintainer risk is high at this star count.

Key questions for the maintainer / spike.

1. Which Laravel versions' Blade grammar are explicitly supported and tested?
2. Does it handle @verbatim, anonymous components, @props, slot syntax, and custom directives — or only core directives?
3. Is there a printer/serializer, and what round-trip guarantees exist (byte-identical vs. semantically equivalent)?
4. What is the parser's error-recovery behavior on malformed input — throw, or partial AST?
5. Parse throughput on a corpus of ~1–2k views?
6. Is the API stable (semver) or pre-1.0 churn?

Integration Approach

Stack fit. Fits cleanly as a require-dev dependency in a dedicated tooling repository or a tools/ path excluded from production autoloading. It must never enter the request path — the cost of parsing on every render would be a regression against Laravel's compiled-view cache.

Migration path. There is no migration; this is net-new capability. Frame it as: build a thin internal wrapper around Forte's parser so that (a) the rest of our tooling depends on our interface, not Forte's, and (b) swapping parsers later is a contained change.

Compatibility. Pin an exact version. Maintain our own compatibility matrix mapping Forte version → Laravel major → PHP version, and treat a Laravel upgrade as requiring a Forte re-validation gate.

Sequencing.

1. Provenance review — locate the actual repo, confirm license file, CI, and test presence. Gate: pass/fail.
2. One-week spike — run the parser across a representative, deliberately messy sample of our real views (legacy partials, inline PHP, custom directives). Measure parse success rate and round-trip integrity.
3. Go/no-go on the specific use case. Success threshold should be pre-agreed (e.g., ≥98% of corpus parses, zero byte-level corruption on round-trip).
4. Only then build lint rules or codemods on top.

If the spike fails, the fallback is regex/line-based tooling for narrow rules, or forking — which is viable precisely because the package is MIT and small.

Operational Impact

Maintenance. Low if confined to dev tooling; zero production blast radius. But we inherit fork risk: with one effective maintainer and 67 stars, assume we may need to vendor or patch. Budget a small ongoing allowance for that, not zero.

Support. Community-scale only. No vendor SLA, no paid support. Internal expertise must be built — identify one owner who understands the AST API. Expect to self-serve on documentation gaps.

Scaling. Parsing is CPU-bound and roughly linear in view count. Full-corpus runs in CI will add minutes at scale; mitigate with incremental parsing (changed files only) and caching parsed output keyed by file hash. Keep it out of pre-commit hooks if corpus is large.

Failure modes.

• Parse failure on valid Blade → lint false negatives, or CI hard-fails on legitimate templates. Mitigate with a skip-list and a non-blocking reporting mode initially.
• Silent AST mutation corruption → codemods write broken templates. Mitigate with mandatory dry-run diff output and template tests before any write.
• Laravel upgrade drift → parser rejects newly valid syntax across the whole corpus at once. Mitigate by pinning Laravel and Forte together and validating in a branch.
• Abandonment → mitigate via internal wrapper interface and MIT fork option.

Ramp-up. Expect 1–2 days for a competent PHP engineer to become productive with AST traversal; longer if documentation is thin. Plan for a single owner plus a documented internal wrapper so the knowledge doesn't stay siloed.