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.
The impetus for this PR was me starting to work on a suggestion PR for #445. When I got into the code, I decided that we have long ago outgrown the structure of the codebase as I created it when splitting this module out of the core Pino module. Basically, it has grown in a difficult to navigate mess with everything crammed into a few large files.
I have more that I intend to do, but I think this PR has become large enough as it is. So I'm halting my work until we make a decision on this (🤞 that means it's merged).
This PR is not yet complete as of commit 065fc99. I just want to put it up to show the following:
As of that commit, the "utils" file has been split out into a directory,
lib/utils/
. This directory has one file per utility function and a corresponding test file for each utility function file. It also updates thetap
configuration to include a coverage map. The result is that we are not actually covering at 100% as we assumed:Coverage Report
Okay, so that's not quite true. The difference is that some of the coverage comes through the factory function tests. With the restructure we have 1:1 test to code and we can see the gaps. it is my opinion that we should be able to recognize that file Y covers code X. Prior to this PR, one has to dig through a lot of code to find where something might be covering the code in question. As an example, in order to properly cover a case in
handle-custom-levels-opts
andhandle-custom-levels-names-opts
I had to read back through the git blame and learn what code was added to cover an odd branch.After rebasing this on #451, I get numbers like this for the changes in this PR:
So, roughly no change in performance by splitting the functions out into their own files/scopes.