Use Node.js compile cache

[outslept]

Resolves #177

[Copilot]

Pull Request Overview

This PR enables Node.js compile cache functionality to improve module instantiation performance. The changes add compile cache support in both CommonJS and ESM entry points while disabling it during testing to ensure test environment consistency.

• Adds enableCompileCache calls to both ESM and CommonJS entry points for performance optimization
• Configures test environment to disable compile cache for consistent test results

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
lib/esm.mjs	Imports and enables Node.js compile cache with optional chaining
lib/cjs.cjs	Enables compile cache using require() approach for CommonJS compatibility
.github/workflows/test.yml	Disables compile cache in CI environment for consistent testing

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.24%. Comparing base (60634b7) to head (f53c3a9).
⚠️ Report is 8 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #193      +/-   ##
==========================================
+ Coverage   96.03%   96.24%   +0.20%     
==========================================
  Files          36       36              
  Lines        2143     2155      +12     
  Branches       84       86       +2     
==========================================
+ Hits         2058     2074      +16     
+ Misses         83       81       -2     
+ Partials        2        0       -2     

Flag	Coverage Δ
macos-latest-20	95.77% <83.33%> (-0.17%)	⬇️
macos-latest-22	95.86% <100.00%> (+0.02%)	⬆️
macos-latest-24	95.86% <100.00%> (+0.02%)	⬆️
ubuntu-latest-20	95.39% <83.33%> (-0.07%)	⬇️
ubuntu-latest-22	95.48% <100.00%> (+0.02%)	⬆️
ubuntu-latest-24	95.48% <100.00%> (+0.02%)	⬆️
windows-latest-20	95.41% <83.33%> (-0.07%)	⬇️
windows-latest-22	95.50% <100.00%> (+0.02%)	⬆️
windows-latest-24	95.50% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[outslept]

Ooh. I didn't account for the engines. Give me a minute

[outslept]

This works, but it might not be the cleanest approach. Open to better ideas if anyone has suggestions

[voxpelli]

Since at least I personally often nest calls to npm-run-all2 we maybe need / should do a module.flushCompileCache() before spawning child processes?

[bcomnes]

Any noticeable differences in performance? Refreshing my familiarity with the implications of doing this.

[bcomnes]

Sorry I didn't get to this this week, but its still on my todo.

[outslept]

I was really busy as well. I'll upload before/after on the weekend

[bcomnes]

Look at maybe landing this.

[bcomnes]

The problem with this PR is that by the time the compile cache method calls, the import graph is already open. I could switch to running it before the main import but then I would need t switch to dynamic import which has it OWN slowdowns.

[bcomnes]

I tired to land this in a time box and couldn't come to anything I was convinced was wroth landing:

#221

But I'm open to a working / proven solution if someone else can figure it out.