[BRO-31] Errors on websites with strict Content Security Policy

[Ivan-Mahda]

Purpose

The injected script attempts to compile and instantiate WebAssembly, which fails when a website uses a Content Security Policy which does not allow for running WebAssembly.
Main reason esbuild does not provide proper tree-shaking and as result unused WebAssembly functions included in to bundle
This can be avoided by importing only functions you need, without importing all module.

Changes

Created yarn patch for @concordium/web-sdk
Now it is possible to import from ./types/ directory, and avoid tree-shaking bug of esbuild

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

By submitting the contribution I accept the terms and conditions of the
Contributor License Agreement v1.0

• link: https://developers.concordium.com/CLAs/Contributor-License-Agreement-v1.0.pdf

• I accept the above linked CLA.

[abizjak]

@Ivan-Mahda I will take myself off the reviewers list. Soren and Emil are the experts anyhow.

[soerenbf]

Great detective work @Ivan-Mahda!

It seems that this completely removes the WASM error.. I actually thought we needed to dive into the legacy grpc client and well and do some updates, but seems like that is not needed anyway 🤷

[limemloh]

The patch is nice for now, but I think we should fix it in the SDK straight away as well and then remove this patch again.

[soerenbf]

The patch is nice for now, but I think we should fix it in the SDK straight away as well and then remove this patch again.

I suggested we do this as a yarn patch initially, as I thought we might want to discuss if we want to make the types accessible in this manner in the SDK.

One point of view could be that it worsens the user experience, as fromJSON would trigger n (i.e. the number of wrapper types) suggestions from the typescript LSP along with the code produced being less readable (but maybe these rules are not for us to impose upon others?).

Of course another point of view could be that it enables people to use tools like ESBuild and potentially other tools with less ability to tree-shake than the state-of-the-art bundlers.

Personally, I feel inclined towards the former of the two.. But I don't have any strong opinion on this matter tbh.

What do you think @Ivan-Mahda and @limemloh ?

[limemloh]

The patch is nice for now, but I think we should fix it in the SDK straight away as well and then remove this patch again.

I suggested we do this as a yarn patch initially, as I thought we might want to discuss if we want to make the types accessible in this manner in the SDK.

One point of view could be that it worsens the user experience, as fromJSON would trigger n (i.e. the number of wrapper types) suggestions from the typescript LSP along with the code produced being less readable (but maybe these rules are not for us to impose upon others?).

Of course another point of view could be that it enables people to use tools like ESBuild and potentially other tools with less ability to tree-shake than the state-of-the-art bundlers.

Personally, I feel inclined towards the former of the two.. But I don't have any strong opinion on this matter tbh.

What do you think @Ivan-Mahda and @limemloh ?

Just wanted to check the experience if we did this, and you are right, it does add a lot of noise:

I agree then, let's get this merged and find the best solution for the SDK after