Laracorekit Laravel Package

Getting Started

• Treat this as a Laravel 1.x project template/starter, not a drop-in library. The normal install path is composer create-project from the main repository, but the release notes warn that Packagist may still point at the legacy repository. For now, use an explicit VCS repository entry or clone the main repo directly.
• After install, inspect these first:
  • composer.json — Laravel version constraints, scripts, autoload mappings.
  • The module directory (likely modules/, app/Modules/, or similar) — this is where editable modules live.
  • tests/ and phpunit.xml — the release ships 27 tests / 121 assertions as a baseline.
  • public/ — prebuilt frontend/showcase assets are included, so you can run the app before rebuilding assets.
• Minimal bootstrap: composer install, copy .env.example to .env, php artisan key:generate, configure the database, php artisan migrate, then php artisan test.
• First practical use case: open one editable module, trace its route → controller → view → test, then duplicate that structure for a small feature. This validates the module conventions before you build anything substantial.

Implementation Patterns

• Module-oriented development: keep feature code inside editable modules rather than scattering it through app/. Each module should own its routes, controllers, models, migrations, views, and tests. Register module service providers through the project’s existing convention so discovery stays consistent.
• Frontend workflow: the release includes prebuilt public assets. Decide early whether your team commits built assets or builds them in CI. If you change source styles/scripts, rebuild rather than editing files in public/ directly. The showcase assets are useful as a reference but should be treated as replaceable.
• Testing workflow: use the shipped tests as the pattern for new work. Run php artisan test before and after changes. Add at least one feature test per module; the 121 assertions are a sanity baseline, not full coverage.
• New vs. existing applications: for greenfield work, use the 1.x project model. For existing 0.x applications, stay on the legacy repository/tags until you have a deliberate migration plan — do not assume the 1.x structure is backward compatible.
• Integration tip: pin the package/repository version in composer.json and document the explicit repository source. This avoids accidental resolution against the wrong Packagist metadata while the repository transition is in progress.
• Customization: prefer extending module service providers, config files, route files, and view namespaces over modifying core scaffold files. That keeps future template upgrades manageable.

Gotchas and Tips

• Packagist/repository mismatch: the most likely install failure is composer create-project pulling from the wrong source. Verify with composer show and use an explicit repository or VCS URL until Packagist points at the main repository.
• Legacy 0.x tags: keep 0.x and 1.x branches/tags clearly separated. Mixing structures across versions will produce confusing autoload, route, and asset errors.
• Prebuilt assets can hide build problems: if frontend changes do not appear, check the Vite/asset manifest and run the build step. Do not debug compiled files in public/; fix the source and rebuild.
• Module autoloading: after adding or renaming modules, run composer dump-autoload. If routes or config changes are not picked up, run php artisan optimize:clear.
• Test environment quirks: confirm whether tests use SQLite in memory, a seeded database, or factories. Check phpunit.xml and the base TestCase before assuming a failing test is a code defect.
• Extension points to favor: module service providers, published config, route registration, view namespaces, and the existing test structure. These are the safest places to add custom behavior without fighting the template.
• Upgrade discipline: because this is a project model rather than a library, “upgrading” means diffing the template and porting changes into your application. Keep custom code isolated in modules to make that diff tractable.