webnet-fr/database-anonymizer-bundle
Symfony bundle for anonymizing database data—replace sensitive fields with fake values via configurable rules, so you can safely copy production data to dev or test environments while keeping referential integrity intact.
This is a v0.0.1 release with no published release notes, so treat it as pre-stable scaffolding rather than a documented API. Before wiring it into anything, spend ten minutes doing reconnaissance:
composer.json first. Check the require block (which Laravel/Illuminate versions and PHP constraint you're bound to), the autoload section (PSR-4 namespace and whether there are files autoloads that run code on every request), and extra.laravel — that key tells you whether the package ships a service provider and/or facade alias, i.e. whether it self-registers or expects manual registration in config/app.php (older/simplified packages still do).src/*ServiceProvider.php → register() (container bindings, config merge, singletons) then boot() (publishes, routes, migrations, view/Blade directives, commands). Almost everything you need to know about day-to-day usage is visible in those two methods.php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" (or --tag= once you see the tags in boot()). If there's a config file, publish it and read it — every option is a supported integration point, and the defaults are the author's opinion of the happy path.php artisan about and php artisan package:discover output confirm discovery; if commands or bindings are missing, the provider isn't registered.First use case: resolve the package's primary class out of the container in php artisan tinker and exercise the smallest happy path (app(Primary::class)->doTheThing($fixture)). Because there's no changelog or docs to lean on, tinker is your fastest feedback loop for confirming the real method signatures — don't trust your reading of the source alone for argument order and return types.
Do that inside a throwaway branch with a green test suite. At 0.0.x you should assume the public API will move, so the goal is learning the shape, not committing to it.
Bind to the contract, not the concretion. If the provider binds an interface to an implementation, inject the interface into your own services and config()-select the implementation where possible. This is the single cheapest hedge against a 0.0.x → 0.1.0 rename, and it keeps the package swappable if you later need to drop it.
Funnel usage through a thin application-level wrapper. Rather than calling the package's classes from twenty controllers and jobs, expose one small service (e.g. App\Support\Foo) that takes the package class in its constructor and adapts it to your vocabulary. When a method signature changes upstream you edit one file, and you retain a seam for fakes in tests. This is especially important for a package with no semver guarantees yet.
Constructor injection over facades. Facades and app() calls read fine but make the dependency invisible and untestable in isolation. Prefer constructor injection, and register the package's config as your own config in config/services.php (or a dedicated config file) rather than calling config() against the vendor key in place — that lets you override per-environment via .env without touching vendor defaults.
Long-running processes: watch for state. Octane, queue workers, and php artisan serve (with --no-reload semantics) reuse the container. If the provider registers a singleton or the primary class holds per-request state, you'll get leakage in workers. Pattern: resolve per unit of work (app() inside the job/request), or reset in a Octane::tick/Queue::before hook, whichever fits.
Test integration with a fake, not the network. Write one thin integration test that asserts the package produces the shape you expect, then fake the package boundary everywhere else. Because v0.0.1 is likely to change behaviour silently, a single "characterization test" of the happy path documents the behaviour you actually rely on and will fail loudly when the next release shifts it.
Migrate it into the ecosystem properly. If require-dev includes orchestra/testbench, you can extend the provider in your own test suite to test the package's behaviour directly. If it ships a phpunit.xml/phpstan.neon, use those as hints about the supported quality bar.
0.0.1 with an empty changelog, pin the version exactly ("vendor/pkg": "0.0.1", not ^0.0.1 — and note Composer treats ^0.0.1 as >=0.0.1 <0.0.2, so caret is stricter here than elsewhere, but exact still documents intent). Commit the lockfile. Treat upgrades as manual review events, not composer update side effects.php artisan config:clear in dev; a stale bootstrap/cache/config.php is the number-one cause of "the config change did nothing" with freshly installed packages. Add config:cache verification to your deploy pipeline before you go to production.composer dump-autoload fixes it. If a new provider "isn't found", it's the same root cause via the package discovery manifest — php artisan package:discover and composer dump-autoload in that order.env() inside the config file (correct) but a few read it in the provider (wrong under config:cache, where env() returns null). Grep the source for env( outside config/; if you find it, work around it by setting the corresponding config key explicitly.php artisan tinker for signatures, ->dd() on the service provider bindings via a quick php artisan about --only=environment, and Laravel\Telescope (if present) to see whether the package is touching queries/HTTP that you didn't expect. For exception origins, config('app.debug') plus vendor/ stack frames tells you instantly whether the fault is yours or the package's.extend() a container binding, look for a published config key or event; a container override is legitimate but unsupported, so leave a comment in your code explaining why — the next developer will need it.How can I help you explore Laravel packages today?