wasmoon
wasmoon copied to clipboard
ceifa
Missing PATH and PATH_FS for FS operations
I have noticed that, differently from Pyodide and MicroPython for WASM, where some of these utilities are hidden behind a _module field, I can't seem to find these commonly available exports from Emscripten in here, so that I need to manually provide a PATH_FS.resolve(path) functionality and a PATH.dirname(path) too.
On top of that, it'd be lovely to have a FS.mkdirTree(pathDir) utility too, but that's something I can eventually workaround as long as previous utilities are available.
If there is no interest in exposing more paths related utilities, please let me know so I can think about a better solution (but we know user-land code for foreign FS can easily fail in various circumstances).
Thank you!
@ceifa that's what pyodide does ... as a user, I don't feel too confident in using _ prefixed utilities as that's screaming for a breaking thing in the near future but in pyodide case they said it's stable anyway, 'cause used internally too. Your call :+1:
Hey, just to expand on this more - my application relies on certain FS operations (like chdir, stat) which would need JavaScript access to the Module.FS. I am not opposed to providing a higher-level interface, but I think it might be betterto start by exposing FS. As for ENV, it could be added to LuaFactory.
In addition to existing FS code, I think it would be great if all the filesystems are included, like NODEFS, IDBFS and WORKERFS. Tree-shaking should keep the bundle size relatively light if you didn't use any of the filesystems.
@takase1121
I am not opposed to providing a higher-level interface, but I think it might be betterto start by exposing FS.
my idea here was to just expose that Emscripten FS as it is, among PATH and PATH_FS so that nobody needs to reinvent a solved wheel, create documentation, or anything else around these topics ... they're just commonly supported by many other WASM targeting projects because Emscripten provides those out of the box.
I hope this clarifies my idea around this proposal ... I never wanted a new API, although I'd welcome one within the Lua realm, but it's gotta be consistent from the JS side of affairs (imo).
In addition to existing FS code, I think it would be great if all the filesystems are included, like NODEFS, IDBFS and WORKERFS. Tree-shaking should keep the bundle size relatively light if you didn't use any of the filesystems.
The way emscripten creates the glue code doesn't support tree-shaking :(