propaganistas/laravel-fakeid
Generate fake identity documents—ID cards, passports, driver's licenses—for testing and seeding in Laravel. A simple facade produces realistic fake IDs with names, photos, and country-specific details, so demos and test suites never rely on real personal data.
This assessment is being written cold: there is no prior assessment and no package metadata, class list, or usage data in scope. The only signal is release 4.2.3, whose changelog reads in full:
Marking package as abandoned. Sorry!
That is the entire release. There is no functional diff, no deprecation shim, no redirect to a successor package. 4.2.3 is a governance release, not a code release — treat it as an end-of-life notice that happens to have a version number attached.
What to do first, in order:
composer show <vendor>/<package> and composer why <vendor>/<package>. If you are on <= 4.2.2, 4.2.3 may be byte-identical in runtime behaviour; the abandonment flag is metadata on the Packagist record. If you are already on 4.2.3, nothing about your application changed at runtime — only your support posture did.grep -r the package namespace through app/, routes/, config/, database/, and any queued jobs or artisan commands. Laravel packages leak into surprising places: service providers in config/app.php or bootstrap/providers.php, facades and aliases, published config at config/<package>.php, migrations with the package's table prefix, and Blade components registered via a provider.composer update cannot silently pull a 5.0 from a maintainer who has stopped caring about semver.Your first real use case is not "build a feature with this package" — it is inventory and containment. Day one is spent drawing a boundary around the dependency so that everything afterwards is a normal Laravel refactor rather than an emergency.
Pin hard, and say why. In composer.json, constrain to the exact last-good tag ("vendor/package": "4.2.2") or a tight range, and add a comment in your README or an ADR recording the abandonment date and the migration owner. A floating ^4.0 constraint against an abandoned package is a landmine: you get no security patches, but you do still get breaking changes if the repository is ever transferred or a well-meaning contributor tags something.
Wrap the package behind your own seam. If the package is used in more than a handful of places, introduce a thin application-level abstraction — an interface, a repository, a service class, a facade of your own — and migrate call sites to it before you migrate off the package. This is the single highest-leverage move. It converts an unbounded "replace a dependency" project into a bounded "implement one interface" task, and it means the eventual swap touches one file instead of forty. Do this even if you have no immediate replacement in mind; the seam costs a day and buys you optionality.
Prefer fork-and-replace over fork-and-edit. If you need a patch (a security fix, a PHP 8.4 deprecation, an upstream API change in Laravel), do not edit vendor/. Add a vcs or path repository entry in composer.json pointing at your fork, keep the same namespace so no call sites change, and carry the patch as a tag (4.2.2-p1). Document the patch in the fork's README so the next developer knows exactly what diverges from upstream.
Migrate by capability, not by package. Enumerate what the package does for you — queued jobs, PDF rendering, a payment gateway, a media library — and evaluate maintained alternatives against that capability list. Laravel's ecosystem usually has two or three credible options; the risk is picking one with a different concurrency model or config shape and discovering it during rollout. Run both implementations side by side behind your seam (feature flag, or a config-driven binding in a service provider) and shadow-compare outputs on real data before cutting over.
Freeze the surface area. While the package is in place, lock down its config with a test that asserts the published config file matches expectations. Abandoned packages are prime candidates for a "helpful" fork publishing a new config key with a dangerous default — if config/<package>.php is versioned in your repo and an assertion guards it, an accidental merge-review miss becomes a failing test.
The Composer warning is stderr, and it will bite CI. Composer emits Package <vendor>/<package> is abandoned, you should avoid using it. No replacement was suggested. on install and update. Any pipeline that treats non-empty stderr as failure — or that greps build output for "abandoned" — turns red on the next dependency resolution. Decide deliberately whether to suppress, ignore, or surface it, and put that decision somewhere a human will read it. Silencing it without a migration ticket is how packages quietly rot for three years.
"No replacement was suggested" is the important half of that message. The maintainer did not name a successor. Do not assume the obvious ecosystem alternative is a drop-in — verify the config schema, the facade surface, and the published migrations yourself. Absence of a redirect is a signal that the author may not know of one either.
Semver is now a fiction. An abandoned repo can still be tagged. Do not let composer update run unrestricted against it in any environment, and consider composer.lock as the actual source of truth (it always was — the abandonment just raises the stakes). Beware transitive abandonment too: if this package is a dependency of something you depend on, composer why will show you the parent, and the parent is where your upgrade pressure will come from.
Security auditing goes quiet, not loud. composer audit will still flag known advisories, but nobody is going to publish a fix. An advisory against this package is permanent. Set a calendar reminder to re-check the advisory database quarterly, and treat any hit as a forced-migration trigger rather than a patch-and-move-on.
Do not ship 4.2.3 as a "bugfix release." If your release process auto-bumps dependencies, a version ending in a patch increment will read as low-risk to reviewers. It is not a code change, but it is the moment your support contract ends. Call it out in the changelog of your own app.
Debugging an abandoned package is archaeology. There will be no upstream issues answered, no maintainer to ping, and no docs updates for the Laravel version you are on. Keep a local checkout of the source under vendor/ (or the fork) and read it directly — vendor/vendor/package/src is now your primary documentation. When something breaks after a Laravel upgrade, the failure is almost always in the package's service provider or its use of a framework-internal API; bisect by temporarily binding a stub in your seam rather than by patching vendor/ in place.
Forking is cheap; maintenance is not. Before you fork, honestly assess whether you are signing up to track Laravel releases for years. For a small utility, forking and patching one method is fine. For anything touching auth, payments, or persistence, forking is usually a slower route to the same migration you were avoiding. The seam from the previous section is the escape hatch that makes either choice survivable.
How can I help you explore Laravel packages today?