fix!: wasm compatibility for fuels-types
#839
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hal3e
previously approved these changes
Feb 20, 2023
…magnet/wasm_friendly_abigen
`fuel-core` feature was created by mentioning `fuel-core` inside the `fuel-core-lib` feature without using `dep:`. This has a consequence that if somebody should enable `fuel-core` as a feature, thinking that would get them the fuel-core-lib, it would only do half the job because the real feature for that is `fuel-core-lib`.
digorithm
approved these changes
Feb 23, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
closes: #837
closes: #854
A big thank you to @hal3e for help with the CI.
The wasm offending functionality is now hidden behind the feature
stdinfuels-typesand infuels-coreas well.Breakage:
@digorithm
It is part of the crate's default features, so most users shouldn't feel the change -- especially since there weren't other other features that would have made somebody do
default-features = falsein theirCargo.toml.But if they did for whatever reason, then they might see parts of
fuels-typesdisappear since thestdfeature would not be enabled. So that makes it a theoretically breaking change.Also
fuelshad two feature flags:fuel-coreandfuel-core-lib.fuel-coreis removed since it was implicitly added because the optional dependencyfuel-corehad not been referred to by prependingdep:to it.fuel-coreused to enable the fuel-core-lib only partially and was not the right flag to use.About the implementation
Cargo features should be additive by design. This means that you cannot remove dependencies by adding features.
This further means that wasm support is generally implemented by hiding wasm-offending code behind a feature (such as
std).In our case, if we want to be WASM compatible, we must not enable the
stdfeature on anyfuels-*crates our project might depend on.Feature unification makes this a bit difficult. If there is even one dependency that enabled
stdon somefuels-*crate, all other crates that are part of that compilation will also have thestdfeature enabled for that crate.Because of this, I've made it default for our workspace dependencies to start off without defaults (and thus without the
stdflag).If any of our crates need it, they will have to enable the feature explicitly.