Typescript Generator Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for the API contract layer. This bundle sits in the "generate TypeScript from a Symfony codebase" category — the decision it informs is whether our team hand-maintains TS types, adopts a generator, or standardizes on an OpenAPI-first pipeline. It's a data point in that comparison, not the answer.
• Front-end/back-end drift reduction. If we're Symfony + TypeScript, the recurring cost is manual re-sync of interfaces after PHP DTO/entity changes. A generator removes a class of "works in PHP, breaks in TS at runtime" bugs, which is a quality/velocity lever PMs can actually trade against sprint capacity.
• Tooling investment sizing. The package is archived, has 0 stars and 0 dependents. That makes the real product decision "do we adopt, fork, or reimplement?" — and it tells us the maintenance cost is ours, not a vendor's, which changes the TCO model entirely.
• Licensing/roadmap constraint check. EUPL-1.1 is a copyleft license. For internal tooling it's usually fine; if any generated code or the bundle itself ships in a distributed product, legal review becomes a gating decision before any engineering time is spent.
• Spike scoping. It's a cheap reference implementation to read for a 1–2 day spike, even if we never install it. That's a legitimate PM-approved use of time when the alternative is a multi-week evaluation of a commercial schema pipeline.

When to Consider This Package

Adopt or evaluate it when all of the following hold:

• The stack is genuinely Symfony (backend) + TypeScript (frontend), with a DTO/entity-heavy API surface where hand-written types are already a known pain point.
• The team is willing to own the code — fork it, vendor it, pin it. Archived means no security patches, no PHP/Laravel-Symfony version bumps, no issue triage.
• The blast radius is internal tooling or a non-critical internal app, not a customer-facing contract that needs support SLAs.
• EUPL-1.1 has been cleared for our distribution model.
• We've timeboxed it as a spike with a written exit criterion ("if it can't cover enums + nullable relations + route params in 2 days, we stop").

Look elsewhere when:

• Maintenance matters. 0 stars, 0 dependents, archived, no maintainer — there is no community to absorb breakage. Prefer actively maintained equivalents: an OpenAPI-first path (nelmio/api-doc or API Platform → openapi-typescript), Symfony's native type-info tooling, or a schema-first approach with Zod/Valibot.
• The project isn't Symfony-shaped, or the frontend is small enough that a single hand-written types.ts is cheaper than any generator.
• We need first-class support for framework upgrades (Symfony 7/8, PHP 8.3+) and can't budget the fork time.
• Compliance/security review requires a maintained dependency with a CVE response process.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a small open-source Symfony bundle that auto-generates TypeScript types from our backend, which would remove a recurring source of front-end breakage and manual rework. The catch is that it's archived with no community, so the realistic proposal is not "add a dependency" — it's a short, timeboxed spike to see whether the approach is worth adopting, either by forking this code or by buying into a maintained OpenAPI-based pipeline. Cost is a few engineering days; the decision it unlocks is whether to fund contract automation on the roadmap.

To engineering: Treat vinatis/typescript-generator as a reference implementation first and a dependency second. It's a Symfony bundle that emits TypeScript from the Symfony project, which is exactly the seam we keep patching by hand. Because it's archived with zero dependents, anything we adopt we own: fork it, pin it, and add it to the upgrade checklist. Recommended next step is a two-day spike against our three messiest DTOs, benchmarked head-to-head against an OpenAPI → openapi-typescript path, with a clear "stop if it doesn't handle enums, nullables, and route params" gate. If it wins, we fork; if it loses, we've still learned what our contract layer needs.