- Can I use mattsches/version-eye-bundle in a Laravel application?
- No. Despite showing up in Composer dependency searches, this is a Symfony2 bundle, not a Laravel package. It ships a Bundle subclass, a DependencyInjection Extension, a Configuration tree, and XML/YAML service wiring, none of which have any analogue in Laravel's service provider and config repository model. There is no auto-discovery, no publishable config, and no facade. It cannot be installed into a modern Laravel app because its constraints conflict with the Symfony components Laravel already ships.
- What does the version-eye console command actually do?
- It scans the Composer packages installed in your project and reports which ones have newer releases available. Output shows the currently installed version next to the latest version published for each package, so you can spot outdated dependencies without leaving the terminal. It is a read-only reporting command with no update or write behaviour. The version data comes from a remote VersionEye API call rather than from Packagist directly.
- Is the VersionEye API still available for this bundle to call?
- No. VersionEye ceased operations in 2018, so the remote endpoint this bundle talks to no longer responds. Even a perfectly working installation will fail at the HTTP call stage. That means the package's entire value proposition is gone, regardless of how clean your Symfony or Laravel environment is. Any revival requires re-pointing the client at a live data source such as Packagist, deps.dev, or OSV.dev.
- What PHP, Symfony, and Guzzle versions does this bundle require?
- The bundle targets the Symfony 2.x era with Guzzle 3, and the code is written in PHP 5-era syntax without strict types. All three of those stacks are end-of-life: Symfony 2 and Guzzle 3 no longer receive security fixes, and Guzzle 3 carries known CVEs. Modern Laravel applications ship Symfony 5, 6, or 7 components and Guzzle 7, so Composer will refuse to resolve the upstream package at all. Expect deprecated constructs and PSR-0-style naming if you read the source.
- How do I install and register mattsches/version-eye-bundle in Symfony?
- In a legacy Symfony 2 application you would require it via Composer and then register the bundle in AppKernel.php, supplying your VersionEye API credentials through the bundle configuration tree. The command then becomes available through the Symfony console. None of these steps transfer to Laravel, which is why installation instructions for Symfony are not useful to Laravel developers. Given the dead API, installing it even in a legacy Symfony app no longer produces working output.
- Can I port this Symfony bundle to Laravel as a service provider?
- You can lift the HTTP client class out and wrap it in a service provider, but the result is a rewrite rather than a port. The Bundle, Extension, and Configuration classes get deleted entirely, Guzzle 3 must be replaced by Laravel's Http facade or Guzzle 7, and the hardcoded base URL becomes a config entry. You would also need a new data source because the original endpoint is dead. At that point the upstream package contributes almost nothing beyond a reference implementation, so treat it as vendored sample code rather than a dependency.
- Does this bundle detect security vulnerabilities or CVEs in dependencies?
- No. It only compares the versions you have installed against the latest published releases, which is an outdatedness signal, not a vulnerability scan. A package can be current and still vulnerable, and a package can be several versions behind without any known advisory. For real security coverage in Laravel, use composer audit, the FriendsOfPHP security-advisories database, or Roave Security Advisories as a dev dependency. Modern tools such as Dependabot and OSV.dev cover both angles in one place.
- Is mattsches/version-eye-bundle still maintained?
- No. The last release was 2016-08-16, it has a single maintainer, and there is no security response path. It has roughly 11 stars and zero dependents, which means no field validation, no community bug reports, and no downstream patches you could borrow. Because the upstream service it depends on is also gone, there is no realistic maintenance scenario. Treat it as abandoned code that is useful only as a reference.
- What Laravel-native alternatives check for outdated Composer packages?
- Start with composer outdated --direct, which requires no extra package and lists installed versus latest versions straight from Packagist. For automation, GitHub Dependabot, GitLab dependency scanning, and Renovate all open pull requests for Laravel projects out of the box. For richer reporting, deps.dev, Libraries.io, and OSV.dev offer APIs you can call from a scheduled job. If you need in-app visibility, a small custom command around the Packagist API is a few dozen lines and avoids the dead VersionEye endpoint entirely.
- How do I run outdated dependency checks in a Laravel CI pipeline?
- Add a step that runs composer outdated --direct --strict and let a non-zero exit code fail the build, or use composer audit for the security dimension. Dependabot and Renovate are usually a better fit because they also raise the update pull request rather than just reporting. Whatever you choose, avoid synchronous third-party HTTP inside a request cycle; run checks in a scheduled job or queue worker with caching and retry backoff. That design constraint is exactly where the old Symfony bundle falls short for modern Laravel use.