-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using std
package without exports for target=wasm32
#1962
Comments
Good point. I thought about this from time to time too in the past but it was never a priority to fix. Could be done using a macro you need to call explicitly from a contract. Could you explain the use case in mode detail, specially the envorinment you want to use this in and the goal of your project? So far all JavaScript usage is clients and they don't really need the types as Addr, Uint128 and Binary are simply strings in the JSON interface. |
Also is your problem exports or imports?
|
The javascript issue is indeed not of higher priority. Compiling for javascript solely for porting the primitives wouldn't make sense for sure. However if it was a library that uses those primitives for an algorithm or a complex function it can be beneficial to use the same code in multiple environments. Possible some performance improvements for JS if it is doing cryptography or matrix calculations What I am personally face right now is issues caused by referencing an interface package that depends on Here is a package I am trying to reference but I believe it is going to be identical with If I try to reference the package from a project that uses a fork of the cosmwasm it will fail since both of the version are injecting the same exports on build (on target_arch =
|
When a project references
cosmwasm_std
crate as one of the dependencies and is being compiled to wasm32 architecture, the package injects entrypoint exports into the final wasm buildcosmwasm/packages/std/src/lib.rs
Lines 111 to 112 in 888552a
It might not be desirable when developing interfaces and libraries that only need certain types like
Binary
,Uint128
and so on.It unnecessarily increases the size when building for Javascript environment and causes issues when building for virtual machines with custom constraints
A possible solution would be to only inject the exports when referencing cosmwasm contract specific entities like
entrypoint
or to provide additional feature flag for the crate (e.g.library
) for opting out of injectionThe text was updated successfully, but these errors were encountered: