Should Knip run in pre-commit?
This lesson preview is part of the Bundling and Automation in Monorepos course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to Bundling and Automation in Monorepos, plus 90+ \newline books, guides and courses with the \newline Pro subscription.
[00:00 - 00:18] In the previous lesson, we added Knip to our pre-commit checks in lefthook.yaml, but we never explored what the performance impact of this additional check is. Let's quickly fix this oversight. I'm going to benchmark by running its binary directly and measuring it with hyperfine.
[00:19 - 00:34] I'm going to run "hyperfine ./node_modules/.bin/knip". And we're going to see that even on this small example Monorepo, it takes about 900 milliseconds.
[00:35 - 00:53] In larger codebases, Knip can take anywhere from 10 to 20s, and that may be too slow for some teams to tolerate in a pre-commit workflow. How your team handles this depends on whether they're comfortable spending extra time during every commit to catch potential issues.
[00:54 - 01:06] Some teams don't mind waiting, while others prefer to rely on continuous integration to identify problems. The difference is in the timing of when you learned about those problems.
[01:07 - 01:12] Do you learn about them quicker in your commit flow? But you need to wait more for each commit.
[01:13 - 01:28] Or do you wait for CI to run to know if there is a problem? In our example, we will leave Knip in the pre-commit checks for now, but we'll also discuss how to offload some extensive tests to CI later in the course.