- Does fakerino/laravel-fakerino work with Laravel 11 and PHP 8?
- No. The last release was on 2015-05-26, which places it in the Laravel 5.0/5.1 and PHP 5.4–5.6 era, and its Composer constraints will almost certainly conflict with current Laravel and PHP 8.x targets. Installation will either fail dependency resolution or require --ignore-platform-reqs, which is not acceptable for production. Running it on PHP 8 requires a fork and a modernization pass, not a configuration tweak.
- How do I install fakerino/laravel-fakerino in a Laravel app?
- On a legacy Laravel 5.x stack you would require the package with Composer, then manually register the service provider and facade alias in config/app.php, and publish the package config. There is no extra.laravel package discovery, so automatic provider registration and facade aliasing will not happen. On a modern stack, expect resolution failures before you reach the registration step.
- Is laravel-fakerino still maintained?
- No. There has been no release since 2015-05-26 and there is no visible triage, security policy, CI, or test suite. Any defect you encounter becomes yours to fix. The package also has zero dependents and only a handful of stars, so there is no ecosystem validation to rely on.
- What is the difference between laravel-fakerino and fakerphp/faker?
- Laravel has shipped fakerphp/faker as a dev dependency for years, alongside the fake() helper, model factories, and database seeders. Laravel Fakerino is a thin wrapper around a separate fake-data generator, adding a service provider, facade, and Artisan commands. It is only justifiable if Fakerino exposes generators, locale data, or determinism semantics that a small custom Faker provider cannot replicate, and that is unverified.
- How do I register the Fakerino service provider and facade in Laravel?
- Because the package predates Laravel package auto-discovery, you must add the Fakerino service provider class to the providers array in config/app.php and add the facade alias to the aliases array. After that, publish the package configuration with vendor:publish so the config-driven providers are available. Refer to the repository for the exact namespaces and config key.
- Can I use laravel-fakerino in production seeders or deploy pipelines?
- The package is intended for development and test data, but seeders are frequently wired into shared deploy pipelines, so dev-only is an assumption worth verifying rather than granting. An unmaintained dependency with near-zero adoption is a supply-chain concern, and dev dependencies still execute in CI with access to secrets and registries. Avoid executing it outside local or isolated test environments.
- What are the best alternatives to laravel-fakerino for fake data in Laravel?
- Use Laravel's native tooling: fakerphp/faker is already a dev dependency, and the fake() helper, model factories, and database seeders cover typical test-data needs with zero added dependency surface. If you need bespoke generators, register a small custom Faker provider instead of adding a wrapper package. Consolidating on native tooling is the recommended path for greenfield and modern applications.
- How do I test code that depends on deterministic laravel-fakerino output?
- Seeded output from this library is an internal implementation detail of an unmaintained package, so tests should not depend on it. Swap seeded Fakerino output for explicit fixtures or use Faker's Generator::seed() with your own provider. Pinning determinism this way prevents test failures if the dependency is removed or replaced.
- What PHP and Laravel versions does laravel-fakerino support?
- Based on the 2015 release date and the original Composer constraints, expect Laravel 5.0/5.1 and PHP 5.4–5.6, with PSR-0 or classmap autoloading and pre-typed code. It is not compatible with PHP 8.x or modern Laravel without a fork and rewrite. Check the exact composer.json constraints for laravel/framework and php before attempting an install.
- Is fakerino/laravel-fakerino a security risk or typosquat target?
- An unmaintained package name with near-zero adoption is a plausible takeover or typosquat target, and dev dependencies still execute in CI with access to secrets and registries. The theoretical blast radius is limited to dev and test, but seeders are often wired into deploy hooks, so verify where the code actually runs. Audit the provenance of the underlying fakerino library, including Packagist ownership, repository history, and license, before considering any use.