Krayin Package Generator Laravel Package

Getting Started

This is a dev-time scaffolding tool, not a runtime dependency. It generates the boilerplate for a Krayin module so you can skip the repetitive wiring and get straight to domain code.

1. Match generator major to Krayin major. As of v2.0.0 the generator explicitly targets Krayin v2.0.0. The pairing is now one-to-one at the major level: generator 2.x → Krayin 2.x, generator 1.x → Krayin 1.x. Do not mix them — the stubs encode the host's conventions (service providers, migrations, menu/ACL wiring), and a mismatched major is the most common reason generated files look "wrong."
2. Install as a dev dependency inside an existing Krayin installation:

   composer require --dev krayin/krayin-package-generator:^2.0
   

   The repo still has no public documentation and only a small star count, so treat the source as the spec. Read the service provider and the stubs/ directory before you run anything — that tells you exactly what you'll get.
3. Just run the command bare. Since v2.0.0, invoking it with no arguments prompts interactively for the required inputs (vendor, package name, author, description). So start with:

   php artisan list | grep -i package
   php artisan <generator-command>
   

   The prompt walks you through the arguments — no need to guess the signature or memorize flags. Use the flag form once you're scripting module creation in CI or a team bootstrap script.
4. First use case: a small internal module — e.g. customer feedback notes, an audit trail, or a custom dashboard widget. Generate it, run it end-to-end (migration → route → controller → view) once before building anything complex, so you learn where the generated wiring is incomplete on Krayin 2.x.
5. Where to look first after generation: the package's composer.json (PSR-4 namespace and path), its ServiceProvider (what it registers — routes, migrations, views, translations), the routes file, and the migration stub. Those four files define how the package plugs into Krayin.

Implementation Patterns

Scaffold → register → migrate → iterate. Treat generation as step zero of a repeatable workflow:

php artisan <generator-command>            # prompted, or pass args for scripts
composer dump-autoload
php artisan migrate
php artisan route:list | grep package-name

Follow Krayin's module convention, not Laravel's package convention. Krayin keeps modules under packages/{Vendor}/{Name} with a src/ tree, registered via a path repository in the root composer.json and a provider in the app config. Generated code should slot into that layout — resist "fixing" it into a standard vendor/package structure, because Krayin's admin UI, ACL, and menu system assume the module layout.

One package per bounded context. Use the generator per feature area (e.g. Acme/Feedback, Acme/AuditLog) rather than one giant Acme/Custom. This keeps migrations and route files small and makes it trivial to disable a module by removing its provider registration. The interactive prompt makes it cheap to spin up several small modules in one sitting.

Layered structure inside the generated package. The generator gives you the skeleton; keep domain logic in predictable folders:

src/
  Models/
  Repositories/        # Krayin/Webkul convention — wrap Eloquent here
  Contracts/
  Http/Controllers/
  Http/Requests/
  Database/Migrations/
  Resources/views/
  Routes/
  Providers/

Following the Repository + Contract pattern matters if you ever want your module to feel native to Krayin's codebase and be reviewable by Webkul-style maintainers.

Wire up what the generator leaves out. Typically you will still need to:

• Register the provider (root config/app.php on older Laravel, bootstrap/providers.php on Laravel 11+).
• Add the package to the root composer.json repositories/autoload if the generator doesn't.
• Add the module to Krayin's admin menu and ACL — generated controllers are protected by Krayin's permission system, so a new route with no ACL entry returns 403 or silently disappears from the nav.
• Add translations under Resources/lang/ (Krayin ships many locales; missing keys fall back awkwardly).

Use it for internal modules, not distributable packages. The generated scaffold assumes it lives inside a Krayin install. If your goal is a package for Packagist, you'll end up reworking the composer.json, namespaces, and test setup — Laravel's own orchestra/testbench-style scaffolding is a better base.

Customize the stubs once, for the whole team. If the generator supports publishing or overriding stub files, do it early: bake in your company's license header, declare(strict_types=1), repository/contract skeleton, and a default PHPUnit/Pest setup. Every module generated afterwards is then consistent. Re-verify overrides after the 1.x → 2.x stub changes described below.

CI hygiene. Because it's --dev, keep it out of production images. In CI, run composer install --no-dev for deploy builds and verify the generated module's autoload entries are committed, otherwise composer dump-autoload -o on the server won't see the package.

Gotchas and Tips

• It is not a runtime package. Requiring it in production adds dead weight and can pull in dev-only dependencies. Keep it in require-dev and exclude it from release builds.
• Pin the major to your Krayin version, explicitly. ^2.0 on Krayin 2.x, ^1.0 on Krayin 1.x. v2.0.0's headline change is Krayin 2.0 compatibility — meaning the stubs were retargeted. Loosening the constraint (or using *) lets Composer pull a generator whose stub conventions don't match your host.
• Upgrading Krayin 1.x → 2.x means reviewing, not regenerating. Do not re-run the generator over existing modules and overwrite them. Generate into a scratch directory, diff against your live module, and port the differences — especially provider registration, migration signatures, and menu/ACL wiring, which are exactly what a compatibility release touches.
• Autoload is the #1 failure mode. After generating, an un-dumped autoloader produces Class not found errors that look like provider registration problems. Always composer dump-autoload immediately, and again after adding files.
• Case sensitivity in namespaces. The interactive prompt accepts free text, so a typo in casing is easy. Generators substitute the vendor/package name into namespaces and paths. On case-sensitive Linux filesystems, Acme/Feedback vs acme/feedback produces packages that work on macOS and 404 on the server. Pick PascalCase for namespaces, kebab-case for the composer name, and verify the generated composer.json matches.
• Double-check the prompted values before committing. Prompted arguments are baked into namespaces, composer names, and file paths — a wrong vendor name means a rename across the whole package. If you're scripting many modules, prefer explicit arguments so the values are visible in your terminal history or bootstrap script.
• Route caching bites. Krayin/Laravel caches routes and config in production. A newly generated module's routes won't appear until php artisan route:clear && php artisan config:clear && php artisan optimize. Make this part of your deploy step.
• Migrations may not be auto-discovered. Some generators register loadMigrationsFrom only for the package's own path; if you add migrations in subfolders, they're skipped. Debug with php artisan migrate:status.
• Krayin's admin guard and middleware. Generated routes are often plain web middleware. Krayin's admin area expects its own auth/ACL middleware and route prefix. Copy the middleware stack from an existing Krayin 2.x module rather than inventing one, and add the ACL permission record or admins can't reach your screens.
• Menu registration is manual. A module can be fully functional and still invisible because nothing told Krayin's menu system about it. Look at how existing modules register menu items (usually in the provider or a Menu class) and mirror it.
• Sparse docs mean read the source. There's no community safety net. The fastest debugging path is: read the generator command class → read the relevant stub → compare against a known-good Krayin module in packages/Webkul/. Diffing a generated module against a core module is the single most effective way to spot missing wiring — and it's now also the fastest way to see what changed in the v2 stubs.
• Extension points worth knowing: config for output path/vendor defaults, stub overrides for team conventions, and the command class itself (subclass it to add post-generation steps like auto-registering the provider or seeding an ACL permission). The new interactive prompting lives in that command class, so it's the place to look if you want your own defaults or validation on top.
• Don't fight the generated code. If a stub doesn't fit your needs, change the stub — not every generated file in every module. Otherwise future regenerations reintroduce the same friction.