Closed sirpy closed 6 months ago
Not sure but this still seems to relate to URLs. Perhaps you could try moving your compatibility_date
forward, or enable flags to do with URLs e.g. https://developers.cloudflare.com/workers/configuration/compatibility-dates/#new-url-parser-implementation
@alanshaw I don't think so. looking at the code it uses a value from import.meta which resolves to undefined, and that is the issue.
@alanshaw probably even resolving import.meta.url wouldnt work as there's no url for the cloudflare worker to resolve the wasm file from. this looks more like browser/non-browser env detection issue
Hmm yes looks like you're right. @gozala would you mind looking into this next CIC?
Hey @sirpy
Apologies for late response here. We have been working on getting this supported into Cloudflare workers. The good news are that once https://github.com/web3-storage/w3up/pull/1294 is merged and released, you will be able to use w3up-client
in CF Workers environment. However, it won't be an out of the box solution. Cloudflare has some strict limitations on how to load WASM bytecode, which sadly goes against how other environments accept to load WASM bytecode (where are the standards? 😭 ). To try to make life easier to deploy this into Cloudflare workers, I put together a esbuild-plugin
you can use, as well as an example:
To use this, you will just need to wait for #1294 to be merged/released and guarantee afterwards that when installing dependencies you have fr32-sha2-256-trunc254-padded-binary-tree-multihash@3.3.0
(latest)
@vasco-santos thanks
@vasco-santos ok it worked I still had to patch URL importing the storage requires do to the import like you did, directly from the class file, importing from top level exports breaks.
Previously we've been using web3storage with cloudflare workers. Trying to get it to work with w3up we encounter multiple issues to get it to work
lastly couldnt solve the last error when calling
client.uploadFile