Utils.log.psr.multi Logger Laravel Package

Product Decisions This Supports

• Multi-destination logging as a product requirement. This package implements a fan-out (composite) PSR-3 logger: every log() call is forwarded to an array of child loggers. That directly supports decisions like "ship the same events to app logs and a customer-facing audit trail," "mirror errors to Sentry plus a file sink," or "run a shadow pipeline during a logging vendor migration."
• Build vs. buy on plumbing. This is a ~50-line class behind an interface you already depend on (PSR-3). The PM decision is rarely "buy this"; it's "do we allow a vendored dependency for glue code, or do we write it ourselves?" Because the surface area is tiny and MIT-licensed, the honest answer is often: copy the pattern into your own codebase and own it. Reserve the package as a decision only if you want zero internal ownership of the code.
• Vendor migration de-risking. The most compelling product use case is a dual-write cutover: wrap the legacy logger and the new logger together, ship, verify parity in production, then remove the old one. This lets you sequence a logging/observability migration independently of feature work instead of a risky flag-day swap.
• Framework-agnostic library and SDK design. If you ship reusable PHP code that must not depend on Laravel's Log facade or Monolog concrete classes, a PSR-3 composite lets downstream consumers inject any set of loggers without your library knowing about them.
• Roadmap signal — deprioritize. With 3 stars, 0 dependents, and an extremely low package score, this should not appear on a roadmap as a strategic dependency. Treat it as an implementation detail, not a platform choice.

When to Consider This Package

Adopt (or copy) only when most of these hold:

• You have two or more existing PSR-3 loggers and need them invoked together without editing call sites.
• The code that logs is framework-agnostic or vendor-neutral and cannot assume Monolog, Laravel, or Symfony concrete classes.
• The requirement is strictly fan-out — no per-sink level filtering, no sampling, no context enrichment, no async/buffered writes, no retry. If you need any of those, this package will not do it and you will end up wrapping it anyway.
• You are comfortable pinning the version and vendoring the source given the maintenance risk.

Look elsewhere — specifically, do not adopt — when:

• You are on Laravel. config/logging.php already ships a stack driver that does exactly this, with per-channel configuration and no third-party code. In a Laravel context this package's value collapses to near zero. Any PM proposal to add it inside a Laravel app should be rejected as redundant.
• You are on Monolog directly. Monolog's handler stack is a native fan-out with far richer routing; a composite logger adds a layer without capability.
• You need structured/contextual logging, trace correlation, or level routing per destination. Out of scope for this package.
• You require a supported dependency with a security response process. Single-maintainer, near-zero-adoption projects do not provide that assurance; you are accepting the code as-is, forever.

How to Pitch It (Stakeholders)

To executives: This is a small utility, not a platform investment. It lets one logging call reach several destinations at once, which is useful for a short window during a logging or audit-trail migration. Cost is effectively zero and the code is MIT-licensed and trivially replaceable, so downside is contained. But it is not a strategic dependency — adoption is in the single digits — so we should either vendor the pattern into our own code or, if we run Laravel, use the built-in stack channel and skip the dependency entirely. Recommendation: do not add it to the architecture; approve it only as a throwaway migration aid, if at all.

To engineering: It is a PSR-3 composite logger — a LoggerInterface that loops over an array of LoggerInterface instances. That is the entire value proposition. On Laravel, the stack channel is the same thing with better ergonomics, so use that. On framework-neutral code, a ~30-line internal class gets you identical behavior with no supply-chain exposure and no upgrade treadmill. If you do pull it in, pin the exact version and expect to own it; the maintenance signal (3 stars, 0 dependents) means we should plan on forking rather than relying on upstream fixes.