fix: fallback for ENAMETOOLONG when evaluating esm#429
Conversation
Use a temp file instead of a data URL for ESM fallback evaluation. This avoids ENAMETOOLONG errors on OS/filesystem combinations with strict NAME_MAX limits (e.g., encrypted home dirs, macOS). Opt-in via `esmResolveTempFile: true` or `JITI_ESM_RESOLVE_TEMP_FILE=true`. Co-authored-by: Mario Zechner <badlogicgames@gmail.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThis PR adds optional temp-file-based ESM evaluation as a fallback when ChangesESM Temp-File Fallback Support
Sequence DiagramN/A — This PR refactors internal fallback logic within a single evaluation helper without introducing new inter-component interactions that would benefit from visualization. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
esmResolveTempFile option for ESM fallbackENAMETOOLONG when evaluating esm
Dynamic `import()` rejects raw absolute paths like `C:\...\foo.mjs` on Windows — must be a `file://` URL.
This PR makes the ESM evaluation fallback path tolerate filesystems with strict
NAME_MAXlimits (e.g. ecryptfs-encrypted home dirs on Linux, some macOS configurations) where the existingdata:URL approach fails withENAMETOOLONGonce the base64-encoded source grows past the limit.data:URL as before, and automatically falls back to writing a temp file and importing it natively if — and only if — the import rejects withENAMETOOLONG. Users on affected filesystems get the fix transparently.esmEvalTempFile: true(env:JITI_ESM_EVAL_TEMP_FILE=true): skips thedata:URL attempt entirely and goes straight to the temp-file path. Useful when you know the data-URL path will fail and want to avoid the wasted attempt.The temp file is written to
{TMP_DIR}/jiti-esm/<name>-<timestamp>-<rand>.mjsandunlinked after import.import.meta.url/dirname/filenameare unaffected — jiti's babel plugins already rewrite them to the original location, so user code doesn't see the temp path.This only affects the ESM fallback path that handles cases like
import.meta.<custom>(wherevm.runInThisContextrejects with aSyntaxError). The common path is unchanged.Context
Based on work by @badlogic:
Changes
src/eval.ts—esmEval()gains a temp-file branch with auto-fallback onENAMETOOLONG; cleans up the temp file in.finallysrc/options.ts+lib/types.d.ts— newesmEvalTempFileoption /JITI_ESM_EVAL_TEMP_FILEenv var (defaultfalse)test/esm-temp-file.test.ts— covers the opt-in path, the large-file scenario, the[tempfile]debug trace, and a regression test ensuring a user-thrownENAMETOOLONGdoes not double-execute via the fallback