ESM files not loading properly on Windows
The current strategy for importing files from CLI (e.g.: jscad ./model.js) first converts the source path argument to absolute (if not absolute already) and then await import()s it
The issue is that import() only accepts URLs and, in Windows, the absolute path of a file is not an URL as it starts with a partition letter (e.g.: c:/path/to/file.js)
The proper way of handling this is with the file:// protocol
This PR converts the absolute path to a file:// URL before calling import()
note: pnpm test failed to run with error Based on your configuration, 7 test files were found, but did not match the CLI arguments: and, as such, no test was run
Regardless, I tested the implementation in Windows and Ubuntu (WSL) and both yielded a proper .stl file
All Submissions:
- [x] Have you followed the guidelines in our Contributing document?
- [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
- [ ] Does your submission pass tests?
@NemoStein Cool. An actual fix to V3. Even more cool!
I'll give this a try but the changes look fine. I'm surprised that the test suite could not be executed. Let's see what the CI does.
Dynamic Import
The module to import from. The evaluation of the specifier is host-specified, but always follows the same algorithm as static import declarations.
Static Import
The module to import from. Only single quoted and double quoted string literals are allowed. The evaluation of the specifier is host-specified. Most hosts align with browsers and resolve the specifiers as URLs relative to the current module URL (see import.meta.url).
Import.meta
import.meta.resolve() is a built-in function defined on the import.meta object of a JavaScript module that resolves a module specifier to a URL using the current module's URL as base.
More tricks are available via import.meta.resolve()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta/resolve
@NemoStein Have you played with import.meta.url and import.meta.resolve()?
@platypii what do you think? these changes seems appropriate but may not be the ultimate solution.