Log Laravel Package

Product Decisions This Supports

• Logging abstraction standardization (build vs. buy): yiisoft/log is a thin, PSR-3-compliant logger. When the question is "do we write our own logging interface wrapper or adopt a standards-compliant one," this is the buy-side answer with near-zero integration cost — a few hundred lines of code versus weeks of internal design, review, and maintenance.
• Framework-agnostic library/SDK strategy: if we publish PHP packages (internal shared libraries, partner SDKs, open-source components) that must not drag Laravel, Symfony, or Monolog concrete classes into a consumer's dependency tree, a PSR-3-only logger is the correct dependency floor. This decision protects downstream adopters and lowers integration friction.
• Vendor lock-in reduction on observability: PSR-3 is the contract, not the implementation. Choosing a PSR-3 logger at the seam means swapping the underlying transport (file, stderr, syslog, a hosted observability backend) is a configuration change rather than a refactor — a hedge against future observability vendor decisions.
• Roadmap input — multi-target and structured logging: the package supports message/context separation per PSR-3, which enables structured fields (request ID, tenant, user, trace ID) without bespoke formatting code. That is a prerequisite for correlation across services and for later log-aggregation work.
• Compliance and audit-trail scoping: BSD-3-Clause is permissive and commercially safe; combined with a minimal dependency surface, it de-risks legal/procurement review for shipping in client-facing or redistributed software.
• Use cases: plain-PHP services and CLI tools; Yii3 applications; microservices or workers outside a full framework; shared packages consumed by heterogeneous PHP teams; prototypes where pulling in a full logging stack is disproportionate.

When to Consider This Package

Adopt when:

• You are writing code that must run under multiple frameworks or none at all, and PSR-3 is the only logging contract you want to commit to.
• You are already in the Yii ecosystem (Yii3) and want the first-party, maintainer-aligned implementation rather than a bolted-on third-party library.
• Your requirements are simple and stable: level-based filtering, message interpolation, context passthrough, and pluggable output targets. You do not need a catalog of prebuilt handlers.
• Dependency minimalism matters — SBOM size, license review, or supply-chain policy favors a small, permissively licensed library with no exotic extensions.
• You want an implementation you can swap out later without touching call sites.

Look elsewhere when:

• The product is a Laravel application. Laravel binds its Log facade to Monolog out of the box. Replacing that means rebinding the log manager and forfeiting the default channel configuration, daily-file rotation, and the logging.php config ergonomics. The benefit is small and the integration friction is real.
• You need a rich handler ecosystem out of the box — Slack, Sentry, CloudWatch, Loggly, Graylog, Papertrail, rotating and buffered handlers. Monolog already owns this space; re-implementing it here is wasted effort.
• You need high-throughput or async logging (buffered/batched writes, non-blocking I/O). This package is not positioned for that; adding it is a build project.
• Community support is a hard requirement. At roughly 43 stars, this is a low-adoption library. Expect to be a first-line debugger, and expect fewer Stack Overflow answers, blog posts, and third-party tutorials. Mitigate by pinning versions and by keeping usage confined behind a PSR-3 interface so replacement is cheap.
• You need active feature velocity or vendor-backed SLAs. Maintainer responsiveness may be excellent, but it is not contractual.

Key risks to log explicitly: low adoption (43 stars) implies thin community knowledge and a concentration of maintainership; the effective mitigation is that PSR-3 confinement makes exit cost near zero, so the downside is bounded. Note also that "PSR-3 compatible" is a low bar — verify that context handling, exception rendering, and level filtering behave as your team expects before standardizing.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small, permissively licensed (BSD-3) PHP logging component that implements PSR-3, the industry-standard logging interface. The strategic value is not the code — it is optionality. Committing to a standards contract at the logging boundary means we can change logging backends, or change frameworks, without rewriting call sites. The cost is negligible and the license carries no commercial restrictions. The principle risk is that the library has limited community adoption, which we contain by isolating it behind the standard interface so it can be replaced in days, not quarters. Recommendation: adopt where we are writing framework-agnostic code; do not force it into the Laravel application, where the default stack already does this job well.

For engineering: Treat this as a PSR-3 implementation, not a logging platform. It gives you level filtering, message interpolation, and context passthrough with essentially no dependency surface — trivially unit-testable and trivial to mock. Standard practice: type-hint Psr\Log\LoggerInterface everywhere, inject the concrete logger only at the composition root, and never let Yiisoft\Log\* types leak into domain code. That single rule makes the adoption decision reversible. Two things to verify in a spike before we commit: exception-to-context rendering behavior and how handlers are composed for our multi-target needs (file plus stderr plus a future aggregator). If we need a large handler catalog, buffered writes, or deep Laravel/Symfony integration, Monolog is the pragmatic choice and this package is not worth the fight.