Laravel Contextify Laravel Package

Getting Started

Install the package and publish its config:

composer require faustoff/laravel-contextify
php artisan vendor:publish --tag=contextify-config

Look at config/contextify.php first — it is the whole surface area of the package. Then check the service provider to see where it hooks in (a Monolog processor/Log::withContext call vs. a middleware), because that determines whether the context lands on every channel or only the default stack.

The first use case worth wiring up is request correlation: every log line gets a request ID plus the authenticated user/tenant so you can grep a single request out of a day of output.

// config/contextify.php (shape; confirm keys against the published file)
'enabled' => env('CONTEXTIFY_ENABLED', true),
'context' => [
    'request_id' => true,
    'user_id'    => true,
],

4.4.0 is a non-breaking, additive release. It adds a config flag that fully disables the package. That is the first thing to set in phpunit.xml and in local .env, since it removes context keys from test assertions and makes local logs readable again.

Implementation Patterns

Environment-matrix the enable flag. This is the primary reason 4.4.0 matters:

# .env.testing
CONTEXTIFY_ENABLED=false

# .env (local)
CONTEXTIFY_ENABLED=false

# .env.production
CONTEXTIFY_ENABLED=true

Keep it on in staging and production, off locally and in tests. The "fully disable" wording implies the provider short-circuits registration, so you get zero overhead rather than just empty context — verify that by checking the provider's register()/boot() guard rather than assuming.

Enrich, don't replace. Treat Contextify as the ambient layer (request ID, user, tenant) and use Log::withContext() for per-operation context inside a service or job. Merge order matters — the more specific call usually wins, but confirm which side wins when both set the same key, or you will silently lose job-level data.

Propagate into queued jobs. The request context dies with the request, so a job that logs will either have no context or (worse) inherit stale context from a long-lived worker. Push the correlation ID into the job payload at dispatch time and re-establish it in handle():

dispatch(new ProcessOrder($order, requestId: Context::get('request_id')));

Pair with a UI. Context keys are only worth the bytes if something reads them — Sentry/Flare tags, Telescope, or a structured log viewer. A request ID in a plain-text log file is nearly useless; in JSON it is a join key.

Testing. With the flag off in phpunit.xml you can assert on exact log content without stripping context keys. If you do want to test context propagation, flip the flag on in a dedicated test case and use Log::spy() to inspect the context array rather than the formatted string.

Gotchas and Tips

• Long-running workers leak context. Octane, Horizon, and queue workers reuse the process across requests/jobs. If the package sets context on boot, the first request's user/tenant sticks to every subsequent one — a genuine data-leak vector, not just a logging bug. Confirm there is a per-request reset (middleware terminate, a JobProcessing listener) before shipping.
• Config caching. After changing the flag: php artisan config:clear (or rebuild the cache). A config-cached deploy will happily ignore your .env change and leave the package enabled.
• Disabling may not undo registration. If the provider registers a Monolog processor before checking the flag, disabling gives you a no-op processor rather than no processor. Cheap, but not free — worth a one-time check if you are disabling for performance on a hot path.
• Sensitive fields. User IDs are fine; emails, tokens, and request bodies are not. Check whether the default context includes headers or the session, and redact before this reaches a third-party log sink (retention and GDPR implications).
• Serialization cost. Context is serialized on every log call. In a tight loop that logs thousands of lines, a rich context array is measurable overhead — one more argument for the new disable flag in high-throughput console commands.
• Extension points. The context array is the seam: a custom resolver/processor injected into the config is the clean way to add tenant or trace IDs, rather than reaching into the package internals or appending to the Monolog record by hand.
• Debugging empty context. Order of triage: is the flag actually true at runtime (config('contextify.enabled')), is the config cached, and is the channel you are logging to one the package instruments (custom stack/daily channels sometimes sit outside the default wiring).