Consider enabling Node.js module compile cache

[outslept]

Enabling the Node.js compile cache should reduce startup overhead, could shave tens of milliseconds off repeated runs after the first. The benefit for lint-staged is most noticeable for short "no-op" or small-change commits; for linter-heavy runs it’s negligible.

Docs: https://nodejs.org/api/module.html#moduleenablecompilecachecachedir

[iiroj]

Hello,

I don't think "tens of milliseconds" is a worthwhile improvement to enable an experimental feature.

Can you point to some projects using this feature successfully? I'm not familiar with it yet.

[outslept]

Here are two notable adoptions:

• ESLint: perf: using Node.js compile cache eslint/eslint#19012
• TypeScript: Enable Node.js/v8 compile caching via entrypoint shims microsoft/TypeScript#59720

Both PRs have before/after timings. For lint-staged specifically, I’d expect a smaller win because most wall time is in spawning linters/formatters and git calls - the compile cache only trims Node’s own module parse/compile cost. It’s still should be helpful for small enough operations, where startup dominates.

[iiroj]

Ok sounds good, do you want to open a PR? As long as it's called conditionally or something so it doesn't explode on older Node.js. I just added 20.17.0 to CI since it's the oldest supported version.

[iiroj]

In a very unscientific test I tried this without any staged changes by simply running on my local M4 Pro machine:

time node bin/lint-staged.js

results are:

With compile cache:

0.098
0.099
0.098
0.098
0.097
0.098
0.088
0.095
0.087
0.086
0.092
0.088
0.086
0.089

avg 0.092785714285714

Without:

0.094
0.099
0.093
0.092
0.090
0.088
0.089
0.089
0.084
0.086
0.086
0.087
0.086
0.082

avg 0.088928571428571

So maybe leave this for later.

[outslept]

Ahh.. That's unfortunate. I think this is safe to close