Weave Code
Os Laravel Package
php-standard-library/os
Detect the operating system in a type-safe way using PHP Standard Library's OperatingSystemFamily enum. Part opf the php-standard-library project, this small package gives you a clean, enum-based API for OS detection instead of fragile string checks.
Type-safe operating system detection via OperatingSystemFamily enum
Frequently asked questions about Os
- What is php-standard-library/os and what does it actually do?
- It is a small package that resolves the host operating system into an OperatingSystemFamily enum case from the PHP Standard Library project. It replaces fragile string sniffing such as str_contains(PHP_OS, 'WIN') or php_uname() parsing with a typed value that PHPStan and IDEs can reason about. The scope is deliberately narrow: OS detection is a primitive, not a subsystem, so expect roughly 20 to 40 lines of real logic rather than a framework.
- How do I install php-standard-library/os in a Laravel application?
- Install it with composer require php-standard-library/os; the package is PSR-4 autoloaded and has no transitive dependencies beyond the PHP version requirement, so friction is low. The architectural friction is that OperatingSystemFamily::current() is static and therefore not injectable or mockable. In a Laravel codebase, bind your own OsDetector interface in the service container and put the single adapter implementation that calls the package behind it.
- Which PHP and Laravel versions does php-standard-library/os support?
- The package requires PHP 8.1 or newer because it relies on native enums, and it has no Laravel-specific integration or service provider. Laravel 10 and 11 applications running PHP 8.2 or later satisfy the requirement comfortably. There is no documented Laravel version constraint beyond the underlying PHP requirement, so verify against your platform before pinning.
- How do I use OperatingSystemFamily to detect the operating system in Laravel?
- The entry point is the static OperatingSystemFamily::current(), which returns an enum case you compare against the enum cases rather than against strings. In Laravel, wrap that call in an OsDetector interface with one adapter implementation and resolve it from the container so controllers, Artisan commands, and filesystem or permission logic depend on your abstraction. That keeps the package as an implementation detail and makes swapping it later a one-file change.
- Can I mock OperatingSystemFamily::current() in unit tests?
- No, a static enum method is not injectable and cannot be mocked cleanly in a standard test suite. Define an OsDetector interface with a family() method, bind an adapter implementation in a service provider, and fake that binding in your tests. This wrapper is the real integration deliverable, and the package itself becomes an untested implementation detail inside it.
- Which operating systems does the OperatingSystemFamily enum cover, and what happens on an unrecognized platform?
- The repository does not publish a full case list or a documented behavior for unrecognized platforms, so verify this before adoption. The key question is whether current() throws, returns null, or falls back to a generic Unknown case, because a thrown exception during bootstrap is an outage while a silent Unknown is a latent bug. Niche targets such as WSL, FreeBSD, and illumos variants are the ones most likely to be unmodeled, and WSL in particular reports a Linux kernel even when developers expect Windows-adjacent behavior.
- Can I add custom cases to the OperatingSystemFamily enum for niche platforms?
- No, PHP enums are closed and cannot be extended, so adding a case to the upstream enum from your application is not technically possible. If current() does not model a platform you care about, your options are to fork the package, wrap and map its result into your own enum, or fall back to raw detection for that case. This materially raises the cost of the just-adopt-it path and is worth confirming before you commit.
- Is php-standard-library/os safe to use in production given its low adoption?
- Validation signals are effectively zero: the repository has no stars, no dependents, and no documented third-party production usage. The MIT license protects against legal lock-in but not against abandonment, and per-package release notes are stubs pointing at the monorepo, so you cannot determine what changed in OS detection between versions. Pin an exact version, review the upstream monorepo tags, and keep the package behind your own interface so replacement stays cheap.
- Which version of php-standard-library/os should I require?
- The guidance is contradictory: release notes imply a 6.x line while integration notes reference ^1.0, so the documentation may be stale or the versioning unstable. Do a pin-and-verify pass by inspecting the actual tags in the repository and the monorepo before choosing a constraint. Requiring an exact version and locking it prevents a quiet behavioral change from reaching production.
- Should I use this package or write my own OS detection in Laravel?
- If you have under roughly 15 raw OS checks, an in-house enum is cheaper on every axis: no added supply-chain surface and native handling of niche platforms. Adoption costs about a day for the wrapper plus tests, whereas in-house costs one to two days and removes upgrade risk entirely. Either way, define an OsDetector interface so the decision is reversible in a single file.
Weaver
How can I help you explore Laravel packages today?