- Is solidry/api-generator compatible with Laravel 10 or 11?
- The package's last tagged release dates to August 2020, which predates Laravel 8 through 11 and the PHP 8.x line, so its official compatibility window stops around Laravel 5.5 to 6.x. On modern Laravel expect Composer constraint conflicts on the illuminate/* packages and plan for a fork or dependency overrides. Run composer why-not laravel/framework with your target version as the first gate before committing. Generated code may also encode older Laravel idioms that need manual refreshing.
- How do I install and configure solidry/api-generator?
- Install it as a dev-time dependency with composer require --dev solidry/api-generator, then publish the package config if one is provided. Generation is driven through Artisan commands, so you define your resources in the package's own schema format and run the generator to emit controllers, routes, form requests, and serializers. Because it is a build-time tool, it never sits in the request path and adds no runtime coupling. Expect to commit the generated files and hand-tune them as part of your normal code review.
- What does solidry/api-generator actually generate for a Laravel model?
- It scaffolds Eloquent-backed models, controllers, form requests, routes, and JSON:API serializers from a resource definition. The value is removing the boilerplate that JSON:API's data, included, links, and meta structure otherwise forces you to write by hand. Output is meant to be committed to version control and then customized, so treat it as a starting point rather than a black box. If your app is Inertia or Livewire-first, the generated endpoints may be more surface area than you need.
- Does solidry/api-generator fully support the JSON:API specification?
- The package advertises complete support for the JSON:API data format, including resource serialization into data, included, links, and meta shapes. However, the last release predates several JSON:API spec revisions, so verify emitted documents against current conformance rules instead of trusting the claim. Check media types, compound documents, error objects, and sparse fieldsets explicitly in a spike. Treat spec drift as a known, manageable risk rather than a guarantee.
- Can I re-run the generator without overwriting my custom code?
- The documented workflow treats generated code as something you commit and then hand-modify, which implies regeneration and manual edits will eventually collide. There is no strong evidence of diff-aware or idempotent generation, so assume a re-run will overwrite files. The practical mitigation is to generate once, keep everything in VCS, and treat later regeneration as a deliberate merge rather than a routine command. Agree as a team on which files are generated versus hand-owned before adopting the tool.
- Is solidry/api-generator still maintained?
- The last tagged release is from August 2020 and there is no visible active maintainer, so it should be treated as effectively unmaintained. That risk lands mostly on the code it emits rather than on runtime behavior, since it is a dev-time dependency. If you adopt it, budget for owning a fork or vendoring the generator internally. Pin the version explicitly and run composer audit over the resolved dependency graph before merging.
- How do I define resources with the generator's schema DSL?
- You describe each resource in the package's own definition or schema format, then invoke the Artisan generator to produce the Laravel artifacts. The learning curve of that DSL is the main integration friction: it is not turnkey, and you must model resources before generating them. The definition surface covers attributes, relations, and serialization concerns, though depth of support for your specific domain needs verification. Run a one-resource spike and compare the output against your existing conventions before standardizing.
- Does solidry/api-generator handle polymorphic relationships and sparse fieldsets?
- JSON:API requires both, and the package's stated scope is complete JSON:API support, so polymorphic relationships and sparse fieldsets should be representable in its definitions. In practice the 2020-era release may lag later spec clarifications, and the DSL's expressiveness for polymorphic relations is worth proving rather than assuming. Test a real polymorphic case end to end in a spike branch. If your domain leans heavily on compound documents, budget extra validation time for included resources and relationship links.
- How should I test the endpoints generated by solidry/api-generator?
- The generator emits ordinary Laravel controllers, routes, and form requests, so you test them like any hand-written endpoint. Write feature tests that hit the routes and assert the JSON:API document structure, including data, included, links, and meta keys, plus the correct media type header. Assert validation failures produce proper 4xx error objects and that relationship endpoints behave correctly for missing or forbidden resources. Doing this during the spike tells you whether the emitted code meets your standards before you adopt.
- What are the alternatives to solidry/api-generator for Laravel APIs?
- For plain REST, Laravel's own make:model, make:controller, and make:request commands plus hand-written API resources cover most scaffolding needs with no extra dependency. If you want JSON:API compliance without a stale generator, dedicated JSON:API packages for Laravel handle serialization and spec conformance at runtime. OpenAPI tooling such as Scramble can document endpoints you already have. Solidry only earns its place if you have already committed to JSON:API as your wire format and want a fast first draft.