Product Decisions This Supports
- Frontend/backend contract consistency: Laravel’s morph map lets polymorphic relationships store stable aliases instead of PHP class names. This package exposes that map to JavaScript, reducing the risk of frontend code hard-coding aliases or drifting from backend definitions.
- Feature delivery for polymorphic API resources: Useful when shipping features backed by polymorphic relations — comments, activity feeds, notifications, media attachments, audit logs, or any
*_type / *_id payload consumed by a JS/TS client.
- Build vs. buy: The package is a narrow code-generation utility. Adoption is reasonable when the team wants a maintained, convention-based generator instead of writing and owning a custom Artisan command.
- CI and release workflow decisions: Supports adding morph-map generation to the frontend build or release pipeline so generated JS is refreshed whenever backend morph aliases change.
- Roadmap and API evolution: Encourages treating morph aliases as part of the public API contract. Alias changes should be reviewed like schema or enum changes because frontend behavior depends on them.
- v1.2.2 release decision: The default morph-map command now emits plain JavaScript. This is a bug fix, not a new feature or declared breaking change, but teams should regenerate committed output and verify the artifact in CI because the default command’s output format has changed.
When to Consider This Package
Consider adoption when:
- The Laravel application uses
Relation::morphMap() or equivalent polymorphic alias configuration.
- A JavaScript or TypeScript frontend consumes API payloads containing polymorphic type fields.
- The frontend needs a generated alias-to-type mapping, display metadata, or a shared source of truth for polymorphic resources.
- The team can run an Artisan command during build, deployment, or code generation.
- The team wants a small, focused dependency rather than a broader API schema/codegen platform.
Look elsewhere or build internally when:
- The application does not use Laravel morph maps or does not expose polymorphic relationships to a JS client.
- The frontend can consume a runtime API endpoint for morph-map metadata instead of a generated asset.
- The organisation already standardises on OpenAPI, JSON Schema, GraphQL codegen, or a broader TypeScript type-generation pipeline.
- The generated JavaScript must support advanced customisation, multiple output formats, or complex transformation rules beyond the package’s scope.
- The package’s maintenance cadence, Laravel version support, or security posture does not meet procurement requirements.
For v1.2.2 specifically, verify that the generated plain JavaScript output matches the frontend’s expected module format and that any committed generated files are refreshed. Since this is a patch-level bug fix, adoption risk appears low, but the output change should still be validated in a staging build.
How to Pitch It (Stakeholders)
For executives: This is a small, low-risk utility that keeps frontend and backend aligned when APIs return polymorphic data. It reduces a class of integration bugs caused by duplicated or stale type mappings, and it can be automated in the build pipeline. The latest patch fixes the default command so it emits plain JavaScript, improving out-of-the-box integration. The main governance ask is to treat morph aliases as part of the API contract and include generation in CI.
For engineering: The package generates JavaScript from Laravel’s morph map, removing the need to hand-maintain alias mappings in the frontend. It fits naturally into an Artisan-based build step. v1.2.2 is a bug-fix release changing the default morph-map command to emit plain JavaScript; there are no declared breaking changes, but generated artifacts should be regenerated and checked for module-format compatibility. Recommended adoption steps: pin the version, add generation to CI, commit or publish the generated output deliberately, and add a test that fails when the morph map changes without regenerating frontend assets.