Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Logging Bundle Laravel Package

vysokeskoly/logging-bundle

A Laravel/PHP logging bundle from VysokeSkoly that provides reusable configuration and integration for application logging. It helps standardize log handlers and services in Laravel projects, making it easier to set up consistent, maintainable logging across environments.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Ecosystem fit check (do this first): this is a Symfony bundle, not a Laravel package. For any Laravel service in the portfolio, the evaluation ends here — Laravel's config/logging.php channels, Log::withContext(), and Monolog taps cover the same ground with first-party support. For Symfony services, it's a legitimate — if marginal — input.
  • Logging/observability strategy: the bundle's premise ("extended logging options") maps to real product decisions — standardizing structured logs, enriching entries with request/user/correlation-ID context, splitting audit vs. application logs, and routing to multiple sinks. Use it to frame what we need from logging, not what to install.
  • Build vs. buy vs. borrow: at 0 stars, 0 dependents, and no release since 2022-07-18, this is effectively someone's published-in-public internal bundle. Its product value is as a reference implementation — a few hours of reading that can be reimplemented with native Monolog config — not as a dependency.
  • Roadmap input: if a Symfony service has a concrete logging gap (compliance audit trail, multi-tenant log routing, PII redaction), this is a candidate for a timeboxed spike, never for production adoption without a fork-and-own plan.
  • Risk register entry: adopting an unmaintained, zero-adoption package in the logging path creates a hidden maintenance line item — security patches, Symfony major-version upgrades, Monolog API drift — borne entirely by us.

When to Consider This Package

Consider reading (not shipping) it when:

  • You run Symfony (5.x/6.x era, given the 2022 release) and have a narrow logging requirement the default Monolog recipe doesn't cover — custom processors, multi-handler routing, environment-specific formatting.
  • You want a worked example of bundle-level Monolog wiring before writing your own service definitions and compiler passes.
  • Your team can vendor or fork it under MIT with a named owner, a pinned version, and a test that asserts the log output shape you need.

Look elsewhere when:

  • The stack is Laravel. Wrong ecosystem; the DI wiring and bundle conventions buy you nothing.
  • You need a supported dependency. Zero stars, zero dependents, no release in over three years: you are the maintainer on day one.
  • You need observability, not logging. APM, tracing, alerting, and centralized aggregation (Sentry, Datadog, OpenTelemetry) are a different purchase. A logging library moves bytes; it doesn't produce dashboards or SLOs.
  • Native Monolog already covers it. Most "extended logging" asks are 20–50 lines of config plus one or two custom processors.
  • Security/compliance review requires provenance, signed releases, or an active vulnerability-response process.

Minimum bar if someone insists: a ≤1-day spike confirming our Symfony/Monolog versions are supported, plus a written fork-and-own plan approved before anything enters composer.json.

How to Pitch It (Stakeholders)

Executive summary. A small, MIT-licensed Symfony logging bundle — last released July 2022, zero stars, zero dependents, no maintainer activity. It adds handlers and context enrichment beyond Symfony's defaults. Recommendation: do not adopt it as a dependency. An unmaintained package sitting in the logging path is precisely where a security advisory or a framework upgrade turns into an outage, and the cost of owning it exceeds the value it delivers. Treat it as free design input instead: an engineer can read it in a few hours and reproduce anything useful with native Monolog configuration — near-zero cost, zero ongoing dependency.

For engineering. It's a reference, not a dependency. Skim the service definitions and handlers, lift the patterns worth keeping, implement them in our own config with tests. If we later establish we genuinely need this specific behavior, fork it under MIT, pin it, and assign an owner. Until then it stays out of composer.json.

For roadmap. No initiative should be blocked or unblocked by this package. If logging and observability become a real requirement — audit trails, correlation IDs, log-based alerting — that's a story about our own instrumentation plus an APM vendor decision, not a story about this repo.

One correction to flag up front: the brief frames this as a Laravel/PHP package. It's a Symfony bundle. For any Laravel-based product, that distinction alone closes the evaluation.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package