- How do I install vierbergenlars/php-semver in a Laravel project?
- Install it with composer require vierbergenlars/php-semver. It is a plain PSR-4 library, so once Composer's autoloader is regenerated the classes are available anywhere in your Laravel application without registering a service provider or publishing configuration. Most teams wrap it behind a small internal service or helper so the rest of the codebase never references the vendor namespace directly.
- Does vierbergenlars/php-semver support Laravel 10 and Laravel 11?
- The package has no framework coupling, so it installs and runs in Laravel 8 through 11 as long as your PHP version satisfies its Composer constraint. Because the upstream repository is archived and the last release was in May 2023, verify that the pinned version installs and passes your test suite on both your PHP floor and ceiling before committing to it.
- Do I need a service provider or config file for this package?
- No. There is no service provider, facade, config file, migration or published asset; the library is a set of standalone classes reached through Composer's autoloader. That also means nothing is bound into the container, so you resolve or inject it yourself if you want it mockable in tests.
- What is the difference between vierbergenlars/php-semver and composer/semver?
- Both parse Semantic Versioning strings and evaluate constraints such as ^1.2, ~1.4.0 and ranges. composer/semver is the de facto standard, is what Composer itself uses, is actively maintained and is usually already present transitively in Composer-adjacent tooling, whereas vierbergenlars/php-semver is archived. Mixing two parsers in one codebase also risks two subtly different definitions of what satisfies a constraint, so pick one.
- Which version constraint syntaxes can I evaluate with it?
- It supports the common Composer-style expressions: exact versions, comparison operators such as >=2.0 <3.0, caret constraints such as ^1.2, tilde constraints such as ~2.0, wildcards like 1.2.*, and combinations and ranges. That covers typical plugin and module compatibility gates plus update checks. If the same strings are also fed to Composer, test that both parsers agree on edge cases instead of assuming identical grammar.
- How do I compare two version strings in PHP with this library?
- Parse each string into a version object and compare them, or use the SemVer helper methods such as gt, lt, gte, lte and eq for precedence checks, plus a satisfies-style call to test a version against a constraint. Build metadata is ignored for precedence, so 1.0.0+build.1 and 1.0.0 compare equal. Sorting a list of releases then becomes a usort over parsed objects.
- What happens when I pass an invalid version or constraint string?
- Malformed input raises an exception rather than returning false, and common causes include leading zeros, a stray v prefix and truncated constraints. In a request path an uncaught exception becomes a 500, so validate or catch around the parse call whenever the string comes from a plugin manifest, API caller or other untrusted source. In batch loops, record the failure per item so one bad plugin does not abort the whole run.
- Does it handle prerelease versions and build metadata correctly?
- It implements SemVer 2.0.0 precedence, so 1.0.0-alpha sorts before 1.0.0-alpha.1, which sorts before 1.0.0, and build metadata such as +sha.abc is ignored when comparing. Prerelease handling inside constraint matching is the usual source of surprises, so write tests for the policy you actually want, for example whether an update check should ever offer a beta to a stable install.
- Is it safe to depend on an archived package with an unclear license in production?
- Two issues need sign-off first: upstream is archived with no CVE response or PHP 8.4-plus compatibility work, and GitHub reports the license as NOASSERTION even though composer.json has historically declared MIT. That means obtaining legal clearance or forking and vendoring the code with an explicit, verified license file. You should also name an internal owner and budget maintenance time, because adopting it means owning it.
- Can I use it for a Laravel validation rule or Eloquent cast on a version column?
- Yes, and that is a common use: wrap the parse call in a try/catch inside a custom rule and fail validation instead of letting the exception escape, then reuse the same parser in an Eloquent cast or accessor so version columns are validated and compared consistently. Keep constraint strings from users and third parties behind that validation layer. If you only need to validate and compare in one place, a short internal helper may be cheaper than the dependency.