fix(ts-bindings): valid TS when >1 contracterror #2031
Conversation
5333dcf to
235a4d1
Compare
235a4d1 to
fae2e17
Compare
|
I first reviewed blind to the context. Does this mean that when you have multiple error defs they are assigned a value as they are seen. e.g. first error enum with four [0-3], does this second start at value 4? |
fae2e17 to
4749a4b
Compare
|
@willemneal no, it doesn't reassign error numbers. I just checked; if you have two separate export const Errors = {
100: {message:"Unauthorized"},
/**
* The operation failed because the contract is paused.
*/
100: {message:"EnforcedPause"},
/**
* The operation failed because the contract is not paused.
*/
101: {message:"ExpectedPause"}
}Great catch. Not sure what to about this. |
|
@willemneal ok, I dug into it, and I believe these errorTypes: spec.errorCases().reduce(
(acc, curr) => ({
...acc,
[curr.value()]: { message: curr.doc().toString() },
}),
{} as Pick<ClientOptions, "errorTypes">,
),I've added a second commit to remove all the logic to generate |
We were generating a separate `const Errors` definition for every
`#[contracterror]` in the original contract source. For example, with
the new `custom_type` source code, the generated TS would be:
```ts
export const Errors = {
/**
* Please provide an odd number
*/
1: {message:"NumberMustBeOdd"}
}
export const Errors = {
/**
* Some contract libraries contain extra #[contracterror] definitions that end up compiled
* into the main contract types. We need to make sure tooling deals with this properly.
*/
100: {message:"HowCouldYou"}
}
```
This now names the `const` after the name of the error enum in the
original file, following the logic of other enum types. It will also
rename `Error` to `Errors`, to avoid conflicts with JS `Error` type. So
the updated `custom_type` source code now generates:
```ts
export const Errors = {
/**
* Please provide an odd number
*/
1: {message:"NumberMustBeOdd"}
}
export const Erroneous = {
/**
* Some contract libraries contain extra #[contracterror] definitions that end up compiled
* into the main contract types. We need to make sure tooling deals with this properly.
*/
100: {message:"HowCouldYou"}
}
```
These constants are NOT ACTUALLY USED by the TS, but are continuing to
be exported to avoid considering this a breaking change to the library
generation logic.
This is needed in order to generate TS bindings for [OpenZeppelin's
Fungible Token][1]. The contract itself defines [`contracterror` number
1][2], the `pausable` libraries defines [100-series
`contracterror`s][3], and the `fungible` library creates [200-series
`contracterror`s][4].
[1]: https://github.com/OpenZeppelin/stellar-contracts/blob/main/examples/fungible-token-interface/src/contract.rs
[2]: https://github.com/OpenZeppelin/stellar-contracts/blob/54eec16f8f8d8373936147464d6eb81eff3c58c2/examples/fungible-token-interface/src/contract.rs#L29C1-L34C2
[3]: https://github.com/OpenZeppelin/stellar-contracts/blob/54eec16f8f8d8373936147464d6eb81eff3c58c2/packages/contract-utils/pausable/src/pausable.rs#L74-L82
[4]: https://github.com/OpenZeppelin/stellar-contracts/blob/54eec16f8f8d8373936147464d6eb81eff3c58c2/packages/tokens/fungible/src/fungible.rs#L156-L182
Co-authored-by: Willem Wyndham <willem@ahalabs.dev>
4a25b39 to
368af40
Compare
| let name = if name == "Error" { | ||
| format!("{name}s") |
There was a problem hiding this comment.
Do you know why the s is added? I see you're just copying the behaviour from above.
There was a problem hiding this comment.
I suspect the original guess was that Error is a reserved word in JS. It’s not; we can name the export Error and compile with no problem. It does make for unexpected name collisions though, with the built in Error.
I figured matching the logic above would make for a more consistent file as well as less of a change from the previous behavior.
We were generating a separate
const Errorsdefinition for every#[contracterror]in the original contract source. For example, with the newcustom_typesource code, the generated TS would be:This now names the
constafter the name of the error enum in the original file, following the logic of other enum types. It will also renameErrortoErrors, to avoid conflicts with JSErrortype. So the updatedcustom_typesource code now generates:These constants are NOT ACTUALLY USED by the TS, but are continuing to be exported to avoid considering this a breaking change to the library generation logic.
This is needed in order to generate TS bindings for OpenZeppelin's Fungible Token. The contract itself defines
contracterrornumber 1, thepausablelibraries defines 100-seriescontracterrors, and thefungiblelibrary creates 200-seriescontracterrors.