feat!: init WASM during decode, remove top-level init #24
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The initial implementation of WebAssembly-based decoder in #20 caused some ugly API changes. It required users to await a top-level
init
promise:Following a suggestion from @dlehdanakf, this PR removes the need for an
init
promise:Instead, the
composite()
method (available onPsd
,Layer
, andGroup
objects) is now async:Details
This PR extracts the WebAssembly-based image decoder into a separate package named
@webtoon/psd-decoder
. This package exports theinit
promise in addition to methods generated by wasm-pack.The
generateRgba()
function in@webtoon/psd
imports@webtoon/psd-decoder
and awaits theinit
promise, ensuring that the WebAssembly module is ready before using any of its methods. This allows the rest of@webtoon/psd
to work without worrying aboutinit
.This PR effectively "moves" the top-level
init
from@webtoon/psd
to@webtoon/psd-decoder
. The asynchrony of WebAssembly is safely contained ingenerateRgba()
, instead of contaminating the entire library.On the flip side,
generateRgba()
is now asynchronous, even though it technically doesn't have to be...not yet, anyway.