## Problem With the Node engine and `NodeModulesResolver`, every module compile moves the **process-wide** working directory into `node_modules/<package>` (e.g. `node_modules/sass`), and it is never restored, not even on `close()`. The working directory belongs to the whole process, not to a thread. Any other thread in the JVM that opens a relative path is affected, and only some of the time, depending on timing: - `Files.*(Path.of("relative"))`, `FileOutputStream("relative")` - log appenders configured with a relative file - `ProcessBuilder` without `directory()` (the child inherits the moved cwd) `user.dir` does not move, so `Path.of("x").toAbsolutePath()` reports a different directory than the one `Files.exists(Path.of("x"))` actually checks. Failures are sporadic and hard to trace back to jsass. jsass's own file I/O is not affected: `PathBoundary`, `LoadPathsImporter` and the file compile all resolve through `toAbsolutePath()` / `toUri()`, which use `user.dir`. ## Cause `ModuleResolverAdapter.compile` calls `IV8Executor.setResourceName(canonical)`. On a Node runtime, that default method (Javet 6.0.2, bytecode-verified) also sets the globals `__dirname` and `__filename`, the `require()` root, and calls `NodeModuleProcess.setWorkingDirectory(parent)`, i.e. `process.chdir`. With `WebjarModuleResolver` the canonical name is not a real directory, so the chdir fails silently (only logged), which is why that resolver leaves the cwd alone. The V8 engine never does this. ## Why restoring the cwd is not a fix `NodeModuleProcess.setWorkingDirectory` can move the cwd back (verified). But saving and restoring a process-global value is not atomic: with two parallel compiles, the second one may save the already-moved directory and later "restore" the wrong one. The window during the compile would also remain. ## Proposed fix Do what `IV8Executor.setResourceName` does **except** the chdir. Setting only the script origin is not enough, because it also drops the `require()` root that Node's CommonJS loader resolves `node_modules` from: ```java // ModuleResolverAdapter.compile (sketch) final var executor = v8Runtime.getExecutor(source); executor.getV8ScriptOrigin().setResourceName(canonical); if (v8Runtime instanceof NodeRuntime nodeRuntime) { final var file = new File(canonical); final var dir = file.getParentFile(); // null / non-existent for WebjarModuleResolver names nodeRuntime.getGlobalObject().set("__dirname", dir.getAbsolutePath()); nodeRuntime.getGlobalObject().set("__filename", file.getAbsolutePath()); nodeRuntime.getNodeModule(NodeModuleModule.class).setRequireRootDirectory(dir.getAbsoluteFile()); } return executor.compileV8Module(); ``` `__dirname`, `__filename` and the `require()` root are per-runtime state. Only the working directory is process-wide. ### Measured on Javet 6.0.2 A Node runtime runs an ES module named `<repo>/node_modules/sass/probe.mjs` that calls `require('immutable')` and `require('./package.json')`. Each variant ran in its own JVM, started outside the repo: | Variant | `require(...)` | cwd afterwards | |---|---|---| | `setResourceName` (today) | works | moved to `node_modules/sass` | | everything except chdir (sketch above) | works | unchanged | | script origin only | `Cannot find module 'immutable'` | unchanged | So the "origin only" one-liner first considered here would break any module that uses Node's `require()`. jsass's own code path doesn't use `require()` (it loads dart-sass's ESM `sass.default.js` on both engines), so `./gradlew clean check` was green even with the one-liner, but consumer modules may rely on it. The working directory itself is not needed for `node_modules` resolution: Node resolves `require()` from the require root, not from `process.cwd()`. ### Open question Libraries that read `process.cwd()` would now see the application's directory instead of `node_modules/<last compiled package>`. For example, browserslist looks up `.browserslistrc` / `package.json` there when given no path. The application's directory is arguably the more correct answer, but it is a behaviour change worth noting in the changelog. ## Decision: keep open, do before the 6.0 release (low priority) Weighed on 2026-10-06. **Against fixing (why *won't do* was considered):** - Javet documents the chdir as part of closing the gap to native Node.js; it is not a Javet defect. - The fix re-implements three of the four steps of `IV8Executor.setResourceName` by hand. If a later Javet version adds a fifth step, we would not pick it up automatically. - jsass's own I/O is unaffected, the README already warns, and consumers have a way out today: the V8 engine, or `WebjarModuleResolver`. **For fixing (outweighs the above):** - A library that moves the cwd of the whole process hits code that has nothing to do with it (log appenders, `ProcessBuilder`, relative `Files.*`), especially in server applications. A README warning pushes that onto every consumer, and the failures are sporadic and hard to trace. - The fix is about ten lines, uses only public Javet API, and was measured to work. The `require()` regression test below guards against missing a future Javet step. - jsass 6 has no users yet, so the `process.cwd()` behaviour change is free now and breaking after the release. **Rejected alternative:** restoring the cwd after each compile. The cwd is process-global, so save-and-restore is racy across parallel compiles, and other threads still see the moved directory during the compile. ## Side finding dart-sass's CommonJS Node build is not an option on Javet's Node mode. `require('<repo>/node_modules/sass/sass.node.js')` from a bare `NodeRuntime` dies with `EvalError: Code generation from strings disallowed for this context` (in `sass.dart.js`, `new Function`), and the unhandled error takes the JVM down. This was measured on 6.0.2. jsass is unaffected because it loads the ESM `sass.default.js`. ## To do - [ ] Apply the change in `ModuleResolverAdapter.compile` (everything except the chdir, not origin-only) - [ ] Switch the startup-script call in `JavetJsassCompiler` (`executor.setResourceName(startupScript.getResourceName())`) the same way. There the chdir presumably fails silently today; not verified. - [ ] Regression test: compare `/proc/self/cwd` before and after a Node compile with `NodeModulesResolver` (Linux-only; skip elsewhere) - [ ] Regression test: a module loaded through `NodeModulesResolver` on the Node engine can still `require()` a package from `node_modules`. This is the guard the origin-only variant would have failed; today's suite doesn't cover it. - [ ] Replace the cwd warnings in `README.md`, `CHANGELOG.md` and `CLAUDE.md` with a `fix` entry