You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compiled scripts produce ERR_MODULE_NOT_FOUND exceptions on all of my Windows machines. This seems to have something to do with the paths generated by the compiler and some unexpected behavior from racket/path.
Racks is able to successfully compile the program, but when I try to run the module with Node, it errors out trying to import a file called 'untimecore.js'. I took a look through the compiled version of my racket code, and found this at the top of the file:
import * as $rjs_core from '..\runtime\core.js'; import * as M0 from "..\runtime\kernel.rkt.js"; import * as M1 from "..\collects\racket\private\modbeg.rkt.js";
These aren't the intended paths, because the single back-slashes escape characters in the file names. This is why '..\runtime\core.js' becomes something like ' untimecore.js'.
I have a working theory for why the paths are being generated this way, although I am new to the codebase, so it could easily be something else.
I suspected this was a windows-specific problem, so I went looking for how these import statements are built. I found that the function simple-module-path in util.rkt can call simple-form-path, which in turn calls simplify-path.
According to the documentation, simplify-path will replace / with \ on Windows, so it certainly seems like this might be the culprit. However, this isn't a bug with simplify-path but the intended behavior. It might be necessary to go through the code and differentiate between when a path is going to be used with the file system and when the path string is to be used in compiled javascript code.
Activity
[-]path resolution problems on Windows[/-][+]path resolution fails on Windows[/+]Swap out Symbol.js with PrimitiveSymbol.js
samth commentedon Aug 6, 2021
I think this was closed unintentionally.