Conduit Test Dev Component Laravel Package

Getting Started

This is an initial v1.0.0 release, so treat it as a greenfield dependency: there is no migration path to worry about, but also no documented public API beyond installation. The release notes describe it as a Conduit CLI component — i.e. it plugs into a Conduit CLI application (the Laravel-flavoured console toolkit) rather than into a standard HTTP Laravel app.

Minimal steps:

composer require jordanpartridge/conduit-test-dev-component

Then, in order:

1. Read the package source before the README. With a 1.0.0 component, vendor/jordanpartridge/conduit-test-dev-component/src/ plus its composer.json (extra.laravel.providers, extra.conduit.*, autoload maps) tells you far more than the release notes. Look for a ServiceProvider and any command classes.
2. Check what it registers. Run php conduit list (or php artisan list if the app exposes commands that way) and diff against the list from before installation. New commands are the component's actual surface area.
3. Confirm where it belongs. If the component is genuinely test/dev tooling, it should live in require-dev, not require. Verify whether its provider is safe to boot in production before deciding — see Gotchas.

First use case: install it into an existing Conduit CLI app and use it to scaffold or assert your command test suite (Pest/PHPUnit around console commands), rather than as a runtime feature.

Implementation Patterns

Register the component explicitly if Conduit expects a manifest entry. Auto-discovery via extra.laravel.providers works for Laravel-style packages, but Conduit components are often listed in the host app's component/config manifest. Check both; a silently-unregistered component is the most common "it installed but does nothing" outcome.

Keep it in require-dev and gate the provider.

"require-dev": {
    "jordanpartridge/conduit-test-dev-component": "^1.0"
}

If the host app runs composer install --no-dev in production, the provider simply won't exist — that's the cleanest isolation for a dev component, provided nothing in require references its classes at compile time.

Pair it with a command-test harness. The practical day-to-day value of a dev component is asserting console behaviour:

it('runs the component command', function () {
    $this->artisan('your:command', ['arg' => 'value'])
        ->expectsOutputToContain('expected')
        ->assertExitCode(0);
});

If the component ships its own test base class or fixtures, extend those instead of hand-rolling a Testbench setup — that's usually the whole reason the package exists.

Use it in CI as a dev dependency. Add the composer step to your pipeline with dev dependencies installed, run the suite, and treat the component's own commands as smoke tests for your CLI wiring.

Compose with existing components. In a Conduit app, components are meant to stack. Where the package exposes bindings or extension hooks, override them in your app's provider rather than forking the vendor code.

Gotchas and Tips

• Documentation is thin by definition at 1.0.0. Pin to ^1.0 and read the source. Expect the public API to shift in 1.x minor releases until it stabilises; treat internal classes as off-limits.
• require vs require-dev matters more than usual. A dev component that registers commands unconditionally will show up in production list output and can fail if it depends on packages excluded by --no-dev.
• Silent no-op registration. If commands don't appear, check: package discovered? provider listed in bootstrap/providers.php or config/app.php? config cached (php artisan config:clear, php conduit config:clear)? In CLI contexts a stale cached config is a frequent culprit.
• Command name collisions. Conduit components commonly namespace their commands. If installation overwrites or shadows an existing command, list will show one entry and the resolution order is provider registration order — check yours.
• Container differences between CLI and HTTP. Bindings that resolve fine in a web request can fail in console context (missing request, different config bootstrapping). When debugging, -vvv on the command plus the full stack trace is faster than reasoning about it.
• Assert on output substrings, not exact strings. Console output formatting (padding, colour codes disabled in tests) makes exact-match assertions brittle across versions.
• Extension points to look for first: custom command registration, overridable stub/fixture paths, and any publishable config (vendor:publish --tag=...). Those are the three seams most Conduit components expose.
• Debugging checklist: composer show jordanpartridge/conduit-test-dev-component (confirm version and deps) → list (confirm commands) → -vvv (confirm runtime failures) → provider's register()/boot() (confirm what it actually does).