Missing PATH and PATH_FS for FS operations

[WebReflection]

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]

Do you think exposing a _module would be a good solution?

[WebReflection]

@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 👍

[takase1121]

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.

[WebReflection]

@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).