refactor: improve `logFn` types
resolves #351
Since logObj.date must be of type Date, we should enforce stricter parameter types to prevent runtime errors.
In addition to formatDate requiring the Date type, we also use the Date internally:
https://github.com/unjs/consola/blob/5ac9ed76b021c9ffc768f0727355238056aabeb1/src/consola.ts#L418-L422
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 29.30%. Comparing base (
24c98ce) to head (e9268d0). Report is 57 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #372 +/- ##
===========================================
- Coverage 61.08% 29.30% -31.78%
===========================================
Files 13 43 +30
Lines 1380 1723 +343
Branches 58 87 +29
===========================================
- Hits 843 505 -338
- Misses 537 1192 +655
- Partials 0 26 +26
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
Thanks for PR but it seems type only getting stricter we need to fix runtime support somehow to not wrongly detect { date } as logobj.
Do you mean a stricter isLogObj function check, requiring date to be Date if it exists?
https://github.com/unjs/consola/blob/5ac9ed76b021c9ffc768f0727355238056aabeb1/src/utils/log.ts#L16-L33
Yes exactly! (types couldbe lean as is IMO. feel free to make another PR for runtime fix)
#379 makes the runtime check more strict.
Personally, I prefer stricter types that align with runtime behavior. This can improve DX 😃
(I've also simplified the LogParam<T> for better understanding and easier maintenance)