Learn Monorepo Bar Laravel Package

Getting Started

This is a pre-1.0 package (v0.0.6) with a very small release footprint so far. Start with the repository itself rather than assuming a stable public API:

1. Install into a scratch Laravel app first (composer require feryardiant/learn-monorepo-bar) so you can inspect what the service provider registers before committing to it in a real project.
2. Read composer.json for the package's autoload namespace, then open src/ to find the service provider and any facade or config file.
3. Check tests/ — as of v0.0.6 this is now a Pest suite, which is the best available documentation of intended behaviour. Read the tests before the source; they show the expected call signatures.
4. Publish any config with php artisan vendor:publish --tag=<package-tag> and diff it against the package defaults before editing.

The first realistic use case is evaluating it in a throwaway branch: wire it into one small feature, confirm the service provider resolves and the published config is sane, then decide whether the API is stable enough for your codebase. Given the 0.0.x version, treat it as an experiment rather than infrastructure.

Implementation Patterns

Because the release notes only cover tooling (Pest test scaffolding and per-sub-package release automation) rather than new runtime features, the practical patterns are around consumption and version pinning:

• Pin to an exact version. In a 0.0.x line where releases are automated, minor bumps can land frequently. Use "feryardiant/learn-monorepo-bar": "0.0.6" while evaluating, and only loosen to ^0.0.6 once you have tests covering the integration.
• Wrap the package behind your own boundary. Put any calls to its classes behind a small service class or interface in your app. If the API shifts on the next automated release, you change one file instead of grepping your codebase.
• Mirror the package's Pest style. If your own test suite is Pest, follow the conventions introduced in v0.0.6 so your integration tests read consistently with the package's own; if you use PHPUnit, keep the package's tests out of your run via phpunit.xml exclusions and write your own thin integration test instead.
• Feature-test the wiring, not the internals. Add one test that boots the provider and asserts the config/bindings you rely on. That single test will catch most breakage from automated releases far more cheaply than reading changelogs.
• Track releases via the monorepo compare links. The release notes link to a commit range on learn-monorepo-bar; since this is one package in a monorepo, subscribe to tags for this sub-package specifically rather than the whole repo, otherwise you will get noise from sibling packages.

Gotchas and Tips

• Automated release tooling means fast-moving tags. v0.0.6 introduces release automation on each sub-package. Expect patch and minor releases with terse changelogs that describe tooling changes rather than behaviour changes. Read the compare diff, not just the notes, before upgrading.
• Monorepo split lag. In a monorepo with per-package release automation, the tag on the split repository can occasionally point at a commit that differs from what you'd expect from the main repo. Confirm the tag resolves to the commit you intend (composer show feryardiant/learn-monorepo-bar plus a look at the tag on GitHub) when debugging odd behaviour.
• Pest was introduced here, not before. If you had already vendored or copied tests from an earlier tag, they will be PHPUnit-style; do not assume the test bootstrap matches your app's. Installing the package should not pull Pest into your production dependencies — verify it stays in require-dev.
• No documented deprecation policy yet. With no 1.0 and no prior assessment, there is nothing guaranteeing backwards compatibility. Treat every 0.0.x bump as potentially breaking and let your integration test be the gate.
• Extension points are unknown and therefore risky. Before subclassing or decorating internal classes, check whether they are final and whether the provider binds interfaces or concrete classes. Prefer binding overrides in your own provider over editing published config.
• Debugging provider issues: if the package's bindings don't appear, run php artisan about and php artisan package:discover to confirm discovery happened, and clear bootstrap/cache/packages.php — monorepo packages with unusual autoload paths are a common cause of silent discovery failures.
• Keep a changelog bookmark. Until the README documents behaviour, the commit history of learn-monorepo-bar is the de facto documentation; check it before filing issues.