Laravel Class Generator Laravel Package

Getting Started

v1.4.0 is a constraint-widening release, not a feature release: the only documented change is that the Laravel framework requirement now includes 13.0. That means the "getting started" story is unchanged for anyone on Laravel 10–12, and the package is now installable on Laravel 13 projects.

• Check your constraint first. Before anything else, confirm what your composer.json allows:

  composer show <vendor>/<package> --all | grep -A2 requires
  

  You want to see the Laravel framework constraint expressed as an OR-chain that includes ^13.0 (e.g. ^10.0|^11.0|^12.0|^13.0). If your locked version predates v1.4.0, you are still pinned out of Laravel 13.

• Install / upgrade:

  composer require <vendor>/<package>:"^1.4"
  # or, inside an existing project already on Laravel 13:
  composer update <vendor>/<package> --with-all-dependencies
  

  --with-all-dependencies matters here — the framework itself and any shared transitive constraints need to move together.

• Where to look first. Read the package's composer.json (the constraint is the actual contract), then the service provider and any config/*.php it ships. Those three files tell you how it registers into the container and what is configurable — the README is usually a subset of that.

• First use case. Get the package booting and exercising its default path on your current Laravel version before touching 13. That gives you a known-good baseline so that if something breaks on 13 you can attribute it correctly rather than guessing.

Implementation Patterns

• Verify compatibility in CI, not locally. If the package is part of your stack, add Laravel 13 to a test matrix row. A green build on 12 says very little about 13.

  matrix:
    laravel: ['11.*', '12.*', '13.*']
    include:
      - laravel: '13.*'
  

• Treat the version bump as a two-sided decision. For an application on Laravel 12, v1.4.0 is a no-op upgrade — take it, stay current, no code changes. For an application moving to Laravel 13, v1.4.0 is a prerequisite, and this is the release that unblocks the framework upgrade.

• Resolve the upgrade order deliberately. When you upgrade Laravel, do it in two steps: first bump the framework and run composer update, letting Composer report which packages block 13; then upgrade the blockers. If this package is one of several that only just added 13 support, check the others too — the last blocker is the one that costs you a day.

• Pin to ^1.4 if you're on Laravel 13. Earlier 1.x releases cannot satisfy a illuminate/*: ^13.0 requirement, so an unconstrained ^1.0 will still resolve — but to a version that will fail composer update on 13. Explicit constraints make that failure legible.

• Keep framework-coupled logic behind the package's own abstractions. The whole point of a release like this is that the package insulates you from framework internals. If you've reached around it into Illuminate\* classes directly, that code is now your Laravel 13 migration problem, not the maintainer's.

Gotchas and Tips

• This release says nothing about behaviour. The changelog mentions only the framework constraint. Assume zero functional changes; if you observe different runtime behaviour after upgrading, suspect your own Laravel version change, not v1.4.0.

• ^13.0 ≠ "13 works everywhere." A widened constraint means the package installs on 13 and its test suite presumably passes there. It does not guarantee every optional integration (queue driver, cache store, HTTP client, dev tooling) has been exercised. Smoke-test the paths you actually use.

• Watch for the silent no-op. If Composer resolves the package to v1.4.0 but your app is still on Laravel 12, you're running the code path that was already tested — fine, but don't treat the version number as evidence you're Laravel 13-ready.

• Transitive conflicts are the real failure mode. composer why-not <vendor>/<package> 1.4.0 and composer why-not laravel/framework 13.0 are the fastest way to find which package is holding you back. Reach for those before hand-editing constraints.

• Debugging config drift. After any framework-version change, php artisan config:clear (and cache:clear, route:clear) before concluding something is broken. Config cached against a previous framework version produces confusing, non-reproducible errors.

• Extension points remain the safe surface. Custom drivers, container bindings, and published config are what this package expects you to customise. Anything you've monkey-patched or subclassed internally is unverified against 13 and should be re-checked manually after the upgrade.

• If you are not going to Laravel 13 yet, upgrade anyway and stop reading — you get the same code, a supported version string, and no migration work. Only revisit when 13 is on your roadmap.