Core Laravel Package

Getting Started

Treat the first hour as source reconnaissance, not a tutorial. The README is accurate but thin, and the package is proprietary, zero-star, and has no dependents — there is no Stack Overflow backlog to fall back on.

1. Confirm you can install it at all. Check the require block in vendor-side composer.json before writing any code. The README states PHP 8.5+ and Laravel 13.x; if your app is on 8.3/11.x the resolver will simply refuse. Pin an exact version — this is a 0.x package:

composer require devanoxltd/core:0.2.1

If the repo is private, add it as a VCS repository first:

"repositories": [
  { "type": "vcs", "url": "[email protected]:devanoxltd/core.git" }
]

2. Read these four things, in this order.

3. Publish and migrate. All resources at once, or granularly:

php artisan vendor:publish --tag="core"          # everything
# or: core-config / core-migrations / core-views / core-lang / core-assets
php artisan migrate

4. First use case — prove modules work. This is the riskiest claim in the package, so validate it before building on it:

php artisan module:list

Then add one throwaway module under modules/ (or whatever core.module_path says) containing Config/config.php plus a single route, and confirm discovery:

php artisan module:enable Reports
php artisan module:list

5. Second use case — helpers in tinker. They are global functions, so check for collisions with your own app helpers before relying on them:

php artisan tinker
>>> isAppInstalled(); modules(); tenant(); tenancy();

6. Tenancy, only if you need it. Publish the tenancy config and migrations, run the installer, migrate, then wire tenant routes into bootstrap/app.php via withRouting(... then: ...) using PreventAccessFromCentralDomains and the tenant. route name prefix. First real operation is php artisan tenant:create-database {id}.

7. Set the locale now. Translations ship under the eng locale. Add APP_FALLBACK_LOCALE=eng to .env or every core string renders as a raw key.

8. Run the license check early, in a scratch environment: php artisan devanox:license-check. Know what success, failure, and no-network look like before this appears in staging.

Implementation Patterns

Modules are the product; helpers are convenience; licensing is a gate. Design each accordingly.

Module layout

One module per bounded context (Billing, Reporting, Onboarding), never per layer (Models, Controllers). A stable shape:

modules/Billing/
├── Config/config.php          # required — module metadata the package reads
├── Providers/BillingServiceProvider.php
├── routes/web.php
├── database/migrations/
└── Helpers/

Rules that survive team growth:

• Modules communicate via events or contracts; a concrete class reference into another module means they are one module wearing two hats.
• Every module owns its migrations and runs them with php artisan module:migrate Billing — not the global migrate.
• Treat enable/disable as a production kill switch. php artisan module:disable Billing beats a hotfix deploy when a module misbehaves.

Command-driven operations

Fold the package commands into your existing rituals rather than inventing new ones:

Tenancy in application code

Use tenancy()->run() for any scoped work — it sets the tenant, switches connections, and restores state afterwards:

tenancy()->run($tenant, function ($tenant) {
    // runs on the tenant's connection
});

Guard with tenant() rather than assuming context. It returns null when tenancy is disabled or unresolved, so tenant()?->id is the safe default in Blade and service code.

Extending tenancy models

Add relationships by subclassing, then repoint config — do not patch vendor:

namespace App\Models;

use Devanox\Core\Models\Tenant as BaseTenant;

class Tenant extends BaseTenant
{
    public function users()
    {
        return $this->hasMany(User::class);
    }
}

// config/tenancy.php
'models' => [
    'tenant' => App\Models\Tenant::class,
    'domain' => Devanox\Core\Models\Domain::class,
],

Extension points worth wiring on day one

• Events — Tenant\Created and Tenant\DatabaseCreated are where provisioning, seed data, and queue-connection setup belong. Listen to both; don't poll.
• Middleware — InstallApp is auto-registered; apply it deliberately. PreventAccessFromCentralDomains is prepended to priority when tenancy is on.
• UI — Blade components under core::, Livewire components natively, and the Core facade aliased via composer.json. Use Core:: for anything not exposed as a helper.

Gotchas and Tips

Namespace and provider drift. The README says Providers (plural); older Laravel packages use Provider. If vendor:publish reports nothing publishable, grep extra.laravel.providers in the package's composer.json for the real class name. Always publish by --tag= where possible — tags are more stable than provider strings.

The platform constraint is the whole ballgame. PHP 8.5 / Laravel 13 means you cannot drop this into an existing app casually. Confirm your CI image, local Docker, and production runtime all satisfy it before the first composer require, or you will discover it in a deploy.

Proprietary license, NOASSERTION. Get legal sign-off before it touches a client codebase, and check whether devanox:license-check phones home. If it does, decide now how CI and air-gapped environments behave — stub the check in your test suite rather than letting it fail builds.

The eng locale trap. Without APP_FALLBACK_LOCALE=eng, every __('core::...') string leaks as a key. Publish core-lang and add an en directory under lang/vendor/core/ if your app is strict about en.

InstallApp is global. It short-circuits on storage/installed. In fresh CI databases, parallel test runs, or a container that rebuilt its storage volume, this middleware will redirect or 403 before your route ever runs. Create the marker file in your test bootstrap or exclude the middleware on health and installer routes.

Prepended middleware priority. Because PreventAccessFromCentralDomains is prepended, your own domain-aware middleware may run after it. If central-domain requests behave unexpectedly, inspect $middleware->priority() ordering before debugging your own code.

Never assert on tenant(). It is null in central context, in queued jobs unless you re-establish context, and in console commands. Jobs that touch tenant data need explicit tenancy()->run() inside handle(), not tenant state serialized from the dispatching request.

Long-lived workers. Under Octane or long-running queue workers, verify tenancy()->run() fully restores config after the callback. If a tenant's DB connection leaks into the next job, you will see cross-tenant reads — the worst possible bug class. Write one test that runs two tenants back-to-back and asserts connection identity in between.

Autoloading. If modules define their own PSR-4 roots, composer dump-autoload belongs in your deploy script. Classmap-authoritative deployments silently miss newly added module namespaces.

Migration ordering. module:migrate and migrate are separate ledgers. Pick a fixed order in the deploy script and document it, or a fresh environment will diverge from a long-lived one.

Zero stars, zero dependents, 0.x versions. Read the source for anything the README hand-waves — particularly license verification side effects at boot. Pin the version, commit composer.lock, and keep a fork path open. When something breaks there is no issue thread to search; git log and the changelog files are your only history.