Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Ng Model Generator Bundle Laravel Package

irstea/ng-model-generator-bundle

A Symfony bundle that generates Angular/TypeScript model classes from Doctrine entities, helping keep frontend and backend data structures in sync. Automate model creation for API-driven Angular apps and reduce manual boilerplate.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Frontend/backend contract maintenance (or its elimination). The bundle generates Angular TypeScript models from API Platform resource metadata, so the PHP entity/resource definition becomes the single source of truth. The product decision this informs is whether to keep paying the recurring tax of hand-maintained DTO mirrors — and the defect class that comes with them (a field renamed on the backend, a nullable change, an added enum case, all silently producing undefined at runtime instead of a compile error).
  • Roadmap sequencing for Angular-on-Symfony surfaces. This is only relevant if the near-term roadmap contains an Angular SPA, admin console, or internal data portal sitting on a Symfony + API Platform API — internal dashboards, catalogues, and research-data tools of the kind an institution like IRSTEA/INRAE builds. If Angular isn't on the roadmap, this package should not consume evaluation time.
  • Adopt vs. fork vs. replace. The realistic framing is not build-vs-buy in the procurement sense, because there is no vendor. It is: do we accept permanent internal ownership of a thin codegen utility, or do we standardise on an OpenAPI-driven generator (openapi-typescript, orval, ng-openapi-gen) that is community-maintained and covers clients and validators, not just interfaces.
  • Tooling standardisation across teams. Adopting this bundle makes model generation a Symfony-plugin concern. Adopting an OpenAPI-based generator makes it a CI concern that works regardless of backend framework. That is a platform-strategy decision, not a per-project one, and it should be made once at the org level rather than per squad.
  • Stack-fit flag, material to the shortlist: despite being catalogued here as a Laravel/PHP package, this is a Symfony bundle with an API Platform dependency, not a Laravel package. There is no service provider, no Artisan command, no config publish. If the product is on Laravel, this is inapplicable; if the product is on Laravel and hand-rolled Eloquent resources, the generator has no valid input at all. Remove it from the Laravel shortlist and, if useful, retain it as a reference implementation of the pattern.

When to Consider This Package

Consider it only when all of the following are true:

  • Backend is genuinely Symfony + API Platform, and you can point the generator at resource metadata rather than an exported spec. If your API surface is hand-rolled, the bundle has nothing to consume.
  • Frontend is Angular, and you are currently hand-maintaining model interfaces — i.e. there is a real, quantified cost to replace.
  • Repository access and licensing are confirmed in writing. It is hosted on gitlab.irstea.fr, an institutional forge; verify availability, auth, licence terms permitting fork and internal redistribution, and Composer stability flags before any code depends on it.
  • Blast radius is contained. An internal tool where a bad generated type is caught in code review, not a customer-facing API contract.
  • You have a named internal owner willing to fork on day one. Assume no release cadence, no issue triage, no deprecation policy, one maintainer, French-language code and comments.

Look elsewhere — and this is the default — when:

  • Stack mismatch. For Laravel, use laravel-typescript-transformer or generate from OpenAPI. For non-Angular frontends, the bundle has no value.
  • You want a supported dependency. Zero stars, zero dependents, no Packagist presence, no public tracker. That is not evidence the code is bad; it is the absence of evidence it runs anywhere outside its origin organisation.
  • You need API clients, services, or validators rather than bare interfaces. The bundle's stated scope is models only.
  • You'd rather not couple to API Platform internals. An OpenAPI artifact is a stable, framework-neutral contract; openapi-typescript and orval are maintained and will still be maintained next year.

Default position: fallback first, this bundle as an accelerator. Document the OpenAPI path before committing, so a stalled fork is a swap rather than a rewrite. If you do proceed, timebox it and run a head-to-head on the same resource set — only adopt the bundle if it decisively wins on enums, relations, and nullability.

How to Pitch It (Stakeholders)

Executives. This eliminates a known defect class — Angular TypeScript models drifting out of sync with the backend API — at zero licence cost, on the Symfony + API Platform + Angular corner of the estate. The honest caveat is that it is an unsupported artifact from another institution's self-hosted GitLab forge with no external adopters, so the real cost is not a purchase price but a few days of integration plus permanent internal ownership with a named engineer attached. Frame it as "adopt with an owner and an exit plan," never as a vendor dependency. Recommendation: a timeboxed pilot on one internal module, with the OpenAPI-based alternative written down first as the fallback, and a decision gate at the end of the pilot. Do not put it on customer-facing contracts.

Engineering. The bundle reads API Platform resource metadata and emits Angular TypeScript models, replacing manual DTO mirroring. Be explicit about what is missing: it is a Symfony bundle, not a Laravel package, so composer require into a Laravel app installs code that never boots; there is no service provider and no Artisan command. Even in a Symfony host, plan for a fork — pin to a commit SHA, confirm the licence, verify PHP/Symfony/Angular version constraints empirically, and run generated output through lint and Angular strict mode. Wire generation into CI with a drift check (regenerate, git diff --exit-code) so metadata changes surface as reviewable diffs rather than silent divergence. Understand the failure modes before relying on it: skipped resources with no error surface, nullability and enum drift, and silent staleness after serializer-group changes where TypeScript still compiles. If the models must be trustworthy in a customer-facing contract, generate from OpenAPI with a maintained tool and treat this bundle as a stopgap or a reference implementation of the mapping logic, not a dependency.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource