Learn Monorepo Foo Laravel Package

Getting Started

This is a pre-1.0 (0.0.6) sub-package from a monorepo, so treat it as experimental and verify the API against the source before building on it.

1. Check compatibility first. Read the package's composer.json for php and illuminate/* constraints. At 0.0.x, Laravel/PHP support may change between patch releases.

2. Install it. The package may not be on Packagist yet. Add it as a VCS or path repository:

   {
     "repositories": [
       { "type": "vcs", "url": "https://github.com/feryardiant/learn-monorepo-foo" },
       { "type": "path", "url": "../learn-monorepo-foo/packages/foo", "options": { "symlink": true } }
     ]
   }
   

   Then composer require feryardiant/learn-monorepo-foo:0.0.6 (adjust the vendor/package name to whatever the sub-package's composer.json declares — the monorepo root name is not the installable unit).

3. Look here first, in order: composer.json (name, autoload, provider), src/ (service provider and public classes), tests/ (the Pest suite added in v0.0.6 is now the most reliable usage documentation), and the GitHub releases/tags.

4. First use case: run the package's own test suite before wiring it into your app.

   composer install
   ./vendor/bin/pest
   

   The Pest tests introduced in this release are effectively executable examples of the intended API. Read them before writing integration code.

Implementation Patterns

Pin, don't float. In 0.0.x, caret constraints are extremely narrow and easy to misread:

"require": { "feryardiant/learn-monorepo-foo": "0.0.6" }

^0.0.6 resolves to >=0.0.6 <0.0.7, not <1.0. Use an exact version or ~0.0.6 and review each release manually.

Develop against a path repository. Because this is a monorepo sub-package, symlink it locally so changes are live:

composer config repositories.foo path ../learn-monorepo-foo/packages/foo
composer require feryardiant/learn-monorepo-foo:*
composer dump-autoload

Run ./vendor/bin/pest inside the package directory to validate changes before committing.

Respect the per-sub-package release unit. v0.0.6 added release automation for each sub-package, meaning tags are likely scoped per package (e.g. foo-v0.0.6) rather than a single monorepo tag. When requiring the package, confirm which tag corresponds to it:

composer show feryardiant/learn-monorepo-foo --all
git tag --list '*0.0.6*'

Integration checklist in a Laravel app:

• If auto-discovery is not configured, register the provider manually in bootstrap/providers.php (Laravel 11+) or config/app.php.
• Publish anything the provider exposes: php artisan vendor:publish --provider="Vendor\\Package\\ServiceProvider".
• If migrations ship with it, run php artisan migrate only after reviewing the migration files — at this version, expect schema changes without upgrade guides.

Mirror the package's Pest setup in your own suite. Copy its tests/Pest.php / TestCase conventions so package-level behavior is covered in your CI matrix alongside your application tests.

Wrap third-party surface area. Given the version, isolate calls behind a small adapter or service class in your app so a breaking 0.0.7 change is a one-file fix.

Gotchas and Tips

• 0.0.x has no stability promise. Any patch release can break the public API. Lock versions in composer.lock, commit it, and read the diff before bumping.

• Monorepo resolution conflicts. Composer may try to resolve the root package instead of the sub-package. Verify with composer show <vendor>/<package> that the installed path points at the sub-package directory, not the repo root. composer why-not <vendor>/<package> 0.0.6 is the fastest diagnostic.

• Autoload after adding a path repo. Symlinked packages frequently need composer dump-autoload before new classes appear. If you get "class not found," this is the first thing to check.

• Pest is a dev dependency. The new test suite requires pestphp/pest and a compatible PHPUnit. If your app pins an older PHPUnit, run package tests in isolation (separate CI job or composer update --working-dir) rather than merging dev requirements.

• Release automation ≠ changelog quality. Per-package automation often produces tags with terse notes. Diff the tags directly:

  git diff <previous-tag>..<new-tag> -- packages/foo
  

• No upgrade guide exists yet. Before each bump, diff src/, config/, and migrations. Look specifically for renamed config keys, changed provider bindings, and altered method signatures.

• Debugging inside Laravel: use php artisan about to confirm the provider loaded, php artisan vendor:publish --list to see publishable assets, and app()->getProvider(...) in tinker to inspect bindings.

• Extension points are whatever the provider exposes. At this stage, the practical extension surface is container bindings (override via $this->app->bind(...) in a later-registered provider) and published config. There is no documented plugin system — do not assume one.

• CI advice: add a job that installs the package at the pinned version and runs its Pest suite. It catches upstream breakage before your app does, and gives you a reproducible bug report when filing issues.