:warning: Breaking change: I've renamed H5WasmProvider to H5WasmBufferProvider for clarity.
The two h5wasm providers now both use the same worker-based API. In fact, they even use the same H5WasmApi class. Where it differs is in the two providers themselves: H5WasmBufferProvider calls a new method in the worker API called remote.openFileBuffer(buffer), and H5WasmLocalFileProvider calls remote.openLocalFile(file) (previously named openFile). Both of these methods return the file's identifier provided by the HDF5 library, which is then passed to the H5WasmApi constructor. That's it!
The rest of the diff is basically about replacing h5wasm-api.ts with the content of h5wasm-local-file-api.ts, removing the local folder, and removing a whole bunch of obsolete utilities.
One significant benefit of this refactoring (in addition to removing a lot of code) is that consumers who use the two providers no longer end up with h5wasm twice in their bundle. For instance, the demo's bundle was basically cut in half, from 10 MB back down to 5 MB.
Additionally, I was so far testing only H5WasmApi (the one with the buffer) and not H5WasmLocalFileApi (because of the web worker). Since we now have a single H5WasmApi, I had no choice but to get the tests to work with it. This was challenging because Vitest runs in a Node environment, which doesn't support Web Workers. There's a package called @vitest/worker that simulates workers in Node, but it is not compatible with Comlink... In the end, the very simple solution I found is to import and use the worker API object directly (no Web Worker, no Comlink).
:warning: Breaking change: I've renamed
H5WasmProvidertoH5WasmBufferProviderfor clarity.The two h5wasm providers now both use the same worker-based API. In fact, they even use the same
H5WasmApiclass. Where it differs is in the two providers themselves:H5WasmBufferProvidercalls a new method in the worker API calledremote.openFileBuffer(buffer), andH5WasmLocalFileProvidercallsremote.openLocalFile(file)(previously namedopenFile). Both of these methods return the file's identifier provided by the HDF5 library, which is then passed to theH5WasmApiconstructor. That's it!The rest of the diff is basically about replacing
h5wasm-api.tswith the content ofh5wasm-local-file-api.ts, removing thelocalfolder, and removing a whole bunch of obsolete utilities.One significant benefit of this refactoring (in addition to removing a lot of code) is that consumers who use the two providers no longer end up with h5wasm twice in their bundle. For instance, the demo's bundle was basically cut in half, from 10 MB back down to 5 MB.
Additionally, I was so far testing only
H5WasmApi(the one with the buffer) and notH5WasmLocalFileApi(because of the web worker). Since we now have a singleH5WasmApi, I had no choice but to get the tests to work with it. This was challenging because Vitest runs in a Node environment, which doesn't support Web Workers. There's a package called@vitest/workerthat simulates workers in Node, but it is not compatible with Comlink... In the end, the very simple solution I found is to import and use the worker API object directly (no Web Worker, no Comlink).