Jlog Bundle Laravel Package

Product Decisions This Supports

• Framework-fit gate for the dependency backlog: This package surfaces a recurring PM decision — whether a candidate library actually targets our stack. johndodev/jlog-bundle is a Symfony bundle (Twig extension + JS asset, Symfony DI config tree), not a Laravel package. Any roadmap item that assumed "drop-in Laravel logging" should be corrected at the triage stage rather than after engineering effort. Treat this as a portfolio hygiene input, not a feature enabler.
• Build vs. buy vs. port decision: The realistic product path here is port, not adopt. The idea (emit server-side values to the browser console instead of dd(), preserving session/CSRF/JS state during multi-step form and POST-handler debugging) is genuinely useful and maps to a real developer-experience pain point. The dependency is not. That is a textbook "reimplement ~40 lines in-house" call, and it should be recorded as such so the same evaluation isn't repeated next quarter.
• Developer-experience roadmap input: If the team is investing in DX tooling (local/staging-only debugging aids, faster iteration on forms and middleware), this package is a useful reference specimen for shaping the spec: what the helper should do, where it should be gated (environment + config flag), and how the asset should be delivered (Vite, not a published bundle asset). It informs a spec; it does not become the dependency.
• Dependency policy calibration: Zero stars, zero dependents, no auto-discovery, no release-cadence signal — a clean worked example for setting the minimum bar (named maintainer, CI matrix, recent commits, documented framework target). Use it to make the allowlist policy concrete rather than abstract.
• Explicitly not a roadmap commitment: Nothing here justifies a roadmap slot, budget, or production surface. If pursued at all, it is a timeboxed spike or an internal port, both of which are engineering-velocity line items, not product features.
• Risk/exit framing: MIT licensing means fork-and-own is legally trivial, but ownership must be assigned. The PM decision is not "adopt or not" but "who owns this if we keep it, and what is the rollback?"

When to Consider This Package

Consider it only under narrow, specific conditions:

• A Symfony component exists in our estate (sidecar admin app, internal tool, legacy service). In that context the bundle is directly installable, and the cost/benefit is normal open-source evaluation. For a Laravel-only codebase, this criterion fails and the conversation should end there.
• A short, timeboxed spike (1–2 days) confirms the debugging-without-interrupting-request workflow is a real, repeated pain point — e.g., teams routinely losing session state, CSRF tokens, or JS state to dd() in multi-step forms, POST handlers, or middleware.
• The need is local/staging-only developer diagnostics, behind a config flag and an environment check. Small blast radius if the package stalls or is removed.
• You are willing to fork and own it, or (preferably) port the pattern into an in-house service provider + Blade directive + Vite asset, with an assigned internal owner either way.
• A source read-through is complete: bundle class (DI alias, config tree), Resources/config/services.* (what's injectable), the Twig extension (public API surface), and Resources/public/js/* (jQuery dependency? payload serialization?).

Look elsewhere — or, more accurately, build in-house — when:

• The application is Laravel. Laravel cannot register a Symfony bundle's compiler passes or Twig extension. Porting is ~40 lines: a JLogServiceProvider singleton, a Blade::directive('jlog', ...), and a Vite-shipped JS asset. That is cheaper than any adapter layer.
• The need is production logging or observability (audit trails, compliance, incident forensics, PII-safe logs). This package is a debugging aid, not a logging stack; Laravel's Monolog stack (Log facade, channels, daily/stack drivers) is the correct answer.
• Supply-chain policy is strict — an unvetted, near-zero-visibility package with Packagist publish access is an attack surface. Pin exact versions or vendor it if it is used at all.
• Framework fit is undocumented or ambiguous. A -bundle suffix on a Laravel request is itself a disqualifier: naming tells you the target ecosystem. Do not assume fit from the package name.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony bundle for developer debugging — it lets engineers inspect server-side values in the browser console without interrupting the page request. It is not a logging or observability platform, it does not fit our Laravel application, and it has effectively no external adoption (zero stars, zero dependents, no maintenance signal). Recommendation: no budget, no roadmap slot, no runtime dependency. The underlying idea — a config-gated, environment-restricted debug helper — is worth roughly a day of engineering to port natively if the team confirms the pain point. Total ask: about one engineer-day, not a procurement or a committed feature. The real product decision it informs is our dependency-allowlist bar, which is worth having written down once.

To engineering: Do not install this into the Laravel app — the Symfony bundle machinery (compiler passes, Twig extension) will not register. Treat it as a reference implementation: read the bundle class for config-tree shape, the services config for what should be injectable, the Twig extension for the public API surface, and the JS asset for payload serialization and jQuery dependencies. Then port the pattern in ~40 lines: a singleton gated on config('jlog.enabled') and app()->environment('local','staging'), a Blade::directive('jlog', ...), and a Vite-delivered JS logger. Two hard requirements on the port: it must be off by default and impossible to enable in production, and it must not leak into committed output — gate the script tag, and scrub any values that could carry secrets or PII. If a Symfony sidecar ever exists in the estate, the bundle becomes a normal, low-stakes evaluation there — but for this codebase, port, don't adopt, and record the decision so we don't re-litigate it.