How best to contribute?

[parkertomatoes]

Hi,

This is an embarrassing story, but I made the exact same project as you to support another retro-emulation project: https://github.com/parkertomatoes/fatfs-wasm

I did that last year, sat on it for a few months, and logged in this weekend to publish it only to discover you had published js-fatfs in the meantime. 🤦

I'd much rather use an existing implementation (less work for me), but there are some differences:

• The WASM file you generated is very large, 500k. I got it down to 22k by using clang directly without libc.
• I went and coded a lot of high-level wrappers around the C functions
• I wrote some unit tests (albeit, for the high-level wrapper)

Would you be interested in merging any of that effort into js-fatfs?

[irori]

Oh, had I known that, I would not have written this library from scratch! :)

The WASM file you generated is very large, 500k. I got it down to 22k by using clang directly without libc.

This is mainly because js-fatfs is compiled with all OEM-Unicode conversion tables enabled, which according to FatFs documentation causes a +486k code size increase. (That said, given the FatFs' minimal libc dependency, not using emacscripten sounds like a good choice.)

Perhaps this library should provide two variants, a "lite" variant that does not include Unicode conversion and LFN support, and a "full" variant.

I went and coded a lot of high-level wrappers around the C functions

The use case I had in mind was manipulation of a Japanese retro PC disk image, which had requirements like:

• It must be able to handle Japanese (code page 932) file names
• Disk images may not be in the raw format, so per-sector read/write interface may be more appropriate than passing an entire disk image in a Uint8Array

What would a high-level API look like that could meet these requirements? If OEM-to-Unicode conversion tables are not included, then filenames would have to be represented as byte strings rather than JavaScript strings.

Would you be interested in merging any of that effort into js-fatfs?

I think it is a good idea to merge efforts, but I don't insist on basing it on my library. If you think that making improvements to fatfs-wasm would be a shorter route, then let's do so. I will be happy to contribute there. Otherwise, I'll also be happy to accept your pull requests for this library.

[parkertomatoes]

Thank you for thoughtfully explaining your use-case. I hadn't considered the larger file size was due to a feature and not some kind of overhead. And your examples of requirements for Japanese image support are a great example of how my naive wrapper over the API might break.

All things considered, I think it makes sense to leave your library's interface as it is, and make any additional features (e.g. high level wrappers) as a separate npm package that pulls in this one.

I just wish I could customize all those preprocessor settings (exFAT, Unicode, number of partitions, etc) from package.json. That would mean involving node-gyp/prebuilt, which is a nasty can of worms. Is it even possible for WASM target?

[irori]

All things considered, I think it makes sense to leave your library's interface as it is, and make any additional features (e.g. high level wrappers) as a separate npm package that pulls in this one.

+1

I just wish I could customize all those preprocessor settings (exFAT, Unicode, number of partitions, etc) from package.json. That would mean involving node-gyp/prebuilt, which is a nasty can of worms. Is it even possible for WASM target?

There are so many combinations of settings that it would be impractical to have pre-built WASMs for all of them. On the other hand, I think it makes sense to divide the library into "full", which enables as many features as possible, and "lite", which covers 80% of use cases.

It may be possible to compile the C code on the user side of the package using technologies like clang.wasm, but I could not find any precedent for this approach.