fix(logger): actually verify pino-pretty is installed before configuring it#138
Merged
Merged
Conversation
…ing it
The existing `try` block around the `transport = { target: 'pino-pretty', … }`
assignment was a no-op. Object-literal construction doesn't throw —
pino lazy-resolves the `target` module the first time the logger emits,
which means a deployment that sets `LOG_PRETTY=1` without `pino-pretty`
on disk would crash on first log line (often during DB-init logging,
seconds into startup) with a confusing pino-internal error. The
"fall through to JSON output" path the comment promised never ran.
Insert an explicit `require.resolve('pino-pretty')` inside the try
block. `require.resolve` synchronously throws MODULE_NOT_FOUND when
the module is missing, which lets the catch fire and the transport
stay undefined — so pino falls through to default JSON output, which
is what the operator should see when they ask for pretty output but
haven't installed the (optional) dev dependency.
No test added because exercising the missing-pino-pretty branch
requires either a subprocess spawn (heavyweight) or filesystem
mocking that interacts with Node's module loader (brittle); the
existing logger tests verify the loaded-module case and continue to
pass. The change is a behavior-correctness fix that brings the code
in line with what the comment already promised.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #137.
Summary
The existing
tryblock around thetransport = { target: 'pino-pretty', … }assignment was a no-op — object-literal construction doesn't throw. Pino lazy-resolves thetargetmodule the first time the logger emits, so a deployment that setsLOG_PRETTY=1withoutpino-prettyon disk crashes on first log line (often during DB init seconds into startup) with a confusing pino-internal error. The "fall through to JSON output" path the comment promised never ran.Insert an explicit
require.resolve('pino-pretty')inside the try block.require.resolvesynchronously throwsMODULE_NOT_FOUNDwhen the module is missing, so the catch fires cleanly andtransportstays undefined — pino then falls through to default JSON output, matching the "pino-pretty is NOT a required dependency" comment at the top of the file.Test plan
npm run lint— cleannpm test— 495 passed, 15 skipped (no test count change; existing logger tests pin the loaded-module case)Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/