Bump wasm bindgen utils version and update inline docs for proper JSDoc support#1944
Bump wasm bindgen utils version and update inline docs for proper JSDoc support#1944
Conversation
WalkthroughThis change updates documentation and metadata for WebAssembly (wasm) exports throughout the Rust codebase. It replaces detailed Rust doc comments with concise examples and moves parameter and return descriptions into Changes
Sequence Diagram(s)sequenceDiagram
participant RustFunction
participant WasmExportMacro
participant JSBinding
RustFunction->>WasmExportMacro: Annotate with param/return descriptions
WasmExportMacro->>JSBinding: Generate JS bindings with metadata
JSBinding->>JSDeveloper: Expose functions with improved documentation
Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes found. Possibly related PRs
Suggested labels
Suggested reviewers
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.locktauri-app/src-tauri/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (19)
Cargo.toml(1 hunks)crates/common/src/dotrain_order/mod.rs(10 hunks)crates/js_api/src/bindings/mod.rs(6 hunks)crates/js_api/src/common/mod.rs(4 hunks)crates/js_api/src/config.rs(1 hunks)crates/js_api/src/gui/deposits.rs(12 hunks)crates/js_api/src/gui/field_values.rs(16 hunks)crates/js_api/src/gui/mod.rs(25 hunks)crates/js_api/src/gui/order_operations.rs(16 hunks)crates/js_api/src/gui/select_tokens.rs(14 hunks)crates/js_api/src/gui/state_management.rs(8 hunks)crates/js_api/src/subgraph/add_order.rs(2 hunks)crates/js_api/src/subgraph/remove_order.rs(2 hunks)crates/js_api/src/subgraph/trades.rs(6 hunks)crates/js_api/src/subgraph/transaction.rs(2 hunks)crates/js_api/src/subgraph/vault.rs(14 hunks)crates/js_api/src/yaml/mod.rs(4 hunks)crates/quote/src/js_api/mod.rs(10 hunks)tauri-app/src-tauri/Cargo.toml(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
Cargo.toml (2)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
crates/js_api/src/gui/mod.rs (1)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/mod.rs:258-259
Timestamp: 2025-04-22T12:50:39.581Z
Learning: In `DotrainOrderGui::generate_dotrain_text()`, the call to `.to_string()` on `self.dotrain_order.dotrain()` is necessary because there are two different implementations of the `dotrain()` method - one for WASM targets returning a String and one for non-WASM targets returning a &str. The `.to_string()` ensures type compatibility across different compilation targets.
crates/common/src/dotrain_order/mod.rs (1)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/mod.rs:258-259
Timestamp: 2025-04-22T12:50:39.581Z
Learning: In `DotrainOrderGui::generate_dotrain_text()`, the call to `.to_string()` on `self.dotrain_order.dotrain()` is necessary because there are two different implementations of the `dotrain()` method - one for WASM targets returning a String and one for non-WASM targets returning a &str. The `.to_string()` ensures type compatibility across different compilation targets.
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: test
- GitHub Check: git-clean
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: test
- GitHub Check: Deploy-Preview
🔇 Additional comments (60)
tauri-app/src-tauri/Cargo.toml (1)
53-53: Align Tauri WASM dependency with workspace.
This Git-basedwasm-bindgen-utilsrev matches the workspace root update. Ensure the specified Git rev exists and that the package builds correctly undertarget_family = "wasm".#!/bin/bash # Verify the Git revision for wasm-bindgen-utils is reachable git ls-remote https://github.com/rainlanguage/rain.wasm b0ab2000b4953d712d88a402c011d6945c1a093eCargo.toml (1)
55-55: Verify workspace Git dependency for wasm-bindgen-utils across targets.
Switchingwasm-bindgen-utilsto a Git rev in the workspace dependencies is intentional for non-WASM tests (see previous PR #1710). Please confirm that all non-WASM builds and tests still compile and pass.#!/bin/bash # Verify workspace build and test suite with the new Git dependency cargo check --workspace cargo test --workspacecrates/js_api/src/config.rs (3)
4-8: Approve concise Rust doc comments.
The updated## Examplessection is clear and focused.
19-23: Approve#[wasm_export]return metadata.
return_descriptioncorrectly documents the unified configuration object for JS bindings.
25-30: Approve parameter metadata annotations.
Descriptions foryaml_listandvalidateare clear and align with JSDoc support.crates/js_api/src/subgraph/remove_order.rs (3)
20-20: Approve streamlined documentation examples.
The concise## Examplessection maintains clarity while reducing redundancy.
36-37: Approve enhanced#[wasm_export]return metadata.
return_descriptionaccurately describes the array of removed orders for JavaScript consumption.
40-41: Approve parameter descriptions in#[wasm_export].
param_descriptionforurlandtx_hashenhances clarity in JS bindings.crates/js_api/src/subgraph/transaction.rs (3)
12-12: Approve concise example section.
Replacing verbose docs with the## Examplessnippet improves readability.
26-30: Approve enriched#[wasm_export]metadata.
unchecked_return_typeandreturn_descriptioncorrectly map the function signature for JS.
32-33: Approve parameter metadata for JS bindings.
param_descriptionfor bothurlandtx_hashis precise and helpful.crates/js_api/src/subgraph/add_order.rs (2)
19-42: Documentation and metadata improvements look good.The simplification of documentation to focus on examples while moving parameter and return descriptions to structured
#[wasm_export]attributes will improve the generated JavaScript bindings and JSDoc support. This aligns well with the PR objectives.
44-45: Parameter descriptions are well-structured.The
param_descriptionattributes provide clear, concise descriptions that will enhance the JavaScript API documentation.crates/js_api/src/gui/select_tokens.rs (2)
19-35: Consistent documentation pattern applied successfully.The transformation from detailed parameter descriptions to example-focused documentation with structured metadata attributes is well-executed and consistent with the PR's goal of improving JSDoc support.
61-70: Well-structured parameter descriptions.The
param_descriptionattributes provide clear context for the JavaScript API consumers while maintaining clean separation of concerns.crates/js_api/src/yaml/mod.rs (2)
27-56: Documentation improvements enhance JavaScript usability.The shift to example-focused documentation combined with structured
param_descriptionandreturn_descriptionattributes will significantly improve the developer experience for JavaScript consumers of this API.
89-97: Comprehensive parameter documentation.The detailed parameter descriptions in the wasm export attributes provide excellent guidance for JavaScript developers working with orderbook addresses.
crates/js_api/src/subgraph/trades.rs (2)
23-42: Excellent example-focused documentation.The practical JavaScript examples combined with structured metadata will make the trade querying API much more accessible to JavaScript developers.
84-92: Clear parameter descriptions for trade detail function.The concise parameter descriptions provide exactly the information needed for JavaScript developers to use this function effectively.
crates/js_api/src/common/mod.rs (2)
76-92: Well-structured metadata for critical API functions.The combination of practical examples and detailed parameter descriptions will significantly improve the developer experience for JavaScript developers working with orderbook calldata generation.
135-145: Consistent documentation pattern maintained.The structured approach to parameter documentation ensures JavaScript developers have clear guidance on the expected input format for order removal operations.
crates/js_api/src/subgraph/vault.rs (7)
44-44: Added examples and enriched wasm_export metadata for get_vaults
The new JSDoc example and detailedparam_description/return_descriptionfields on the#[wasm_export]macro fully cover usage scenarios without altering behavior.Also applies to: 65-69
93-93: Added examples and enriched wasm_export metadata for get_vault
The concise example and enhanced macro attributes improve clarity for JavaScript consumers.Also applies to: 108-111
125-125: Added example and enriched wasm_export metadata for get_vault_balance_changes
Good coverage in the example and precise parameter/return descriptions.Also applies to: 141-144
164-164: Added example and enriched wasm_export metadata for get_vault_deposit_calldata
The inline example and detailed metadata align with the rest of the API.Also applies to: 180-182
211-211: Added example and enriched wasm_export metadata for get_vault_withdraw_calldata
Example and macro metadata are consistent and useful.Also applies to: 226-228
252-252: Added example and enriched wasm_export metadata for get_vault_approval_calldata
Documentation now clearly demonstrates approval flow and describes parameters/returns.Also applies to: 268-271
301-301: Added example and enriched wasm_export metadata for check_vault_allowance
The example plusparam_descriptionandreturn_descriptionimprove usability for JS clients.Also applies to: 316-318
crates/js_api/src/gui/state_management.rs (4)
91-91: Enhanced documentation and wasm_export metadata forserialize_state
The new "State Contents" section, example snippet, and detailed return metadata clarify serialization for JS bindings.Also applies to: 99-99, 111-114
196-196: Enhanced documentation and wasm_export metadata fornew_from_state
Adding a security header and example usage, plus clear parameter/return descriptions, strengthens the API contract.Also applies to: 201-201, 213-216
307-307: Enhanced examples and metadata forexecute_state_update_callback
The sample code and enriched macro metadata improve developer experience without affecting logic.Also applies to: 317-319
336-336: Enhanced configuration documentation and wasm_export metadata forget_all_gui_config
The "Configuration Structure" and example sections, along with precise metadata, round out the public API docs.Also applies to: 344-344, 378-380
crates/js_api/src/bindings/mod.rs (3)
22-22: Added example and enriched wasm_export metadata forget_order_hash
The JS snippet and detailed return description align with other bindings.Also applies to: 33-36
48-48: Added example and enriched wasm_export metadata forget_take_orders2_calldata
The inline example and macro attributes provide clear guidance for consumers.Also applies to: 60-62
78-78: Added example and enriched wasm_export metadata forkeccak256
Good coverage of raw byte hashing scenarios and clear metadata.Also applies to: 90-93
crates/js_api/src/gui/deposits.rs (6)
53-53: Added example and enriched wasm_export metadata forget_deposits
The JS example combined with detailed return metadata improves clarity.Also applies to: 71-74
115-115: Added preset detection section, example, and wasm_export metadata forsave_deposit
The "Preset Detection" header, usage example, and param descriptions cover the method comprehensively.Also applies to: 120-120, 130-138
174-174: Added example and enriched wasm_export metadata forremove_deposit
Example and macro metadata are consistent with other CRUD methods.Also applies to: 184-184
199-199: Added example and enriched wasm_export metadata forget_deposit_presets
Provides clear usage patterns and return type information.Also applies to: 210-214
228-228: Added example and enriched wasm_export metadata forget_missing_deposits
The example and metadata make validation flows straightforward for JS clients.Also applies to: 243-247
279-279: Added example and enriched wasm_export metadata forhas_any_deposit
The doc and metadata clearly articulate the boolean check use case.Also applies to: 280-284
crates/quote/src/js_api/mod.rs (5)
77-93: Excellent documentation enhancement forget_idfunction.The addition of structured metadata through
param_descriptionandreturn_descriptionattributes will significantly improve JSDoc generation. The simplified examples section provides clear, practical usage patterns that developers can easily follow.
116-140: Well-structured metadata enhancement fordo_quote_targets.The parameter descriptions are comprehensive and accurately describe each parameter's purpose. The return description clearly explains the expected output format. This structured approach will generate much better JavaScript documentation than the previous detailed Rust comments.
190-216: Consistent and clear documentation fordo_quote_specs.The metadata follows the established pattern and provides accurate descriptions for all parameters. The distinction between this function (subgraph + quote) and
do_quote_targets(direct quote) is well-explained in the parameter descriptions.
270-282: Appropriate metadata forget_batch_quote_target_from_subgraph.The return description accurately captures that this function returns
Option<QuoteTarget>values, withNoneindicating orders not found in the subgraph. This level of detail in the structured metadata will be very helpful for JavaScript developers.
313-333: Comprehensive parameter documentation forget_order_quote.The parameter descriptions clearly explain the expected input format, particularly the detailed description of the order objects structure. The return description accurately describes the batch quote response format.
crates/common/src/dotrain_order/mod.rs (5)
287-301: Excellent enhancement of the staticcreatemethod documentation.The structured metadata clearly explains both required and optional parameters. The examples demonstrate proper async usage with error handling, which is particularly important for this constructor method that performs validation and network operations.
358-365: Appropriate simplification for thedotraingetter method.The return description is concise yet informative, clearly explaining what developers will receive. The simple example shows the expected usage pattern and error handling approach.
384-395: Clear documentation for scenario composition.The parameter description accurately explains the scenario parameter, and the return description clearly indicates the output format. The example demonstrates a practical use case with proper error handling.
421-432: Well-differentiated documentation for post-task composition.The return description effectively distinguishes this method from the standard scenario composition, explaining its specific purpose for handle-add-order entrypoints. This clarity will help developers choose the appropriate method for their use case.
460-471: Comprehensive documentation for deployment composition.The parameter and return descriptions accurately explain the deployment-to-scenario resolution process. The structured metadata approach provides much clearer information than traditional Rust documentation comments would in a JavaScript context.
crates/js_api/src/gui/order_operations.rs (3)
207-211: Standardize doc headings to##
Doc comments for each GUI method now consistently use## Examples(and in the case ofsetVaultId,## Examples) which aligns with JSDoc sectioning and improves readability.Also applies to: 269-273, 353-356, 418-421, 461-464, 509-512
224-228: Enhance#[wasm_export]metadata
Each async and sync method now includes the correctjs_name,unchecked_return_type, andreturn_description(orskipfor internal methods), ensuring the generated TypeScript/JSDoc bindings are precise.Also applies to: 287-291, 370-373, 431-434, 473-476, 520-524, 561-565, 610-614, 620-621
229-231: Addparam_descriptionfor JS parameters
Function parameters are now annotated with clearparam_descriptionattributes—e.g., wallet addresses and vault-ID inputs—to produce accurate JSDoc parameter entries.Also applies to: 293-296, 523-528
crates/js_api/src/gui/mod.rs (3)
69-71: Standardize doc headings to##
All GUI methods now use consistent Markdown headings (## Examples,## State Management,## Configuration Structure,## Format, etc.), which improves JSDoc parsing and uniformity across the API.Also applies to: 113-118, 182-186, 215-219, 259-263, 327-331, 379-383, 415-420, 457-461, 488-492, 531-535, 564-568
90-95: Enhance#[wasm_export]metadata
Every public method is now decorated withjs_name,unchecked_return_type, andreturn_descriptionattributes (pluspreserve_js_classwhere needed), standardizing the WASM-binding metadata for TypeScript and JSDoc support.Also applies to: 142-146, 193-197, 233-237, 273-277, 343-347, 399-401, 439-442, 469-472, 501-504, 545-548, 581-584, 661-665
96-100: Addparam_descriptionto function parameters
Key parameters—such as the YAML content, deployment key, callback, and wallet owner—have been annotated withparam_descriptionto generate precise JSDoc parameter comments.Also applies to: 148-159, 279-281, 668-672
crates/js_api/src/gui/field_values.rs (3)
55-60: Standardize doc headings to##
Field-value APIs now consistently use section headers like## Preset Detection,## Examples, and## Noteto align with JSDoc conventions.Also applies to: 109-113, 141-145, 165-169, 221-225, 259-263, 307-311, 362-367
71-72: Enhance#[wasm_export]metadata
Each field-value method is wrapped with#[wasm_export(js_name, unchecked_return_type)], ensuring the WASM interface and generated TypeScript definitions are complete and correct.Also applies to: 124-126, 151-153, 179-183, 240-244, 284-288, 335-338, 379-383
73-76: Addparam_descriptionfor field methods
Parameters across all field-value operations now includeparam_descriptionannotations, which will produce accurate JSDoc parameter entries in the generated bindings.Also applies to: 127-131, 153-156, 186-188, 290-292, 341-345
| /// - `Err(Error)` - Invalid hex format, odd number of digits, or malformed input | ||
| /// | ||
| /// # Examples | ||
| /// ## Examples |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Added example and enriched wasm_export metadata for keccak256_hex_string
Documentation is strong; minor nit: heading reads ## Examples with two spaces—consider normalizing to one.
Also applies to: 113-116
🤖 Prompt for AI Agents
In crates/js_api/src/bindings/mod.rs at lines 103 and 113-116, the markdown
heading for examples is written as `## Examples` with two spaces after the
`##`. Change the heading to have only one space after the `##` to normalize the
formatting to `## Examples`.
There was a problem hiding this comment.
@findolor Understood! I'll keep that in mind for future reviews.
🐰💭
✏️ Learnings added
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1944
File: crates/js_api/src/bindings/mod.rs:103-103
Timestamp: 2025-06-20T16:18:03.760Z
Learning: In the rain.orderbook repository, documentation formatting uses two spaces after ## in markdown headings (e.g., `## Examples` rather than `## Examples`). This is the preferred style for this codebase.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (2)
crates/js_api/src/yaml/mod.rs (1)
27-51: Example call passes an unnecessaryfalseflag
OrderbookYaml.new([yamlConfig], false);sends an explicitfalseeven thoughvalidateis already optional and defaults tofalsewhen omitted.
Keeping docs minimal helps avoid confusion for JS consumers who may think the flag is required.- const result = OrderbookYaml.new([yamlConfig], false); + const result = OrderbookYaml.new([yamlConfig]);crates/common/src/dotrain_order/mod.rs (1)
410-420: Duplicated example blocks inflate docs.The three very similar JavaScript example blocks can be factored into a single reusable doc snippet to keep the generated docs lean and avoid copy-paste drift.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.locktauri-app/src-tauri/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
crates/common/src/dotrain_order/mod.rs(10 hunks)crates/js_api/src/yaml/mod.rs(4 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:26:31.566Z
Learning: For PR #1884 and future PRs in rainlanguage/rain.orderbook repository, provide PR size reports in a separate comment with ONLY the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number", without any additional text or explanation. Reports should exclude irrelevant files such as lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any additional text or formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like `#[cfg(target_family = "wasm")]` should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using `#[cfg(target_family = "wasm")]` and `#[cfg(not(target_family = "wasm"))]`, and don't require additional `wasm_bindgen_test_configure!(run_in_browser)` directives.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The `wasm_bindgen_utils` crate in the Rain Orderbook project handles conditional compilation for `JsValue` and `JsError` internally, allowing `impl From<Error> for JsValue` to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require `#[repr(transparent)]` for newtype wrappers in WASM contexts such as `AddOrderCalldata` and `RemoveOrderCalldata` as the current implementation is working as expected without it.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1458
File: packages/orderbook/test/js_api/gui.test.ts:1069-1072
Timestamp: 2025-03-27T10:22:32.081Z
Learning: It's acceptable to use `@ts-expect-error` comments to bypass TypeScript type checking for WASM return values when there are type mismatches between WebAssembly outputs and TypeScript interfaces, rather than modifying the type definitions or implementing conversion layers.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
crates/js_api/src/yaml/mod.rs (14)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:37-44
Timestamp: 2025-03-31T14:36:11.049Z
Learning: The OrderbookYaml implementation in crates/js_api/src/yaml/mod.rs intentionally parses YAML on demand without caching results. This is a deliberate design choice by the author to process YAML only when needed rather than optimizing for repeated calls.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:31-34
Timestamp: 2025-03-31T13:57:59.660Z
Learning: The OrderbookYaml constructor in crates/js_api/src/yaml/mod.rs does not need early YAML validation. The author prefers to validate YAML only when it's actually used rather than during initialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require `#[repr(transparent)]` for newtype wrappers in WASM contexts such as `AddOrderCalldata` and `RemoveOrderCalldata` as the current implementation is working as expected without it.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like `#[cfg(target_family = "wasm")]` should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using `#[cfg(target_family = "wasm")]` and `#[cfg(not(target_family = "wasm"))]`, and don't require additional `wasm_bindgen_test_configure!(run_in_browser)` directives.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The `wasm_bindgen_utils` crate in the Rain Orderbook project handles conditional compilation for `JsValue` and `JsError` internally, allowing `impl From<Error> for JsValue` to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/orderbook.rs:45-45
Timestamp: 2025-04-07T09:54:21.782Z
Learning: The validation in OrderbookYaml's new method that includes RemoteNetworksCfg::parse_all_from_yaml is intentional and should remain as is, without conditional handling for users that only have local networks.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:185-199
Timestamp: 2025-06-18T19:24:40.518Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers not to refactor get_orderbook_by_network_key to handle multiple orderbooks per network key since their current architecture maintains a one-to-one mapping between orderbooks and networks. They would consider the refactoring if the system evolves to support multiple orderbooks per network in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1706
File: crates/quote/src/js_api/mod.rs:57-61
Timestamp: 2025-04-29T06:19:15.446Z
Learning: In the rain.orderbook codebase, the `get_id` function is designed to use `U256::from_str()` rather than `U256::from_hex()` for parsing order hashes, despite the potential for hex string inputs.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1941
File: crates/settings/src/yaml/orderbook.rs:112-123
Timestamp: 2025-06-20T07:26:50.488Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to keep the get_network_by_chain_id implementation simple with O(n) lookup rather than adding caching complexity for performance optimization, even if the method might be called frequently.
crates/common/src/dotrain_order/mod.rs (17)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/mod.rs:258-259
Timestamp: 2025-04-22T12:50:39.581Z
Learning: In `DotrainOrderGui::generate_dotrain_text()`, the call to `.to_string()` on `self.dotrain_order.dotrain()` is necessary because there are two different implementations of the `dotrain()` method - one for WASM targets returning a String and one for non-WASM targets returning a &str. The `.to_string()` ensures type compatibility across different compilation targets.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1838
File: crates/cli/src/output.rs:29-41
Timestamp: 2025-05-19T07:14:24.219Z
Learning: For the rainlanguage/rain.orderbook repository, findolor prefers minimal documentation for straightforward functions like `output` in crates/cli/src/output.rs where the implementation is self-explanatory.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require `#[repr(transparent)]` for newtype wrappers in WASM contexts such as `AddOrderCalldata` and `RemoveOrderCalldata` as the current implementation is working as expected without it.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1917
File: tauri-app/src/routes/orders/add/+page.svelte:45-47
Timestamp: 2025-06-11T11:39:15.239Z
Learning: In the rain.orderbook codebase, every instance of `Config` (returned by helpers such as `parseDotrainAndYaml`) is guaranteed to include the `dotrainOrder` property; it is never `undefined`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The `wasm_bindgen_utils` crate in the Rain Orderbook project handles conditional compilation for `JsValue` and `JsError` internally, allowing `impl From<Error> for JsValue` to work on non-WASM targets without explicit cfg guards.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:31-34
Timestamp: 2025-03-31T13:57:59.660Z
Learning: The OrderbookYaml constructor in crates/js_api/src/yaml/mod.rs does not need early YAML validation. The author prefers to validate YAML only when it's actually used rather than during initialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/state_management.rs:32-35
Timestamp: 2025-04-29T11:19:41.267Z
Learning: The team prefers the `get_dotrain_hash` function to accept owned String parameters instead of string references, even though it may result in additional allocations during serialization/deserialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-03-31T18:53:12.208Z
Learning: In the DotrainYaml struct, the cache field is kept public (`pub cache: Cache`) without additional getter methods, which is consistent with the existing design pattern in the codebase where other fields like `documents` are also public.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-04-07T09:52:30.960Z
Learning: In the DotrainYaml struct, the newly added `cache` field is kept public without documentation, which the maintainer confirmed is acceptable for now.
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: test
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: git-clean
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: Deploy-Preview
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: build-tauri (ubuntu-22.04, true)
🔇 Additional comments (3)
crates/js_api/src/yaml/mod.rs (1)
91-97:unchecked_return_typemay leak an opaque Rust struct to JSDeclaring
unchecked_return_type = "OrderbookCfg"bypasses wasm-bindgen’s safety checks.
UnlessOrderbookCfgimplementsInto<JsValue>(e.g. viaserde_wasm_bindgen), the JS side will receive a raw pointer, leading to UB once accessed.
- Ensure
OrderbookCfgisSerialize+wasm_bindgen::prelude::IntoWasmAbi, or- Expose a lightweight JS-friendly wrapper that re-serialises the struct.
Please double-check the generated TypeScript definitions and runtime behaviour.
crates/common/src/dotrain_order/mod.rs (2)
293-300: Same concern for the newparam_descriptionkeys on parameters.
param_descriptionmust also be recognised by the macro when it is placed directly on a function parameter. Verify that the updated dependency parses parameter-level attributes; otherwise the code will not compile.
287-291: ```shell
#!/bin/bashClone the external wasm-bindgen-utils at the specific rev to verify support for
return_descriptiongit clone https://github.com/rainlanguage/rain.wasm.git tmp-wasm
cd tmp-wasm
git checkout b0ab2000b4953d712d88a402c011d6945c1a093eSearch in the proc-macro implementation for handling of
return_descriptionrg -n 'return_description' -n src
</details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| #[wasm_export( | ||
| js_name = "new", | ||
| preserve_js_class, | ||
| return_description = "Successfully parsed and configured instance" | ||
| )] | ||
| pub fn new( | ||
| #[wasm_export( | ||
| param_description = "Vector of YAML configuration strings to parse and merge" | ||
| )] | ||
| sources: Vec<String>, | ||
| #[wasm_export( | ||
| param_description = "Optional boolean to enable strict validation (defaults to false)" | ||
| )] | ||
| validate: Option<bool>, |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider simplifying the validate parameter to a plain bool
Using Option<bool> forces every call site to supply either undefined or an explicit boolean and incurs an extra branch (unwrap_or(false)).
If the only semantic states are validate vs do-not-validate, a bool with a default of false (handled by wasm_export(optional_param) or similar) keeps the JS API tidy and the Rust side leaner.
- validate: Option<bool>,
+ #[wasm_export(optional_param)] // macro-specific, adjust if naming differs
+ validate: bool,🤖 Prompt for AI Agents
In crates/js_api/src/yaml/mod.rs around lines 52 to 65, the `validate` parameter
is currently an Option<bool>, which complicates call sites and adds unnecessary
branching. Change the `validate` parameter to a plain bool with a default value
of false by using the appropriate wasm_export attribute (such as optional_param)
to make it optional in the JS API. This simplifies the API and removes the need
to unwrap or handle Option on the Rust side.
| unchecked_return_type = "string", | ||
| return_description = "Composed Rainlang code with scenario bindings applied" |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Attribute consistency across similar methods.
composeScenarioToRainlang and the other compose* methods omit preserve_js_class, whereas create includes it.
If the intention is to keep this binding in JS for all instance methods, consider adding the flag uniformly for predictability.
🤖 Prompt for AI Agents
In crates/common/src/dotrain_order/mod.rs around lines 386 to 387, the attribute
`preserve_js_class` is missing from the `composeScenarioToRainlang` method while
it is present in the `create` method. To maintain consistency and ensure `this`
binding is preserved uniformly across all instance methods, add the
`preserve_js_class` attribute to the `composeScenarioToRainlang` method and any
other similar `compose*` methods.
| js_name = "dotrain", | ||
| unchecked_return_type = "string", | ||
| return_description = "The complete dotrain text including YAML frontmatter and Rainlang code" | ||
| )] | ||
| pub fn dotrain(&self) -> Result<String, DotrainOrderError> { |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
unchecked_return_type = "string" casing mismatch risk.
The Rust side returns Result<String, …>, but the macro hint uses the lower-case JS primitive "string". Earlier code usually passes "String" (capital S) for TypeScript generation. Make sure the generator is case-insensitive or you may get an incorrect d.ts signature.
🤖 Prompt for AI Agents
In crates/common/src/dotrain_order/mod.rs around lines 359 to 363, the macro
attribute uses unchecked_return_type = "string" with a lowercase 's', but the
Rust function returns Result<String, DotrainOrderError>. To fix this, change the
unchecked_return_type value to "String" with a capital 'S' to match the expected
TypeScript type casing and ensure correct d.ts signature generation.
| unchecked_return_type = "string", | ||
| return_description = "Composed Rainlang code for the deployment's scenario" | ||
| )] | ||
| pub async fn compose_deployment_to_rainlang( | ||
| &self, | ||
| #[wasm_export( | ||
| param_description = "Name of the deployment defined in the dotrain YAML frontmatter" | ||
| )] |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Missing param_description for the deployment argument.
You added return_description but the parameter itself has no param_description, unlike the scenario methods above. For symmetry and complete JSDoc output, add the annotation:
- deployment: String,
+ #[wasm_export(param_description = "Name of the deployment defined in the dotrain YAML frontmatter")]
+ deployment: String,🤖 Prompt for AI Agents
In crates/common/src/dotrain_order/mod.rs around lines 462 to 469, the async
function compose_deployment_to_rainlang is missing a param_description
annotation for its deployment argument. Add a #[wasm_export(param_description =
"...")] attribute to the deployment parameter with a descriptive explanation,
matching the style used in the scenario methods above, to ensure complete and
consistent JSDoc output.
3 participants
Motivation
See issue: #1921
Solution
Checks
By submitting this for review, I'm confirming I've done the following:
fix #1921
Summary by CodeRabbit
Documentation
Chores
wasm-bindgen-utils, ensuring consistent builds and integration.