- Can I use janit/typescript-generator-bundle in a Laravel application?
- Not directly. It is a Symfony bundle that registers into a Symfony kernel, wires through Symfony dependency injection, and exposes its logic as a tagged Symfony console command, so composer require will not give you a usable php artisan command. The realistic paths are to fork the generator service and re-register it behind one Artisan command, or to depend on a standalone framework-free core library if the bundle wraps one. Resolve which of those is true before committing, because the effort differs by an order of magnitude.
- How do I install and configure it in a Symfony project?
- You install it with Composer, enable the bundle in your Symfony bundle registration, and configure source paths and the output directory in your bundle config. Generation then runs as a Symfony console command during your build or asset pipeline. Laravel has no bundle mechanism or equivalent auto-registration, so that setup does not translate.
- Will it generate TypeScript from my Laravel DTOs, FormRequests, and API Resources?
- The underlying technique, reflecting over PHP classes and emitting TypeScript interfaces, applies to any PHP class including Laravel DTOs and request/response models. What does not transfer is the Symfony-shaped plumbing: configurable source paths assume a conventional Symfony src layout, and the command wiring is Symfony-specific. A short spike pointing the generator at a handful of representative Laravel classes will tell you whether the output quality is acceptable.
- Which PHP versions and type constructs does it support, such as enums, readonly properties, and union types?
- The provided context does not confirm test coverage for these constructs. That matters because the reflection surface moves with every PHP minor release, and an unmaintained reflector can silently emit incomplete TypeScript that still type-checks and looks plausible. Verify enum, readonly, promoted constructor parameter, union, and intersection handling with your own classes before relying on it.
- Is the generated TypeScript output deterministic and diffable enough to run in CI?
- That is unconfirmed and should be one of your first checks. Stable ordering and consistent formatting determine whether generated .ts files can be committed or published as a build artifact without constant churn. If output ordering is unstable, every CI run produces noisy diffs and the tool becomes a maintenance burden rather than a safeguard.
- How do I run type generation in a CI pipeline or asset build?
- In Symfony the generator is already a console command, so you can call it from CI or an asset pipeline step. In Laravel you would wrap the extracted generator in a single Artisan command, for example php artisan types:generate, and invoke that from your pipeline. Keep it as one command with configuration in a config file so CI and local runs behave identically.
- What are the alternatives for keeping Laravel models and TypeScript types in sync?
- You can generate an OpenAPI or JSON Schema document from Laravel with tools such as Scribe or Scramble and feed it to openapi-typescript, which is framework-agnostic and widely used. You can also extract or fork a PHP-to-TypeScript reflector like this one into app/Support and own it. Hand-written interfaces are the fallback, but they reintroduce the drift you are trying to eliminate.
- Is janit/typescript-generator-bundle actively maintained and safe for production?
- Signals are weak: around 16 stars, zero dependents, a composite score near 0.43, no observable production usage, and a bus factor of one. A single maintainer with no downstream consumers means no implicit regression testing and little pressure to track PHP or Symfony releases. The MIT license is the main mitigant, because forking is legally unencumbered and the abandonment scenario is survivable.
- Can I target specific namespaces or exclude certain classes from generation?
- The overview mentions configurable source paths but does not document namespace targeting or exclusions. The bundle likely assumes a conventional Symfony src layout, so confirm exclusion support before relying on it for a mixed codebase. If exclusions are missing, plan to filter classes in your own wrapper rather than patching the bundle.
- Should I commit the generated .ts files to my frontend repository or publish them as a build artifact?
- Either approach works if the output is deterministic, and you should test that before deciding. Committing generated files makes drift visible in review but adds churn if ordering or formatting is unstable. Publishing as a build artifact keeps the frontend repo clean but requires a reliable CI step and versioning discipline, which means more glue code you own in Laravel.