feat: setup speakeasy #794
Conversation
WalkthroughThe changes introduce new GitHub Actions workflows for SDK generation and publishing, modify existing CI configurations, and enhance OpenAPI specifications. A new script is added to preprocess OpenAPI files for compatibility with the Speakeasy SDK. Various documentation files are created or updated to improve clarity and usability. Additionally, TypeScript configurations and utility files are introduced to support the SDK's functionality and maintainability. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant API
participant Preprocess Script
participant SDK
User->>API: Request API Specification
API->>User: Return OpenAPI Specification
User->>Preprocess Script: Run Preprocessing Script
Preprocess Script->>API: Modify OpenAPI Specification
Preprocess Script->>SDK: Generate SDK from Modified Spec
SDK->>User: Provide SDK
TipsChatThere are 3 ways to chat with CodeRabbit:
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 as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
Your org has enabled the Graphite merge queue for merging into mainAdd the label “graphite/merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #794 +/- ##
==========================================
- Coverage 60.53% 60.52% -0.02%
==========================================
Files 143 143
Lines 7265 7268 +3
==========================================
+ Hits 4398 4399 +1
- Misses 2414 2416 +2
Partials 453 453
|
…se keys to be nullable
NOTE: this is a breaking change in /tx/persona/create-persona and /tx/game/{txName}.
cardinal clients, e.g. the cardinal editor, will need to be updated
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post
Actionable comments posted: 78
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files ignored due to path filters (2)
cardinal/sdk/typescript/package-lock.jsonis excluded by!**/package-lock.jsoncardinal/sdk/typescript/speakeasy_linux_amd64.zipis excluded by!**/*.zip,!**/*.zip
Files selected for processing (117)
- .github/workflows/ci-md.yaml (1 hunks)
- .github/workflows/sdk_generation.yaml (1 hunks)
- .github/workflows/sdk_publish.yaml (1 hunks)
- .markdownlintignore (1 hunks)
- .speakeasy/gen.yaml (1 hunks)
- .speakeasy/workflow.lock (1 hunks)
- .speakeasy/workflow.yaml (1 hunks)
- Makefile (2 hunks)
- cardinal/sdk/typescript/.eslintrc.cjs (1 hunks)
- cardinal/sdk/typescript/.gitattributes (1 hunks)
- cardinal/sdk/typescript/.gitignore (1 hunks)
- cardinal/sdk/typescript/.npmignore (1 hunks)
- cardinal/sdk/typescript/.speakeasy/gen.lock (1 hunks)
- cardinal/sdk/typescript/CONTRIBUTING.md (1 hunks)
- cardinal/sdk/typescript/FUNCTIONS.md (1 hunks)
- cardinal/sdk/typescript/README.md (1 hunks)
- cardinal/sdk/typescript/RUNTIMES.md (1 hunks)
- cardinal/sdk/typescript/USAGE.md (1 hunks)
- cardinal/sdk/typescript/docs/lib/utils/retryconfig.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/cqlqueryrequest.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/cqlqueryresponse.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/debugstateelement.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/entitystateelement.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/gethealthresponse.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/getreceiptsrequest.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/getreceiptsresponse.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/getworldresponse.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/receiptentry.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/result.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/txbody.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/txresponse.md (1 hunks)
- cardinal/sdk/typescript/docs/models/components/worldfielddetail.md (1 hunks)
- cardinal/sdk/typescript/docs/models/operations/createpersonaglobals.md (1 hunks)
- cardinal/sdk/typescript/docs/models/operations/queryrequest.md (1 hunks)
- cardinal/sdk/typescript/docs/models/operations/transactglobals.md (1 hunks)
- cardinal/sdk/typescript/docs/models/operations/transactrequest.md (1 hunks)
- cardinal/sdk/typescript/docs/sdks/cardinal/README.md (1 hunks)
- cardinal/sdk/typescript/jsr.json (1 hunks)
- cardinal/sdk/typescript/package.json (1 hunks)
- cardinal/sdk/typescript/src/core.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/createPersona.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/getDebugState.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/getHealth.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/getReceipts.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/getWorld.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/query.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/queryCQL.ts (1 hunks)
- cardinal/sdk/typescript/src/funcs/transact.ts (1 hunks)
- cardinal/sdk/typescript/src/hooks/cardinal.ts (1 hunks)
- cardinal/sdk/typescript/src/hooks/hooks.ts (1 hunks)
- cardinal/sdk/typescript/src/hooks/index.ts (1 hunks)
- cardinal/sdk/typescript/src/hooks/registration.ts (1 hunks)
- cardinal/sdk/typescript/src/hooks/sign.ts (1 hunks)
- cardinal/sdk/typescript/src/hooks/types.ts (1 hunks)
- cardinal/sdk/typescript/src/index.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/base64.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/config.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/dlv.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/encodings.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/http.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/is-plain-object.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/logger.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/matchers.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/primitives.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/retries.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/schemas.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/sdks.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/security.ts (1 hunks)
- cardinal/sdk/typescript/src/lib/url.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/cqlqueryrequest.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/cqlqueryresponse.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/debugstateelement.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/entitystateelement.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/gethealthresponse.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/getreceiptsrequest.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/getreceiptsresponse.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/getworldresponse.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/index.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/receiptentry.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/txbody.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/txresponse.ts (1 hunks)
- cardinal/sdk/typescript/src/models/components/worldfielddetail.ts (1 hunks)
- cardinal/sdk/typescript/src/models/errors/httpclienterrors.ts (1 hunks)
- cardinal/sdk/typescript/src/models/errors/index.ts (1 hunks)
- cardinal/sdk/typescript/src/models/errors/sdkerror.ts (1 hunks)
- cardinal/sdk/typescript/src/models/errors/sdkvalidationerror.ts (1 hunks)
- cardinal/sdk/typescript/src/models/operations/createpersona.ts (1 hunks)
- cardinal/sdk/typescript/src/models/operations/index.ts (1 hunks)
- cardinal/sdk/typescript/src/models/operations/query.ts (1 hunks)
- cardinal/sdk/typescript/src/models/operations/transact.ts (1 hunks)
- cardinal/sdk/typescript/src/sdk/index.ts (1 hunks)
- cardinal/sdk/typescript/src/sdk/sdk.ts (1 hunks)
- cardinal/sdk/typescript/src/types/blobs.ts (1 hunks)
- cardinal/sdk/typescript/src/types/constdatetime.ts (1 hunks)
- cardinal/sdk/typescript/src/types/enums.ts (1 hunks)
- cardinal/sdk/typescript/src/types/fp.ts (1 hunks)
- cardinal/sdk/typescript/src/types/index.ts (1 hunks)
- cardinal/sdk/typescript/src/types/operations.ts (1 hunks)
- cardinal/sdk/typescript/src/types/rfcdate.ts (1 hunks)
- cardinal/sdk/typescript/tsconfig.json (1 hunks)
- cardinal/server/docs/docs.go (13 hunks)
- cardinal/server/docs/openapi.json (1 hunks)
- cardinal/server/docs/swagger.json (13 hunks)
- cardinal/server/docs/swagger.yaml (12 hunks)
- cardinal/server/handler/cql.go (2 hunks)
- cardinal/server/handler/debug.go (1 hunks)
- cardinal/server/handler/health.go (1 hunks)
- cardinal/server/handler/query.go (1 hunks)
- cardinal/server/handler/receipts.go (2 hunks)
- cardinal/server/handler/tx.go (3 hunks)
- cardinal/server/handler/world.go (1 hunks)
- cardinal/types/entity.go (1 hunks)
- cardinal/world.go (1 hunks)
- makefiles/api.mk (1 hunks)
- makefiles/test.mk (1 hunks)
- scripts/post-speakeasy.sh (1 hunks)
- scripts/pre-speakeasy.js (1 hunks)
Additional context used
Markdownlint
cardinal/sdk/typescript/docs/models/components/result.md
14-14: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/txresponse.md
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/operations/transactglobals.md
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/getreceiptsrequest.md
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/cqlqueryrequest.md
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/operations/createpersonaglobals.md
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/gethealthresponse.md
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/debugstateelement.md
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/entitystateelement.md
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/worldfielddetail.md
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/USAGE.md
2-2: null
First line in a file should be a top-level heading(MD041, first-line-heading, first-line-h1)
cardinal/sdk/typescript/docs/models/operations/queryrequest.md
21-21: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/txbody.md
22-22: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/RUNTIMES.md
15-15: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
16-16: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
17-17: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
18-18: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
19-19: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
20-20: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
cardinal/sdk/typescript/docs/models/components/cqlqueryresponse.md
13-13: Expected: 250; Actual: 333
Line length(MD013, line-length)
14-14: Expected: 250; Actual: 333
Line length(MD013, line-length)
15-15: Expected: 250; Actual: 333
Line length(MD013, line-length)
15-15: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/CONTRIBUTING.md
14-14: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
3-3: Expected: 250; Actual: 280
Line length(MD013, line-length)
cardinal/sdk/typescript/docs/models/operations/transactrequest.md
18-18: Expected: 250; Actual: 286
Line length(MD013, line-length)
19-19: Expected: 250; Actual: 286
Line length(MD013, line-length)
20-20: Expected: 250; Actual: 286
Line length(MD013, line-length)
21-21: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/receiptentry.md
18-18: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/getreceiptsresponse.md
13-13: Expected: 250; Actual: 285
Line length(MD013, line-length)
14-14: Expected: 250; Actual: 285
Line length(MD013, line-length)
15-15: Expected: 250; Actual: 285
Line length(MD013, line-length)
16-16: Expected: 250; Actual: 285
Line length(MD013, line-length)
17-17: Expected: 250; Actual: 285
Line length(MD013, line-length)
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/lib/utils/retryconfig.md
17-17: null
Multiple headings with the same content(MD024, no-duplicate-heading)
24-24: null
Files should end with a single newline character(MD047, single-trailing-newline)
9-9: Expected: 4; Actual: 5; Too many cells, extra data will be missing
Table column count(MD056, table-column-count)
cardinal/sdk/typescript/docs/models/components/getworldresponse.md
13-13: Expected: 250; Actual: 317
Line length(MD013, line-length)
14-14: Expected: 250; Actual: 317
Line length(MD013, line-length)
15-15: Expected: 250; Actual: 317
Line length(MD013, line-length)
16-16: Expected: 250; Actual: 317
Line length(MD013, line-length)
17-17: Expected: 250; Actual: 317
Line length(MD013, line-length)
18-18: Expected: 250; Actual: 317
Line length(MD013, line-length)
18-18: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/FUNCTIONS.md
5-5: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
107-107: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/README.md
309-309: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
310-310: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
311-311: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
312-312: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
313-313: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
314-314: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
315-315: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
316-316: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
187-187: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
336-336: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
337-337: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
189-189: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
318-318: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
112-112: Expected: 250; Actual: 273
Line length(MD013, line-length)
187-187: Expected: 250; Actual: 487
Line length(MD013, line-length)
326-326: null
Multiple top-level headings in the same document(MD025, single-title, single-h1)
115-115: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
148-148: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
305-305: Element: details
Inline HTML(MD033, no-inline-html)
307-307: Element: summary
Inline HTML(MD033, no-inline-html)
4-4: null
Images should have alternate text (alt text)(MD045, no-alt-text)
6-6: null
Images should have alternate text (alt text)(MD045, no-alt-text)
cardinal/sdk/typescript/docs/sdks/cardinal/README.md
90-90: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
158-158: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
226-226: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
305-305: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
378-378: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
457-457: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
530-530: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
73-73: Expected: 250; Actual: 709
Line length(MD013, line-length)
74-74: Expected: 250; Actual: 709
Line length(MD013, line-length)
76-76: Expected: 250; Actual: 709
Line length(MD013, line-length)
142-142: Expected: 250; Actual: 709
Line length(MD013, line-length)
143-143: Expected: 250; Actual: 709
Line length(MD013, line-length)
144-144: Expected: 250; Actual: 709
Line length(MD013, line-length)
210-210: Expected: 250; Actual: 709
Line length(MD013, line-length)
211-211: Expected: 250; Actual: 709
Line length(MD013, line-length)
212-212: Expected: 250; Actual: 709
Line length(MD013, line-length)
288-288: Expected: 250; Actual: 709
Line length(MD013, line-length)
289-289: Expected: 250; Actual: 709
Line length(MD013, line-length)
291-291: Expected: 250; Actual: 709
Line length(MD013, line-length)
361-361: Expected: 250; Actual: 709
Line length(MD013, line-length)
362-362: Expected: 250; Actual: 709
Line length(MD013, line-length)
364-364: Expected: 250; Actual: 709
Line length(MD013, line-length)
440-440: Expected: 250; Actual: 709
Line length(MD013, line-length)
441-441: Expected: 250; Actual: 709
Line length(MD013, line-length)
443-443: Expected: 250; Actual: 709
Line length(MD013, line-length)
513-513: Expected: 250; Actual: 709
Line length(MD013, line-length)
514-514: Expected: 250; Actual: 709
Line length(MD013, line-length)
516-516: Expected: 250; Actual: 709
Line length(MD013, line-length)
582-582: Expected: 250; Actual: 709
Line length(MD013, line-length)
583-583: Expected: 250; Actual: 709
Line length(MD013, line-length)
584-584: Expected: 250; Actual: 709
Line length(MD013, line-length)
95-95: null
Multiple headings with the same content(MD024, no-duplicate-heading)
112-112: null
Multiple headings with the same content(MD024, no-duplicate-heading)
140-140: null
Multiple headings with the same content(MD024, no-duplicate-heading)
148-148: null
Multiple headings with the same content(MD024, no-duplicate-heading)
152-152: null
Multiple headings with the same content(MD024, no-duplicate-heading)
163-163: null
Multiple headings with the same content(MD024, no-duplicate-heading)
180-180: null
Multiple headings with the same content(MD024, no-duplicate-heading)
208-208: null
Multiple headings with the same content(MD024, no-duplicate-heading)
216-216: null
Multiple headings with the same content(MD024, no-duplicate-heading)
220-220: null
Multiple headings with the same content(MD024, no-duplicate-heading)
231-231: null
Multiple headings with the same content(MD024, no-duplicate-heading)
253-253: null
Multiple headings with the same content(MD024, no-duplicate-heading)
286-286: null
Multiple headings with the same content(MD024, no-duplicate-heading)
295-295: null
Multiple headings with the same content(MD024, no-duplicate-heading)
299-299: null
Multiple headings with the same content(MD024, no-duplicate-heading)
310-310: null
Multiple headings with the same content(MD024, no-duplicate-heading)
329-329: null
Multiple headings with the same content(MD024, no-duplicate-heading)
359-359: null
Multiple headings with the same content(MD024, no-duplicate-heading)
368-368: null
Multiple headings with the same content(MD024, no-duplicate-heading)
372-372: null
Multiple headings with the same content(MD024, no-duplicate-heading)
383-383: null
Multiple headings with the same content(MD024, no-duplicate-heading)
405-405: null
Multiple headings with the same content(MD024, no-duplicate-heading)
438-438: null
Multiple headings with the same content(MD024, no-duplicate-heading)
447-447: null
Multiple headings with the same content(MD024, no-duplicate-heading)
451-451: null
Multiple headings with the same content(MD024, no-duplicate-heading)
462-462: null
Multiple headings with the same content(MD024, no-duplicate-heading)
481-481: null
Multiple headings with the same content(MD024, no-duplicate-heading)
511-511: null
Multiple headings with the same content(MD024, no-duplicate-heading)
520-520: null
Multiple headings with the same content(MD024, no-duplicate-heading)
524-524: null
Multiple headings with the same content(MD024, no-duplicate-heading)
535-535: null
Multiple headings with the same content(MD024, no-duplicate-heading)
552-552: null
Multiple headings with the same content(MD024, no-duplicate-heading)
580-580: null
Multiple headings with the same content(MD024, no-duplicate-heading)
588-588: null
Multiple headings with the same content(MD024, no-duplicate-heading)
592-592: null
Multiple headings with the same content(MD024, no-duplicate-heading)
Biome
cardinal/sdk/typescript/src/types/rfcdate.ts
[error] 30-30: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
[error] 36-36: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
[error] 35-35: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
cardinal/sdk/typescript/src/lib/dlv.ts
[error] 50-50: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
[error] 47-47: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
[error] 48-48: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
[error] 48-48: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
cardinal/sdk/typescript/src/hooks/cardinal.ts
[error] 35-35: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 38-38: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 38-38: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
cardinal/sdk/typescript/src/models/components/receiptentry.ts
[error] 7-7: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 20-20: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
cardinal/sdk/typescript/src/models/errors/sdkvalidationerror.ts
[error] 46-46: The assignment should not be in an expression.
The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.(lint/suspicious/noAssignInExpressions)
cardinal/sdk/typescript/src/hooks/sign.ts
[error] 4-4: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.(lint/style/useNodejsImportProtocol)
cardinal/sdk/typescript/src/lib/retries.ts
[error] 104-104: Use a regular expression literal instead of the RegExp constructor.
Regular expression literals avoid some escaping required in a string literal, and are easier to analyze statically.
Safe fix: Use a literal notation instead.(lint/complexity/useRegexLiterals)
[error] 160-160: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
[error] 164-164: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
scripts/pre-speakeasy.js
[error] 1-1: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.(lint/style/useNodejsImportProtocol)
[error] 85-86: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 89-90: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 97-98: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
cardinal/sdk/typescript/src/lib/http.ts
[error] 39-39: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 208-208: Use a regular expression literal instead of the RegExp constructor.
Regular expression literals avoid some escaping required in a string literal, and are easier to analyze statically.
Safe fix: Use a literal notation instead.(lint/complexity/useRegexLiterals)
cardinal/sdk/typescript/src/lib/sdks.ts
[error] 98-98: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
LanguageTool
cardinal/sdk/typescript/docs/lib/utils/retryconfig.md
[uncategorized] ~10-~10: You might be missing the article “the” here.
Context: ...ckoffStrategy](#backoffstrategy) | When strategy is "backoff", this configurates for the...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[uncategorized] ~11-~11: You might be missing the article “the” here.
Context: ...oolean*` | When strategy is "backoff", this determines whether o...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[style] ~11-~11: Consider shortening this phrase to just ‘whether’, unless you mean ‘regardless of whether’.
Context: ... strategy is "backoff", this determines whether or not to retry on connection errors. | `true...(WHETHER)
cardinal/sdk/typescript/FUNCTIONS.md
[uncategorized] ~11-~11: You might be missing the article “a” here.
Context: ...rs and response handlers. The result is dramatically smaller impact on the application's fin...(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~12-~12: A comma might be missing here.
Context: ...mpact on the application's final bundle size which grows very slowly as you use more...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
[grammar] ~15-~15: Use only “more” (without ‘more’) when you use the comparative.
Context: ...SDK class remains a valid and generally more more ergonomic option. Standalone functions ...(MOST_COMPARATIVE)
[style] ~78-~78: The word “because” means “for the reason that” and thus introduces redundancy.
Context: ...nd reason for this style of programming is because these functions will typically be used ...(REASON_IS_BECAUSE)
cardinal/sdk/typescript/README.md
[uncategorized] ~187-~187: Possible missing comma found.
Context: ...t can be used to log a nicely formatted string since validation errors can list many i...(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~187-~187: The infinitive “read” after “be” requires “to”. Did you mean “be difficult to read”?
Context: ...y issues and the plain error string may be difficult read when debugging. ```typescript import...(WOULD_BE_JJ_VB)
[duplication] ~241-~241: Possible typo: you repeated a word
Context: ...s how to use the"beforeRequest"hook to to add a custom header and a timeout to re...(ENGLISH_WORD_REPEAT_RULE)
[grammar] ~280-~280: The word “setup” is a noun. The verb is spelled with a space.
Context: ...gging [debug] --> ## Debugging You can setup your SDK to emit debug logs for SDK req...(NOUN_VERB_CONFUSION)
[style] ~337-~337: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ... look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of c...(FEEL_FREE_TO_STYLE_ME)
[uncategorized] ~337-~337: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...a PR or an issue with a proof of concept and we'll do our best to include it in a fu...(COMMA_COMPOUND_SENTENCE)
cardinal/sdk/typescript/docs/sdks/cardinal/README.md
[uncategorized] ~77-~77: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~145-~145: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~213-~213: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~292-~292: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~365-~365: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~444-~444: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~517-~517: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~585-~585: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
yamllint
cardinal/server/docs/swagger.yaml
[error] 229-229: wrong indentation: expected 8 but found 6
(indentation)
[error] 233-233: wrong indentation: expected 8 but found 6
(indentation)
[error] 245-245: wrong indentation: expected 8 but found 6
(indentation)
[error] 259-259: wrong indentation: expected 8 but found 6
(indentation)
checkov
cardinal/server/docs/openapi.json
[HIGH] 1-734: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[HIGH] 1-734: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[MEDIUM] 66-71: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
Additional comments not posted (365)
.markdownlintignore (1)
1-2: LGTM!The entries in the
.markdownlintignorefile are appropriate for ignoring vendor and SDK directories.The code changes are approved.
cardinal/sdk/typescript/.gitattributes (1)
1-2: LGTM!The entries in the
.gitattributesfile are appropriate for ensuring that TypeScript files are indexed correctly.The code changes are approved.
cardinal/sdk/typescript/.npmignore (1)
1-9: LGTM!The entries in the
.npmignorefile are appropriate for ensuring that unnecessary files are ignored by npm.The code changes are approved.
cardinal/sdk/typescript/src/sdk/index.ts (1)
1-5: LGTM!The file is correctly exporting the necessary modules and follows the standard practices for auto-generated code.
The code changes are approved.
cardinal/sdk/typescript/src/hooks/index.ts (1)
1-6: LGTM!The file is correctly exporting the necessary modules and follows the standard practices for auto-generated code.
The code changes are approved.
cardinal/sdk/typescript/src/index.ts (1)
1-6: LGTM!The file is correctly exporting the necessary modules and follows the standard practices for auto-generated code.
The code changes are approved.
cardinal/sdk/typescript/.gitignore (1)
1-16: LGTM!The
.gitignoreentries are appropriate for a TypeScript project and ensure that unnecessary files are not tracked by Git.The code changes are approved.
cardinal/sdk/typescript/src/models/operations/index.ts (1)
1-7: LGTM!The export statements are correctly formatted and ensure that the modules can be easily imported elsewhere in the project.
The code changes are approved.
cardinal/sdk/typescript/src/models/errors/index.ts (1)
1-7: LGTM!The export statements are correctly formatted and ensure that the modules can be easily imported elsewhere in the project.
The code changes are approved.
cardinal/sdk/typescript/src/lib/logger.ts (2)
1-3: LGTM!The comment block is standard for generated code.
The code changes are approved.
5-9: LGTM!The
Loggerinterface is correctly defined.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/result.md (1)
1-14: LGTM!The documentation for the
Resultmodel is clear and well-structured.The code changes are approved.
Tools
Markdownlint
14-14: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/types/entity.go (1)
9-9: LGTM!The modification to the
Datafield enhances the flexibility of the data structure.The code changes are approved.
cardinal/sdk/typescript/src/types/constdatetime.ts (1)
1-6: LGTM!The file header and import statement are correct.
The code changes are approved.
.speakeasy/workflow.yaml (1)
1-16: LGTM! Ensure secure management of npm token.The workflow configuration is correct and follows standard practices. Ensure that the npm token is securely managed.
The code changes are approved.
cardinal/sdk/typescript/src/types/index.ts (1)
1-11: LGTM!The file header and export statements are correct.
The code changes are approved.
cardinal/sdk/typescript/src/core.ts (2)
1-6: LGTM!The file header and import statement are correct.
The code changes are approved.
7-13: LGTM!The class
CardinalCoreis correctly implemented and follows the intended design.The code changes are approved.
.github/workflows/sdk_publish.yaml (2)
1-6: LGTM!The file header and permissions are correctly set.
The code changes are approved.
7-20: LGTM!The workflow triggers and job configuration are correct and follow best practices.
The code changes are approved.
cardinal/sdk/typescript/src/types/enums.ts (3)
1-7: LGTM!The file header and type declarations are correct.
The code changes are approved.
8-10: LGTM!The function
catchUnrecognizedEnumis correctly implemented and follows the intended design.The code changes are approved.
12-16: LGTM!The type declarations for
ClosedEnumandOpenEnumare correct and follow the intended design.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/txresponse.md (2)
3-9: LGTM!The example usage is clear and correctly demonstrates how to import and instantiate
TxResponse.The code changes are approved.
11-16: LGTM!The fields section is clear and correctly lists the fields for
TxResponse.The code changes are approved.
Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/operations/transactglobals.md (2)
3-9: LGTM!The example usage is clear and correctly demonstrates how to import and instantiate
TransactGlobals.The code changes are approved.
11-16: LGTM!The fields section is clear and correctly lists the fields for
TransactGlobals.The code changes are approved.
Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/getreceiptsrequest.md (2)
3-10: LGTM!The example usage is clear and correctly demonstrates how to import and instantiate
GetReceiptsRequest.The code changes are approved.
13-17: LGTM!The fields section is clear and correctly lists the fields for
GetReceiptsRequest.The code changes are approved.
Tools
Markdownlint
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/cqlqueryrequest.md (2)
3-11: Example usage is clear and correct.The example usage section correctly demonstrates how to use the
CQLQueryRequestmodel.The code changes are approved.
13-17: Fields section is clear and correct.The fields section correctly describes the fields of the
CQLQueryRequestmodel.The code changes are approved.
Tools
Markdownlint
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/operations/createpersonaglobals.md (2)
3-9: Example usage is clear and correct.The example usage section correctly demonstrates how to use the
CreatePersonaGlobalsmodel.The code changes are approved.
11-16: Fields section is clear and correct.The fields section correctly describes the fields of the
CreatePersonaGlobalsmodel.The code changes are approved.
Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/src/models/components/index.ts (12)
5-5: Export statement forcqlqueryrequest.jsis correct.The export statement correctly exports the
cqlqueryrequest.jsmodule.The code changes are approved.
6-6: Export statement forcqlqueryresponse.jsis correct.The export statement correctly exports the
cqlqueryresponse.jsmodule.The code changes are approved.
7-7: Export statement fordebugstateelement.jsis correct.The export statement correctly exports the
debugstateelement.jsmodule.The code changes are approved.
8-8: Export statement forentitystateelement.jsis correct.The export statement correctly exports the
entitystateelement.jsmodule.The code changes are approved.
9-9: Export statement forgethealthresponse.jsis correct.The export statement correctly exports the
gethealthresponse.jsmodule.The code changes are approved.
10-10: Export statement forgetreceiptsrequest.jsis correct.The export statement correctly exports the
getreceiptsrequest.jsmodule.The code changes are approved.
11-11: Export statement forgetreceiptsresponse.jsis correct.The export statement correctly exports the
getreceiptsresponse.jsmodule.The code changes are approved.
12-12: Export statement forgetworldresponse.jsis correct.The export statement correctly exports the
getworldresponse.jsmodule.The code changes are approved.
13-13: Export statement forreceiptentry.jsis correct.The export statement correctly exports the
receiptentry.jsmodule.The code changes are approved.
14-14: Export statement fortxbody.jsis correct.The export statement correctly exports the
txbody.jsmodule.The code changes are approved.
15-15: Export statement fortxresponse.jsis correct.The export statement correctly exports the
txresponse.jsmodule.The code changes are approved.
16-16: Export statement forworldfielddetail.jsis correct.The export statement correctly exports the
worldfielddetail.jsmodule.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/gethealthresponse.md (2)
3-9: LGTM!The example usage section is clear and correct.
The code changes are approved.
11-16: LGTM!The fields section is clear and correct.
The code changes are approved.
Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/debugstateelement.md (2)
3-9: LGTM!The example usage section is clear and correct.
The code changes are approved.
11-16: LGTM!The fields section is clear and correct.
The code changes are approved.
Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
scripts/post-speakeasy.sh (3)
3-4: LGTM!The sed command for
privateKeyis correct and necessary for the configuration change.The code changes are approved.
6-7: LGTM!The sed command for
namespaceis correct and necessary for the configuration change.The code changes are approved.
9-10: LGTM!The sed command for
serverURLis correct and necessary for the configuration change.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/entitystateelement.md (1)
3-9: LGTM!The example usage is clear and correctly demonstrates how to import and use the
EntityStateElement.The code changes are approved.
cardinal/sdk/typescript/jsr.json (3)
3-5: LGTM!The metadata section is correctly formatted and provides necessary information about the SDK.
The code changes are approved.
6-16: LGTM!The export paths are correctly defined and follow a logical structure.
The code changes are approved.
17-26: LGTM!The publish configuration is correctly defined and includes all necessary files and directories.
The code changes are approved.
cardinal/sdk/typescript/package.json (4)
1-5: LGTM!The metadata section is correctly formatted and provides necessary information about the SDK.
The code changes are approved.
7-10: LGTM!The scripts section is correctly defined and includes necessary scripts for the SDK.
The code changes are approved.
12-24: LGTM!The dependencies section is correctly defined and includes necessary dependencies for the SDK.
The code changes are approved.
25-27: LGTM!The dependencies section is correctly defined and includes necessary dependencies for the SDK.
The code changes are approved.
cardinal/sdk/typescript/src/hooks/registration.ts (2)
1-2: LGTM!The imports are appropriate for the functionality provided in the file.
The code changes are approved.
4-8: LGTM!The comment block is informative and provides clear instructions for future modifications.
The code changes are approved.
cardinal/sdk/typescript/.eslintrc.cjs (3)
1-3: LGTM!The environment setting and module exports are appropriate for a Node.js project.
The code changes are approved.
4-11: LGTM!The extends and parser settings are appropriate for a TypeScript project.
The code changes are approved.
12-27: LGTM! But consider reviewing the turned-off rules.The plugins, settings, and rules are appropriate for the project. However, some rules are turned off, which might lead to potential issues.
Consider reviewing the turned-off rules to ensure they do not lead to potential issues:
"@typescript-eslint/no-unused-vars": "off", // Consider turning this on to avoid unused variables "@typescript-eslint/ban-types": "off", // Consider turning this on to avoid banned types "@typescript-eslint/no-namespace": "off", // Consider turning this on to avoid namespaces "@typescript-eslint/no-explicit-any": "off", // Consider turning this on to avoid using 'any' type "import/no-named-as-default-member": "off", // Consider turning this on to avoid naming conflictscardinal/server/handler/health.go (2)
Line range hint
1-8: LGTM!The imports and type definition are appropriate for the functionality provided in the file.
The code changes are approved.
Line range hint
9-19: LGTM!The function is correctly implemented, and the
@Idannotation improves the API documentation.The code changes are approved.
cardinal/sdk/typescript/src/types/blobs.ts (1)
13-30: LGTM!The function is correctly implemented.
The code changes are approved.
cardinal/server/handler/debug.go (1)
18-18: LGTM!The new annotation enhances the documentation and the function is correctly implemented.
The code changes are approved.
cardinal/sdk/typescript/USAGE.md (2)
2-20: LGTM!The example for creating a persona is clear and well-structured.
The code changes are approved.
Tools
Markdownlint
2-2: null
First line in a file should be a top-level heading(MD041, first-line-heading, first-line-h1)
22-43: LGTM!The example for executing a query is clear and well-structured.
The code changes are approved.
cardinal/sdk/typescript/docs/models/operations/queryrequest.md (1)
16-21: LGTM!The fields section is clear, well-organized, and informative.
The code changes are approved.
Tools
Markdownlint
21-21: null
Files should end with a single newline character(MD047, single-trailing-newline)
.github/workflows/sdk_generation.yaml (3)
1-6: LGTM!The
nameandpermissionssections are correctly configured.The code changes are approved.
7-21: LGTM!The
onsection is correctly configured to trigger the workflow onworkflow_dispatch,schedule, andpushevents.The code changes are approved.
22-33: LGTM!The
jobssection is correctly configured for generating and publishing SDKs.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/txbody.md (2)
1-11: LGTM!The
Example Usagesection is clear and correctly demonstrates how to use theTxBodymodel.The code changes are approved.
13-22: LGTM!The
Fieldssection is clear and correctly documents the fields of theTxBodymodel.The code changes are approved.
Tools
Markdownlint
22-22: null
Files should end with a single newline character(MD047, single-trailing-newline)
.github/workflows/ci-md.yaml (1)
37-38: LGTM!The change optimizes the linting process by focusing only on relevant files.
The code changes are approved.
cardinal/sdk/typescript/src/lib/base64.ts (8)
7-8: LGTM!The function is correctly implemented.
The code changes are approved.
11-12: LGTM!The function is correctly implemented.
The code changes are approved.
15-16: LGTM!The function is correctly implemented.
The code changes are approved.
19-20: LGTM!The function is correctly implemented.
The code changes are approved.
23-24: LGTM!The function is correctly implemented.
The code changes are approved.
27-28: LGTM!The function is correctly implemented.
The code changes are approved.
31-33: LGTM!The schema is correctly implemented.
The code changes are approved.
35-37: LGTM!The schema is correctly implemented.
The code changes are approved.
cardinal/sdk/typescript/tsconfig.json (8)
2-3: Enable incremental compilationThe
incrementaloption is set totrue, which speeds up subsequent compilations by using information from previous compilations.The code changes are approved.
4-4: Specify build info fileThe
tsBuildInfoFileoption specifies the location of the incremental build information file.The code changes are approved.
5-6: Set target and library versionsThe
targetis set toES2018, and thelibincludesES2022,DOM, andDOM.Iterable, ensuring compatibility with modern JavaScript features and browser APIs.The code changes are approved.
8-9: Configure module systemThe
moduleandmoduleResolutionoptions are set toNode16, aligning with the Node.js module system.The code changes are approved.
11-11: Allow JavaScript filesThe
allowJsoption is set totrue, enabling the inclusion of JavaScript files in the project.The code changes are approved.
13-15: Generate declaration and source mapsThe
declaration,declarationMap, andsourceMapoptions are enabled, facilitating type declaration files and source maps for easier debugging.The code changes are approved.
19-36: Enable strict type-checking optionsThe configuration includes various strict type-checking options, ensuring robust type safety and code quality.
The code changes are approved.
38-39: Include and exclude pathsThe
includeandexcludeoptions specify the directories to include and exclude during compilation, ensuring only relevant files are processed.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/cqlqueryresponse.md (1)
1-9: Example Usage is clearThe example usage section provides a clear and correct demonstration of how to use the
CQLQueryResponsemodel.The code changes are approved.
cardinal/server/handler/cql.go (2)
11-11: Example tag enhances clarityThe addition of the
exampletag to theCQLfield enhances the clarity and usability of the API by providing a concrete example of how to structure queries.The code changes are approved.
22-22:@Idannotation enhances documentationThe addition of the
@Idannotation to the documentation for the CQL query execution function serves as a unique identifier for the endpoint, which can be useful for documentation generation and API management tools.The code changes are approved.
.speakeasy/workflow.lock (3)
1-1: LGTM!The version specification is correct and necessary for reproducibility.
The code changes are approved.
2-8: LGTM!The source details are correctly specified, including namespace, revision digest, and blob digest.
The code changes are approved.
9-32: LGTM!The target details and workflow configuration are correctly specified, including output location, workflow version, and publishing details.
The code changes are approved.
.speakeasy/gen.yaml (4)
1-7: LGTM!The configuration version and generation details are correctly specified, including SDK class name, OpenAPI order maintenance, and usage snippets.
The code changes are approved.
8-13: LGTM!The fixes and authentication details are correctly specified, including OAuth2 client credentials.
The code changes are approved.
14-42: LGTM!The TypeScript configuration details are correctly specified, including version, dependencies, and package name.
The code changes are approved.
43-43: LGTM!The use of index modules is correctly specified.
The code changes are approved.
cardinal/sdk/typescript/src/models/components/cqlqueryrequest.ts (5)
1-3: LGTM!The header comment is correct and necessary to indicate that the code is auto-generated.
The code changes are approved.
5-5: LGTM!The import statement is correct and necessary for schema validation.
The code changes are approved.
7-9: LGTM!The type definition is correct and necessary for representing the CQL query request.
The code changes are approved.
11-15: LGTM!The schema definition is correct and necessary for validating the inbound CQL query request.
The code changes are approved.
31-41: LGTM!The namespace definition is correct and necessary for backward compatibility.
The code changes are approved.
cardinal/sdk/typescript/src/lib/primitives.ts (1)
1-40: LGTM!The function is well-implemented and follows TypeScript best practices. The JSDoc comment is clear and provides sufficient detail.
The code changes are approved.
cardinal/sdk/typescript/CONTRIBUTING.md (1)
1-26: LGTM!The file is well-written and provides clear guidelines for contributing to the repository. The instructions for reporting issues are detailed and helpful. The contact section provides a way for contributors to seek further assistance.
The code changes are approved.
Tools
Markdownlint
14-14: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
3-3: Expected: 250; Actual: 280
Line length(MD013, line-length)
cardinal/sdk/typescript/src/models/components/txresponse.ts (5)
7-10: LGTM!The type
TxResponseis well-defined and follows TypeScript best practices.The code changes are approved.
12-16: LGTM!The schema
TxResponse$inboundSchemais well-defined and follows Zod best practices. The internal marking indicates that it is not intended for public use.The code changes are approved.
19-22: LGTM!The type
TxResponse$Outboundis well-defined and follows TypeScript best practices. The internal marking indicates that it is not intended for public use.The code changes are approved.
24-29: LGTM!The schema
TxResponse$outboundSchemais well-defined and follows Zod best practices. The internal marking indicates that it is not intended for public use.The code changes are approved.
31-42: LGTM!The namespace
TxResponse$provides backward compatibility for deprecated schemas and types. The internal and deprecated markings indicate that it is not intended for public use and will be removed in future versions.The code changes are approved.
cardinal/sdk/typescript/src/models/components/getreceiptsrequest.ts (4)
1-6: LGTM!The file header and imports are appropriate and follow standard practices.
The code changes are approved.
7-9: LGTM!The type definition for
GetReceiptsRequestis clear and follows TypeScript conventions.The code changes are approved.
11-18: LGTM!The schema definitions for
GetReceiptsRequestare correct and follow best practices for schema validation.The code changes are approved.
Also applies to: 20-32
34-45: LGTM!The deprecation notice and backward compatibility for the namespace
GetReceiptsRequest$are handled appropriately.The code changes are approved.
cardinal/sdk/typescript/docs/models/operations/transactrequest.md (1)
1-14: LGTM!The file header and example usage for
TransactRequestare clear and informative.The code changes are approved.
cardinal/sdk/typescript/src/types/rfcdate.ts (3)
1-6: LGTM!The file header and regex definition are appropriate and follow standard practices.
The code changes are approved.
47-49: LGTM!The
toJSONmethod is correctly implemented.The code changes are approved.
51-53: LGTM!The
toStringmethod is correctly implemented.The code changes are approved.
Makefile (1)
20-24: LGTM!The new section header and inclusion of
makefiles/api.mkimprove the organization and readability of theMakefile.The code changes are approved.
cardinal/sdk/typescript/src/models/components/debugstateelement.ts (1)
1-46: LGTM!The code is well-structured and follows best practices for defining types and schemas. The deprecated namespaces and types are clearly marked.
The code changes are approved.
cardinal/sdk/typescript/src/types/fp.ts (5)
14-16: LGTM!The
Resulttype is correctly defined and follows the pattern of railway-oriented programming.The code changes are approved.
18-20: LGTM!The
OKfunction is correctly implemented.The code changes are approved.
22-24: LGTM!The
ERRfunction is correctly implemented.The code changes are approved.
30-34: LGTM!The
unwrapfunction is correctly implemented.The code changes are approved.
41-49: LGTM!The
unwrapAsyncfunction is correctly implemented.The code changes are approved.
cardinal/sdk/typescript/src/models/components/entitystateelement.ts (3)
7-10: LGTM!The
EntityStateElementtype is correctly defined.The code changes are approved.
13-20: LGTM!The
EntityStateElement$inboundSchemaschema is correctly defined using thezodlibrary.The code changes are approved.
29-36: LGTM!The
EntityStateElement$outboundSchemaschema is correctly defined using thezodlibrary.The code changes are approved.
cardinal/sdk/typescript/src/models/components/gethealthresponse.ts (3)
7-10: LGTM!The
GetHealthResponsetype is correctly defined.The code changes are approved.
13-17: LGTM!The
GetHealthResponse$inboundSchemaschema is correctly defined using thezodlibrary.The code changes are approved.
26-33: LGTM!The
GetHealthResponse$outboundSchemaschema is correctly defined using thezodlibrary.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/getreceiptsresponse.md (1)
1-9: LGTM!The example usage section is clear and correct.
The code changes are approved.
cardinal/sdk/typescript/src/models/components/cqlqueryresponse.ts (3)
13-15: LGTM!The type definitions are clear and correct.
The code changes are approved.
Also applies to: 24-26
18-21: LGTM!The schemas are clear and correct.
The code changes are approved.
Also applies to: 29-35
37-47: LGTM!The deprecated namespaces and types are clearly marked and provide alternatives.
The code changes are approved.
cardinal/sdk/typescript/src/models/components/worldfielddetail.ts (4)
1-6: LGTM!The file header and imports are appropriate and necessary.
The code changes are approved.
7-17: LGTM!The
WorldFieldDetailtype definition is clear and aligns with TypeScript best practices.The code changes are approved.
19-25: LGTM!The
WorldFieldDetail$inboundSchemaandWorldFieldDetail$outboundSchemaare well-defined and provide necessary validation.The code changes are approved.
Also applies to: 27-43
45-56: LGTM!The deprecated namespace
WorldFieldDetail$is necessary for backward compatibility and is appropriately marked for future removal.The code changes are approved.
cardinal/sdk/typescript/src/lib/is-plain-object.ts (2)
1-26: LGTM!The file header and license are appropriate and necessary.
The code changes are approved.
28-43: LGTM!The
isPlainObjectfunction is well-implemented and properly credited to the original author.The code changes are approved.
cardinal/sdk/typescript/src/models/operations/query.ts (4)
1-6: LGTM!The file header and imports are appropriate and necessary.
The code changes are approved.
8-17: LGTM!The
QueryRequesttype definition is clear and aligns with TypeScript best practices.The code changes are approved.
19-29: LGTM!The
QueryRequest$inboundSchemaandQueryRequest$outboundSchemaare well-defined and provide necessary validation. The use of thetransformmethod for field remapping is appropriate.The code changes are approved.
Also applies to: 31-51
53-64: LGTM!The deprecated namespace
QueryRequest$is necessary for backward compatibility and is appropriately marked for future removal.The code changes are approved.
cardinal/sdk/typescript/src/models/errors/httpclienterrors.ts (5)
30-32: LGTM!The class is correctly implemented.
37-39: LGTM!The class is correctly implemented.
44-46: LGTM!The class is correctly implemented.
52-54: LGTM!The class is correctly implemented.
60-62: LGTM!The class is correctly implemented.
cardinal/sdk/typescript/src/lib/config.ts (3)
5-8: LGTM!The imports are necessary for the functionality of the file.
10-41: LGTM!The
ServerListandSDKOptionsare correctly defined.
60-65: LGTM!The
SDK_METADATAis correctly defined.makefiles/api.mk (6)
5-9: LGTM!The
swaggo-installtarget is correctly implemented.
11-14: LGTM!The
swaggertarget is correctly implemented.
15-30: LGTM!The
swagger-checktarget is correctly implemented.
49-55: LGTM!The
swagger-codegentarget is correctly implemented.
57-60: LGTM!The
speakeasytarget is correctly implemented.
40-47: Consider using a specific version for theswagger-codegenCLI tool.Using a specific version ensures consistency and avoids potential issues with future versions.
wget https://repo1.maven.org/maven2/io/swagger/codegen/v3/swagger-codegen-cli/3.0.57/swagger-codegen-cli-3.0.57.jar -O swagger-codegen-cli.jar echo '#!/usr/bin/java -jar' > swagger-codegen cat swagger-codegen-cli.jar >> swagger-codegen chmod +x swagger-codegen mv swagger-codegen ~/.local/bin/ rm swagger-codegen-cli.jarLikely invalid or redundant comment.
cardinal/server/handler/query.go (1)
36-51: LGTM!The function
PostGameQueryis correctly implemented and enhances the API by providing a specific endpoint for game-related queries.The code changes are approved.
cardinal/sdk/typescript/src/models/operations/createpersona.ts (2)
8-11: LGTM!The type
CreatePersonaGlobalsis correctly defined.The code changes are approved.
13-63: LGTM!The schemas
CreatePersonaGlobals$inboundSchemaandCreatePersonaGlobals$outboundSchemaare correctly defined.The code changes are approved.
cardinal/sdk/typescript/src/models/components/getreceiptsresponse.ts (5)
1-12: LGTM!The file header and imports are appropriate.
The code changes are approved.
13-17: LGTM!The type definition for
GetReceiptsResponseis clear and appropriate.The code changes are approved.
19-28: LGTM!The schema definition for
GetReceiptsResponse$inboundSchemais correct and matches the type definition.The code changes are approved.
30-35: LGTM!The type definition for
GetReceiptsResponse$Outboundis clear and appropriate.The code changes are approved.
37-59: LGTM!The schema definition for
GetReceiptsResponse$outboundSchemaand the deprecated namespaceGetReceiptsResponse$are correct and match the type definition.The code changes are approved.
cardinal/sdk/typescript/src/models/components/txbody.ts (5)
1-6: LGTM!The file header and imports are appropriate.
The code changes are approved.
7-20: LGTM!The type definition for
TxBodyis clear and appropriate.The code changes are approved.
22-30: LGTM!The schema definition for
TxBody$inboundSchemais correct and matches the type definition.The code changes are approved.
32-39: LGTM!The type definition for
TxBody$Outboundis clear and appropriate.The code changes are approved.
42-62: LGTM!The schema definition for
TxBody$outboundSchemaand the deprecated namespaceTxBody$are correct and match the type definition.The code changes are approved.
cardinal/sdk/typescript/docs/models/components/getworldresponse.md (1)
1-9: LGTM!The file header and example usage are clear and appropriate.
The code changes are approved.
cardinal/server/handler/world.go (1)
26-26: LGTM!The annotation
@Id getWorldenhances the documentation and is correctly placed.The code changes are approved.
cardinal/sdk/typescript/src/lib/schemas.ts (3)
14-23: LGTM!The function
parsecorrectly handles Zod errors and converts them toSDKValidationError.The code changes are approved.
30-40: LGTM!The function
safeParsecorrectly handles Zod errors and returns aResulttype.The code changes are approved.
42-74: LGTM!The function
collectExtraKeyscorrectly handles extra keys in a Zod object.The code changes are approved.
cardinal/sdk/typescript/src/models/components/getworldresponse.ts (4)
13-21: LGTM!The type
GetWorldResponseis correctly defined with optional properties.The code changes are approved.
23-31: LGTM!The schema
GetWorldResponse$inboundSchemais correctly defined using Zod.The code changes are approved.
40-50: LGTM!The schema
GetWorldResponse$outboundSchemais correctly defined using Zod.The code changes are approved.
52-63: LGTM!The namespace
GetWorldResponse$is correctly defined with deprecated properties clearly marked.The code changes are approved.
makefiles/test.mk (1)
Line range hint
1-100: Verify the project's documentation strategy.The removal of Swagger-related targets suggests a shift away from automated Swagger specification generation and validation processes. Ensure that the removal aligns with the project's documentation strategy.
Do you want me to open a GitHub issue to track the project's new documentation strategy?
cardinal/sdk/typescript/src/types/operations.ts (6)
7-7: LGTM!The type is correctly defined.
The code changes are approved.
9-12: LGTM!The type is correctly defined.
The code changes are approved.
14-36: LGTM!The function is correctly implemented.
The code changes are approved.
43-51: LGTM!The function is correctly implemented.
The code changes are approved.
57-78: LGTM!The function is correctly implemented.
The code changes are approved.
80-99: LGTM!The function is correctly implemented.
The code changes are approved.
cardinal/sdk/typescript/src/models/components/receiptentry.ts (8)
9-14: LGTM!The type definition is correct and follows best practices.
The code changes are approved.
17-17: LGTM! But update the schema if theResulttype is updated.The schema definition is correct but should be updated if the
Resulttype is updated.The code changes are approved.
23-23: LGTM! But update the schema if theResult$Outboundtype is updated.The schema definition is correct but should be updated if the
Result$Outboundtype is updated.The code changes are approved.
29-35: LGTM!The deprecation notice is clear and follows best practices.
The code changes are approved.
39-44: LGTM!The schema definition is correct and follows best practices.
The code changes are approved.
47-52: LGTM!The type definition is correct and follows best practices.
The code changes are approved.
55-64: LGTM!The schema definition is correct and follows best practices.
The code changes are approved.
70-76: LGTM!The deprecation notice is clear and follows best practices.
The code changes are approved.
cardinal/sdk/typescript/src/funcs/getHealth.ts (1)
1-94: LGTM! But ensure all possible errors are handled correctly.The function is well-structured and follows best practices. However, it is important to ensure that all possible errors are handled correctly.
The code changes are approved.
cardinal/sdk/typescript/src/funcs/getWorld.ts (1)
1-94: LGTM! But ensure all possible errors are handled correctly.The function is well-structured and follows best practices. However, it is important to ensure that all possible errors are handled correctly.
The code changes are approved.
cardinal/server/handler/receipts.go (4)
10-10: LGTM!The addition of the
exampleattribute enhances the clarity of the API documentation.The code changes are approved.
20-20: LGTM!The addition of the
extensions:"x-nullable"annotation clarifies the potential absence of receipts in the response.The code changes are approved.
28-28: LGTM!The addition of the
extensions:"x-nullable"annotation clarifies the potential absence of errors in the response.The code changes are approved.
35-35: LGTM!The addition of the
@Idannotation enhances the documentation and usability of the API.The code changes are approved.
cardinal/sdk/typescript/src/hooks/hooks.ts (1)
33-35: LGTM!The methods for registering hooks are correctly implemented.
The code changes are approved.
Also applies to: 37-39, 41-43, 45-47, 49-51
cardinal/sdk/typescript/src/hooks/types.ts (10)
7-11: LGTM!The
HookContexttype is correctly defined.The code changes are approved.
13-13: LGTM!The
Awaitabletype is correctly defined.The code changes are approved.
15-18: LGTM!The
SDKInitOptionstype is correctly defined.The code changes are approved.
20-23: LGTM!The context types extending
HookContextare correctly defined.The code changes are approved.
25-31: LGTM!The
SDKInitHookinterface is correctly defined.The code changes are approved.
33-40: LGTM!The
BeforeCreateRequestHookinterface is correctly defined.The code changes are approved.
42-49: LGTM!The
BeforeRequestHookinterface is correctly defined.The code changes are approved.
52-59: LGTM!The
AfterSuccessHookinterface is correctly defined.The code changes are approved.
62-75: LGTM!The
AfterErrorHookinterface is correctly defined.The code changes are approved.
78-88: LGTM!The
Hooksinterface is correctly defined.The code changes are approved.
cardinal/sdk/typescript/src/hooks/sign.ts (9)
10-29: LGTM!The types related to signing are correctly defined.
The code changes are approved.
31-38: LGTM!The
isHexfunction is correctly implemented.The code changes are approved.
40-43: LGTM!The
size_function is correctly implemented.The code changes are approved.
45-48: LGTM!The
assertSizefunction is correctly implemented.The code changes are approved.
50-63: LGTM!The
hexToBigIntfunction is correctly implemented.The code changes are approved.
65-71: LGTM!The
signatureToHexfunction is correctly implemented.The code changes are approved.
74-81: LGTM!The
signfunction is correctly implemented.The code changes are approved.
87-89: LGTM!The
customSignfunction is correctly implemented.The code changes are approved.
92-95: LGTM!The
createMsgToSignfunction is correctly implemented.The code changes are approved.
cardinal/sdk/typescript/src/sdk/sdk.ts (8)
25-30: LGTM!The
queryCQLmethod is correctly implemented.The code changes are approved.
38-39: LGTM!The
getDebugStatemethod is correctly implemented.The code changes are approved.
48-49: LGTM!The
getHealthmethod is correctly implemented.The code changes are approved.
58-62: LGTM!The
querymethod is correctly implemented.The code changes are approved.
71-75: LGTM!The
getReceiptsmethod is correctly implemented.The code changes are approved.
84-88: LGTM!The
transactmethod is correctly implemented.The code changes are approved.
97-101: LGTM!The
createPersonamethod is correctly implemented.The code changes are approved.
110-111: LGTM!The
getWorldmethod is correctly implemented.The code changes are approved.
cardinal/sdk/typescript/src/funcs/createPersona.ts (9)
5-23: Imports and DependenciesThe imports and dependencies are well-organized and necessary for the function's operations.
The code changes are approved.
32-36: Function SignatureThe function signature is clear and well-defined, with appropriate types for parameters and return value.
The code changes are approved.
48-54: Input ValidationThe input validation using
schemas$.safeParseis correctly implemented. However, ensure that thecomponents.TxBody$outboundSchemais correctly defined and handles all necessary validation rules.Verify the correctness of
components.TxBody$outboundSchemadefinition to ensure comprehensive validation.
61-66: Request Path and Query ParametersThe request path and query parameters are correctly constructed. Ensure that
client$.options$.namespaceandclient$.options$.privateKeyare correctly set and used.Verify the correctness of
client$.options$.namespaceandclient$.options$.privateKeyvalues.
68-71: Request HeadersThe request headers are correctly set for JSON content.
The code changes are approved.
73-86: Request CreationThe request creation using
client$.createRequest$is correctly implemented. Ensure that thecontextandoptionsare correctly defined and used.Verify the correctness of
contextandoptionsvalues used inclient$.createRequest$.
92-97: Request Execution and Error HandlingThe request execution and error handling using
client$.do$are correctly implemented. Ensure that theerrorCodesandretryCodesare comprehensive and cover all necessary cases.Verify the comprehensiveness of
errorCodesandretryCodesvalues used inclient$.do$.
103-115: Response MatchingThe response matching using
m$.matchis correctly implemented. Ensure thatcomponents.TxResponse$inboundSchemais correctly defined and handles all necessary response validation rules.Verify the correctness of
components.TxResponse$inboundSchemadefinition to ensure comprehensive response validation.
120-120: Return StatementThe return statement correctly returns the result of the response matching.
The code changes are approved.
cardinal/sdk/typescript/src/funcs/query.ts (9)
5-22: Imports and DependenciesThe imports and dependencies are well-organized and necessary for the function's operations.
The code changes are approved.
30-34: Function SignatureThe function signature is clear and well-defined, with appropriate types for parameters and return value.
The code changes are approved.
46-52: Input ValidationThe input validation using
schemas$.safeParseis correctly implemented. However, ensure that theoperations.QueryRequest$outboundSchemais correctly defined and handles all necessary validation rules.Verify the correctness of
operations.QueryRequest$outboundSchemadefinition to ensure comprehensive validation.
59-64: Request Path and Query ParametersThe request path and query parameters are correctly constructed. Ensure that
queryNameis correctly encoded and used.Verify the correctness of
queryNameencoding and usage.
68-71: Request HeadersThe request headers are correctly set for JSON content.
The code changes are approved.
73-85: Request CreationThe request creation using
client$.createRequest$is correctly implemented. Ensure that thecontextandoptionsare correctly defined and used.Verify the correctness of
contextandoptionsvalues used inclient$.createRequest$.
91-96: Request Execution and Error HandlingThe request execution and error handling using
client$.do$are correctly implemented. Ensure that theerrorCodesandretryCodesare comprehensive and cover all necessary cases.Verify the comprehensiveness of
errorCodesandretryCodesvalues used inclient$.do$.
102-114: Response MatchingThe response matching using
m$.matchis correctly implemented. Ensure that the response schema is correctly defined and handles all necessary response validation rules.Verify the correctness of the response schema definition to ensure comprehensive response validation.
119-119: Return StatementThe return statement correctly returns the result of the response matching.
The code changes are approved.
cardinal/sdk/typescript/src/models/operations/transact.ts (8)
9-12: Type DefinitionThe type definition for
TransactGlobalsis clear and well-defined with optional properties.The code changes are approved.
26-36: Inbound SchemaThe inbound schema for
TransactGlobalsis correctly defined with appropriate transformations.The code changes are approved.
45-59: Outbound SchemaThe outbound schema for
TransactGlobalsis correctly defined with appropriate transformations.The code changes are approved.
61-71: Deprecated NamespaceThe deprecated namespace for
TransactGlobals$is correctly defined for backward compatibility.The code changes are approved.
14-23: Type DefinitionThe type definition for
TransactRequestis clear and well-defined with required properties.The code changes are approved.
75-84: Inbound SchemaThe inbound schema for
TransactRequestis correctly defined with appropriate transformations.The code changes are approved.
93-106: Outbound SchemaThe outbound schema for
TransactRequestis correctly defined with appropriate transformations.The code changes are approved.
108-118: Deprecated NamespaceThe deprecated namespace for
TransactRequest$is correctly defined for backward compatibility.The code changes are approved.
cardinal/sdk/typescript/.speakeasy/gen.lock (4)
1-2: LGTM!The lock version and ID are appropriately specified.
The code changes are approved.
3-10: LGTM!The management section is correctly populated with necessary metadata.
The code changes are approved.
11-27: LGTM!The features section is correctly populated with necessary metadata.
The code changes are approved.
28-114: LGTM!The generated files section is correctly populated with necessary metadata.
The code changes are approved.
cardinal/sdk/typescript/src/funcs/transact.ts (4)
1-24: LGTM!The file header and imports are appropriately specified for a generated file.
The code changes are approved.
28-33: LGTM!The function documentation is clear and concise.
The code changes are approved.
34-49: LGTM!The function signature is appropriately defined.
The code changes are approved.
50-129: LGTM!The function body is correctly implemented with proper error handling and validation.
The code changes are approved.
cardinal/sdk/typescript/FUNCTIONS.md (4)
1-13: LGTM!The introduction section is clear and informative.
The code changes are approved.
Tools
LanguageTool
[uncategorized] ~11-~11: You might be missing the article “a” here.
Context: ...rs and response handlers. The result is dramatically smaller impact on the application's fin...(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~12-~12: A comma might be missing here.
Context: ...mpact on the application's final bundle size which grows very slowly as you use more...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
Markdownlint
5-5: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
14-62: LGTM!The usage section is clear and provides a useful example.
The code changes are approved.
Tools
LanguageTool
[grammar] ~15-~15: Use only “more” (without ‘more’) when you use the comparative.
Context: ...SDK class remains a valid and generally more more ergonomic option. Standalone functions ...(MOST_COMPARATIVE)
63-83: LGTM!The result types section is clear and informative.
The code changes are approved.
Tools
LanguageTool
[style] ~78-~78: The word “because” means “for the reason that” and thus introduces redundancy.
Context: ...nd reason for this style of programming is because these functions will typically be used ...(REASON_IS_BECAUSE)
84-103: LGTM!The general pattern section is clear and provides a useful example.
The code changes are approved.
cardinal/sdk/typescript/src/lib/retries.ts (7)
7-12: LGTM!The type definition for
BackoffStrategyis correctly implemented.The code changes are approved.
21-27: LGTM!The type definition for
RetryConfigis correctly implemented.The code changes are approved.
29-37: LGTM!The class
PermanentErroris correctly implemented.The code changes are approved.
40-48: LGTM!The class
TemporaryErroris correctly implemented.The code changes are approved.
51-69: LGTM!The function
retryis correctly implemented.The code changes are approved.
72-101: LGTM!The function
wrapFetcheris correctly implemented.The code changes are approved.
185-187: LGTM!The function
delayis correctly implemented.The code changes are approved.
cardinal/sdk/typescript/src/lib/security.ts (7)
5-8: LGTM!The enum
SecurityErrorCodeis correctly implemented.The code changes are approved.
10-28: LGTM!The class
SecurityErroris correctly implemented.The code changes are approved.
30-35: LGTM!The type definition for
SecurityStateis correctly implemented.The code changes are approved.
71-77: LGTM!The type definition for
SecurityInputis correctly implemented.The code changes are approved.
79-145: LGTM!The function
resolveSecurityis correctly implemented.The code changes are approved.
148-154: LGTM!The function
applyBasicis correctly implemented.The code changes are approved.
156-170: LGTM!The function
applyBeareris correctly implemented.The code changes are approved.
cardinal/server/handler/tx.go (3)
25-26: LGTM!The addition of JSON tags for the fields in
PostTransactionResponseimproves JSON serialization.The code changes are approved.
99-99: LGTM!The addition of the
@Idannotation forPostTransactionimproves API documentation.The code changes are approved.
118-118: LGTM!The addition of the
@Idannotation forPostGameTransactionimproves API documentation.The code changes are approved.
scripts/pre-speakeasy.js (5)
12-21: LGTM!The code correctly sets the
x-speakeasy-ignoreattribute for the specified endpoints.
23-71: LGTM!The code correctly adds and hides the global parameters for the SDK.
105-134: LGTM!The code correctly renames the specified types using
x-speakeasy-name-override.
136-166: LGTM!The code correctly adds example parameter values and usage examples for the specified endpoints.
168-177: LGTM!The code correctly writes the updated OpenAPI data back to the file and handles errors.
cardinal/sdk/typescript/src/lib/http.ts (3)
23-151: LGTM!The
HTTPClientclass is correctly implemented with methods for adding and removing hooks, making requests, and cloning the client.Tools
Biome
[error] 39-39: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
244-323: LGTM!The utility functions for matching responses and error types are correctly implemented.
1-22: Useundefinedinstead ofvoidin union types.Using
undefinedinstead ofvoidin union types is recommended for clarity.-export type Awaitable<T> = T | Promise<T>; +export type Awaitable<T> = T | Promise<T | undefined>;Likely invalid or redundant comment.
cardinal/sdk/typescript/src/lib/matchers.ts (4)
1-22: LGTM!The type definitions and default content types are correctly implemented.
23-140: LGTM!The functions for creating matchers for different encodings and error types are correctly implemented.
141-270: LGTM!The functions for matching responses based on matchers are correctly implemented.
271-308: LGTM!The utility functions for unpacking headers and discarding response bodies are correctly implemented.
cardinal/server/docs/swagger.yaml (11)
6-6: LGTM!The addition of an example value for the
cqlproperty enhances clarity.The code changes are approved.
44-44: LGTM!The addition of an example value for the
startTickproperty enhances clarity.The code changes are approved.
55-55: LGTM!The addition of
x-nullable: truefor theitemsproperty enhances flexibility.The code changes are approved.
72-72: LGTM!The addition of
x-nullable: truefor theerrorsproperty enhances flexibility.The code changes are approved.
135-135: LGTM!The addition of
operationIdfor thequeryCQLendpoint standardizes the API's structure.The code changes are approved.
158-158: LGTM!The addition of
operationIdfor thegetDebugStateendpoint standardizes the API's structure.The code changes are approved.
183-183: LGTM!The addition of
operationIdfor thegetHealthendpoint standardizes the API's structure.The code changes are approved.
320-320: LGTM!The addition of
operationIdfor thetransactendpoint standardizes the API's structure.The code changes are approved.
350-350: LGTM!The addition of
operationIdfor thecreatePersonaendpoint standardizes the API's structure.The code changes are approved.
375-375: LGTM!The addition of
operationIdfor thegetWorldendpoint standardizes the API's structure.The code changes are approved.
96-98: LGTM! But verify all references.The renaming of
EntityStateElementtoDebugStateElementmight indicate a shift in its intended use or context. Ensure all references are updated accordingly.Run the following script to verify all references to
DebugStateElement:Verification successful
Renaming Verified:
EntityStateElementtoDebugStateElementThe renaming of
EntityStateElementtoDebugStateElementhas been consistently applied across the codebase, including YAML, JSON, Go, TypeScript, and other relevant files. No issues found with the references.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all references to `DebugStateElement`. # Test: Search for the references. Expect: Only occurrences of the new name. rg --type yaml 'DebugStateElement'Length of output: 261
Script:
#!/bin/bash # Comprehensive search for `DebugStateElement` across the entire codebase. rg 'DebugStateElement'Length of output: 4650
cardinal/sdk/typescript/src/lib/sdks.ts (7)
5-27: LGTM!The imports are correctly implemented.
The code changes are approved.
30-62: LGTM!The type definitions are correctly implemented.
The code changes are approved.
64-73: LGTM!The utility constants are correctly implemented.
The code changes are approved.
75-107: LGTM!The
ClientSDKclass constructor is correctly implemented.The code changes are approved.
Tools
Biome
[error] 98-98: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
109-201: Ensure proper error handling and logging.The
createRequest$method is correctly implemented. However, ensure that all potential errors are properly handled and logged.Verify that all potential errors are properly handled and logged in the codebase.
204-268: Ensure proper error handling and logging.The
do$method is correctly implemented. However, ensure that all potential errors are properly handled and logged.Verify that all potential errors are properly handled and logged in the codebase.
272-357: LGTM!The utility functions are correctly implemented.
The code changes are approved.
cardinal/world.go (1)
167-167: Remove redundant initialization.The
QueryManagerfield is initialized twice. Remove the redundant initialization to improve code clarity and efficiency.Apply this diff to remove the redundant initialization:
- world.QueryManager = newQueryManager(world)Likely invalid or redundant comment.
cardinal/server/docs/swagger.json (8)
25-25: LGTM!The
operationIdfor the/cqlendpoint is correctly set.The code changes are approved.
60-60: LGTM!The
operationIdfor the/debug/stateendpoint is correctly set.The code changes are approved.
98-98: LGTM!The
operationIdfor the/healthendpoint is correctly set.The code changes are approved.
109-153: LGTM!The new endpoint
/query/game/{queryName}is correctly defined.The code changes are approved.
164-164: LGTM!The
operationIdfor the/query/receipts/listendpoint is correctly set.The code changes are approved.
253-253: LGTM!The
operationIdfor the/tx/game/{txName}endpoint is correctly set.The code changes are approved.
298-298: LGTM!The
operationIdfor the/tx/persona/create-personaendpoint is correctly set.The code changes are approved.
387-387: LGTM!The
operationIdfor the/worldendpoint is correctly set.The code changes are approved.
cardinal/server/docs/docs.go (9)
28-28: LGTM!The
operationIdfor the endpoint"/cql"is correctly set to"queryCQL".The code changes are approved.
63-63: LGTM!The
operationIdfor the endpoint"/debug/state"is correctly set to"getDebugState".The code changes are approved.
101-101: LGTM!The
operationIdfor the endpoint"/health"is correctly set to"getHealth".The code changes are approved.
112-122: LGTM!The
operationIdfor the endpoint"/query/game/{queryName}"is correctly set to"query".The code changes are approved.
167-167: LGTM!The
operationIdfor the endpoint"/query/receipts/list"is correctly set to"getReceipts".The code changes are approved.
256-256: LGTM!The
operationIdfor the endpoint"/transact"is correctly set to"transact".The code changes are approved.
301-301: LGTM!The
operationIdfor the endpoint"/create/persona"is correctly set to"createPersona".The code changes are approved.
28-28: LGTM!The
operationIdfor the endpoint"/query/cql"is correctly set to"queryCQL".The code changes are approved.
549-567: LGTM!The type name changes are consistent with the purpose of the types.
The code changes are approved.
cardinal/server/docs/openapi.json (8)
15-54: LGTM!The endpoint
"/cql"is correctly defined with detailed parameter specifications.The code changes are approved.
56-76: LGTM!The endpoint
"/debug/state"is correctly defined with detailed response specifications.The code changes are approved.
Tools
checkov
[MEDIUM] 66-71: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
97-114: LGTM!The endpoint
"/health"is correctly defined with detailed response specifications.The code changes are approved.
116-175: LGTM!The endpoint
"/query/game/{queryName}"is correctly defined with detailed parameter and response specifications.The code changes are approved.
177-216: LGTM!The endpoint
"/query/receipts/list"is correctly defined with detailed parameter and response specifications.The code changes are approved.
283-350: LGTM!The endpoint
"/tx/game/{txName}"is correctly defined with detailed parameter and response specifications.The code changes are approved.
352-411: LGTM!The endpoint
"/tx/persona/create-persona"is correctly defined with detailed parameter and response specifications.The code changes are approved.
478-506: LGTM!The endpoint
"/world"is correctly defined with detailed response specifications.The code changes are approved.
cardinal/sdk/typescript/docs/sdks/cardinal/README.md (6)
1-16: LGTM!The overview and available operations are correctly listed and provide a clear summary of the SDK's functionality.
The code changes are approved.
18-89: LGTM!The
queryCQLoperation is correctly documented and provides clear instructions for usage.The code changes are approved.
Tools
LanguageTool
[uncategorized] ~77-~77: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
Markdownlint
73-73: Expected: 250; Actual: 709
Line length(MD013, line-length)
74-74: Expected: 250; Actual: 709
Line length(MD013, line-length)
76-76: Expected: 250; Actual: 709
Line length(MD013, line-length)
91-157: LGTM!The
getDebugStateoperation is correctly documented and provides clear instructions for usage.The code changes are approved.
Tools
LanguageTool
[uncategorized] ~145-~145: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
Markdownlint
142-142: Expected: 250; Actual: 709
Line length(MD013, line-length)
143-143: Expected: 250; Actual: 709
Line length(MD013, line-length)
144-144: Expected: 250; Actual: 709
Line length(MD013, line-length)
95-95: null
Multiple headings with the same content(MD024, no-duplicate-heading)
112-112: null
Multiple headings with the same content(MD024, no-duplicate-heading)
140-140: null
Multiple headings with the same content(MD024, no-duplicate-heading)
148-148: null
Multiple headings with the same content(MD024, no-duplicate-heading)
152-152: null
Multiple headings with the same content(MD024, no-duplicate-heading)
159-225: LGTM!The
getHealthoperation is correctly documented and provides clear instructions for usage.The code changes are approved.
Tools
LanguageTool
[uncategorized] ~213-~213: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
Markdownlint
210-210: Expected: 250; Actual: 709
Line length(MD013, line-length)
211-211: Expected: 250; Actual: 709
Line length(MD013, line-length)
212-212: Expected: 250; Actual: 709
Line length(MD013, line-length)
163-163: null
Multiple headings with the same content(MD024, no-duplicate-heading)
180-180: null
Multiple headings with the same content(MD024, no-duplicate-heading)
208-208: null
Multiple headings with the same content(MD024, no-duplicate-heading)
216-216: null
Multiple headings with the same content(MD024, no-duplicate-heading)
220-220: null
Multiple headings with the same content(MD024, no-duplicate-heading)
227-304: LGTM!The
queryoperation is correctly documented and provides clear instructions for usage.The code changes are approved.
Tools
LanguageTool
[uncategorized] ~292-~292: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
Markdownlint
288-288: Expected: 250; Actual: 709
Line length(MD013, line-length)
289-289: Expected: 250; Actual: 709
Line length(MD013, line-length)
291-291: Expected: 250; Actual: 709
Line length(MD013, line-length)
231-231: null
Multiple headings with the same content(MD024, no-duplicate-heading)
253-253: null
Multiple headings with the same content(MD024, no-duplicate-heading)
286-286: null
Multiple headings with the same content(MD024, no-duplicate-heading)
295-295: null
Multiple headings with the same content(MD024, no-duplicate-heading)
299-299: null
Multiple headings with the same content(MD024, no-duplicate-heading)
306-377: LGTM!The
Tools
LanguageTool
[uncategorized] ~365-~365: Possible missing comma found.
Context: ...quest. This can be used to inject extra headers for examples. AllRequestoptions, ex...(AI_HYDRA_LEO_MISSING_COMMA)
Markdownlint
361-361: Expected: 250; Actual: 709
Line length(MD013, line-length)
362-362: Expected: 250; Actual: 709
Line length(MD013, line-length)
364-364: Expected: 250; Actual: 709
Line length(MD013, line-length)
310-310: null
Multiple headings with the same content(MD024, no-duplicate-heading)
329-329: null
Multiple headings with the same content(MD024, no-duplicate-heading)
359-359: null
Multiple headings with the same content(MD024, no-duplicate-heading)
368-368: null
Multiple headings with the same content(MD024, no-duplicate-heading)
372-372: null
Multiple headings with the same content(MD024, no-duplicate-heading)
cardinal/sdk/typescript/README.md (3)
10-38: LGTM!The SDK installation instructions are clear and accurate.
The code changes are approved.
41-45: LGTM!The requirements section is concise and provides the necessary information.
The code changes are approved.
47-91: LGTM!The SDK example usage is clear and demonstrates the SDK's functionality effectively.
The code changes are approved.
cardinal/sdk/typescript/src/lib/encodings.ts (9)
8-13: LGTM!The custom error class
EncodingErroris correctly implemented.The code changes are approved.
15-63: LGTM!The function
encodeMatrixis correctly implemented and handles different data types and encoding options effectively.The code changes are approved.
65-102: LGTM!The function
encodeLabelis correctly implemented and handles different data types and encoding options effectively.The code changes are approved.
110-157: LGTM!The function
formEncoderis correctly implemented and handles different data types and encoding options effectively.The code changes are approved.
159-161: LGTM!The function
encodeFormis correctly implemented.The code changes are approved.
160-161: LGTM!The function
encodeSpaceDelimitedis correctly implemented.The code changes are approved.
161-162: LGTM!The function
encodePipeDelimitedis correctly implemented.The code changes are approved.
163-204: LGTM!The function
encodeBodyFormis correctly implemented and handles different data types and encoding options effectively.The code changes are approved.
206-222: LGTM!The function
encodeDeepObjectis correctly implemented and handles different data types and encoding options effectively.The code changes are approved.
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| ----------- | ----------- | ----------- | ----------- |Tools
Markdownlint
14-14: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/src/types/constdatetime.ts (1)
7-15: Fix typo in error message.
The error message contains a typo: "equivelant" should be "equivalent".
Apply this diff to fix the typo:
- }, `Value must be equivelant to ${val}`); + }, `Value must be equivalent to ${val}`);Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export function constDateTime( val: string, ): z.ZodType<string, z.ZodTypeDef, unknown> { return z.custom<string>((v) => { return ( typeof v === "string" && new Date(v).getTime() === new Date(val).getTime() ); }, `Value must be equivalent to ${val}`); }cardinal/sdk/typescript/docs/models/components/txresponse.md (1)
16-16: Add a newline at the end of the file.
Files should end with a single newline character for consistency.
Apply this diff to add a newline at the end of the file:
| `txHash` | *string* | :heavy_minus_sign: | N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `txHash` | *string* | :heavy_minus_sign: | N/A |Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/operations/transactglobals.md (1)
16-16: Add a newline at the end of the file.
Files should end with a single newline character for consistency.
Apply this diff to add a newline at the end of the file:
| `namespace` | *string* | :heavy_minus_sign: | N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `namespace` | *string* | :heavy_minus_sign: | N/A |Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/getreceiptsrequest.md (1)
17-17: Add a newline at the end of the file.
Files should end with a single newline character for consistency.
Apply this diff to add a newline at the end of the file:
| `startTick` | *number* | :heavy_minus_sign: | N/A | 64 | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `startTick` | *number* | :heavy_minus_sign: | N/A | 64 |Tools
Markdownlint
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/cqlqueryrequest.md (1)
17-17: Add a newline at the end of the file.
The file should end with a single newline character to adhere to best practices.
Apply this diff to add a newline at the end of the file:
-CONTAINS(Health) | +CONTAINS(Health) | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `cql` | *string* | :heavy_minus_sign: | N/A | CONTAINS(Health) |Tools
Markdownlint
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/operations/createpersonaglobals.md (1)
16-16: Add a newline at the end of the file.
The file should end with a single newline character to adhere to best practices.
Apply this diff to add a newline at the end of the file:
-N/A | +N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `namespace` | *string* | :heavy_minus_sign: | N/A |Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/gethealthresponse.md (1)
16-16: Add a single newline character at the end of the file.
The file should end with a single newline character to comply with Markdownlint rules.
Apply this diff to add a single newline character at the end of the file:
-| `isServerRunning` | *boolean* | :heavy_minus_sign: | N/A | +| `isServerRunning` | *boolean* | :heavy_minus_sign: | N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `isServerRunning` | *boolean* | :heavy_minus_sign: | N/A |Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/debugstateelement.md (1)
16-16: Add a single newline character at the end of the file.
The file should end with a single newline character to comply with Markdownlint rules.
Apply this diff to add a single newline character at the end of the file:
-| `id` | *number* | :heavy_minus_sign: | N/A | +| `id` | *number* | :heavy_minus_sign: | N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `id` | *number* | :heavy_minus_sign: | N/A |Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/entitystateelement.md (2)
13-15: Clarify the type of the
datafield.The type
Record<string, *any*>[]might be confusing. Consider providing a more detailed description or example.
16-16: Ensure the file ends with a single newline character.
Files should end with a single newline character to comply with Markdownlint rule MD047.
Apply this diff to add a newline character at the end of the file:
- | `id` | *number* | :heavy_minus_sign: | N/A | + | `id` | *number* | :heavy_minus_sign: | N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `id` | *number* | :heavy_minus_sign: | N/A |Tools
Markdownlint
16-16: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/src/hooks/registration.ts (1)
10-16: Consider adding comments to explain the purpose of the
signerhook.The function is correctly implemented, but additional comments would improve readability and maintainability.
Consider adding comments like this:
export function initHooks(hooks: Hooks) { // Add hooks by calling hooks.register{ClientInit/BeforeCreateRequest/BeforeRequest/AfterSuccess/AfterError}Hook // with an instance of a hook that implements that specific Hook interface // Hooks are registered per SDK instance, and are valid for the lifetime of the SDK instance const signer = new CardinalHook() // This hook signs requests before they are sent hooks.registerBeforeRequestHook(signer) }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export function initHooks(hooks: Hooks) { // Add hooks by calling hooks.register{ClientInit/BeforeCreateRequest/BeforeRequest/AfterSuccess/AfterError}Hook // with an instance of a hook that implements that specific Hook interface // Hooks are registered per SDK instance, and are valid for the lifetime of the SDK instance const signer = new CardinalHook() // This hook signs requests before they are sent hooks.registerBeforeRequestHook(signer) }cardinal/sdk/typescript/src/models/errors/sdkerror.ts (1)
5-24: Validate constructor parameters and improve error message formatting.
The constructor should validate the
rawResponseandbodyparameters to ensure they are of the expected types. Additionally, the error message formatting can be improved for readability.Apply this diff to validate the constructor parameters and improve the error message formatting:
constructor( message: string, - public readonly rawResponse: Response, - public readonly body: string = "" + rawResponse: Response, + body: string = "" ) { + if (!(rawResponse instanceof Response)) { + throw new TypeError("rawResponse must be a Response object"); + } + if (typeof body !== "string") { + throw new TypeError("body must be a string"); + } const statusCode = rawResponse.status; const contentType = rawResponse.headers.get("content-type") || ""; const bodyString = body.length > 0 ? `\n${body}` : ""; super(`${message}:\nStatus: ${statusCode}\nContent-Type: ${contentType}\nBody: ${bodyString}`); this.statusCode = statusCode; this.contentType = contentType; this.rawResponse = rawResponse; this.body = body; this.name = "SDKError"; }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export class SDKError extends Error { public readonly statusCode: number; public readonly contentType: string; public readonly rawResponse: Response; public readonly body: string; constructor( message: string, rawResponse: Response, body: string = "" ) { if (!(rawResponse instanceof Response)) { throw new TypeError("rawResponse must be a Response object"); } if (typeof body !== "string") { throw new TypeError("body must be a string"); } const statusCode = rawResponse.status; const contentType = rawResponse.headers.get("content-type") || ""; const bodyString = body.length > 0 ? `\n${body}` : ""; super(`${message}:\nStatus: ${statusCode}\nContent-Type: ${contentType}\nBody: ${bodyString}`); this.statusCode = statusCode; this.contentType = contentType; this.rawResponse = rawResponse; this.body = body; this.name = "SDKError"; }cardinal/sdk/typescript/src/types/blobs.ts (1)
7-11: Define
isBlobLikefunction before usage and remove deprecatedfataloption.The
isBlobLikefunction should be defined before it is used. Additionally, thefataloption in the schema definition is deprecated in newer versions of Zod.Apply this diff to define the
isBlobLikefunction before it is used and remove the deprecatedfataloption:+export function isBlobLike(val: unknown): val is Blob { + if (val instanceof Blob) { + return true; + } + + if (typeof val !== "object" || val == null || !(Symbol.toStringTag in val)) { + return false; + } + + const name = val[Symbol.toStringTag]; + if (typeof name !== "string") { + return false; + } + if (name !== "Blob" && name !== "File") { + return false; + } + + return "stream" in val && typeof val.stream === "function"; +} export const blobLikeSchema: z.ZodType<Blob, z.ZodTypeDef, Blob> = z.custom<Blob>(isBlobLike, { message: "expected a Blob, File or Blob-like object", - fatal: true, });Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export function isBlobLike(val: unknown): val is Blob { if (val instanceof Blob) { return true; } if (typeof val !== "object" || val == null || !(Symbol.toStringTag in val)) { return false; } const name = val[Symbol.toStringTag]; if (typeof name !== "string") { return false; } if (name !== "Blob" && name !== "File") { return false; } return "stream" in val && typeof val.stream === "function"; } export const blobLikeSchema: z.ZodType<Blob, z.ZodTypeDef, Blob> = z.custom<Blob>(isBlobLike, { message: "expected a Blob, File or Blob-like object", });cardinal/sdk/typescript/docs/models/components/worldfielddetail.md (3)
3-9: Consider providing a more detailed example.
The example usage is clear, but it might be more helpful to provide an example with actual field values to illustrate how the model is used in practice.
import { WorldFieldDetail } from "@arguslabs/cardinal/models/components"; let value: WorldFieldDetail = { name: "ExampleName", url: "http://example.com", fields: { field1: "value1", field2: "value2" } };
11-17: Provide a more informative description for the
urlfield.The description for the
urlfield is "N/A," which is not informative. Consider providing a description that explains the purpose of this field.| `url` | *string* | :heavy_minus_sign: | URL associated with the message or query |Tools
Markdownlint
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
17-17: Add a newline character at the end of the file.
Files should end with a single newline character to adhere to Markdownlint rules.
| `url` | *string* | :heavy_minus_sign: | N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `url` | *string* | :heavy_minus_sign: | N/A |Tools
Markdownlint
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/USAGE.md (1)
1-1: Add a top-level heading at the beginning of the file.
Files should start with a top-level heading to adhere to Markdownlint rules.
+ # SDK Usage <!-- Start SDK Example Usage [usage] -->Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.# SDK Usage <!-- Start SDK Example Usage [usage] -->cardinal/sdk/typescript/docs/models/operations/queryrequest.md (2)
3-14: Consider providing a more detailed example.
The example usage is clear, but it might be more helpful to provide an example with actual field values to illustrate how the model is used in practice.
import { QueryRequest } from "@arguslabs/cardinal/models/operations"; let value: QueryRequest = { queryName: "player-health", requestBody: { key: "exampleValue" } };
21-21: Add a newline character at the end of the file.
Files should end with a single newline character to adhere to Markdownlint rules.
| `requestBody` | Record<string, *any*> | :heavy_check_mark: | Query to be executed | | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `requestBody` | Record<string, *any*> | :heavy_check_mark: | Query to be executed | |Tools
Markdownlint
21-21: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/txbody.md (1)
22-22: Add a single newline character at the end of the file.
The file should end with a single newline character to comply with markdownlint rules.
Apply this diff to add a single newline character at the end of the file:
| `signature` | *string* | :heavy_minus_sign: | hex encoded string | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `signature` | *string* | :heavy_minus_sign: | hex encoded string |Tools
Markdownlint
22-22: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/src/lib/url.ts (1)
9-32: Consider adding type safety for parameters.
The function is correctly implemented. However, it could benefit from additional type safety by using TypeScript's type system to enforce the parameter types.
Apply this diff to add type safety:
-export function pathToFunc( - pathPattern: string, - options?: { charEncoding?: "percent" | "none" }, -): (params?: Params) => string { +export function pathToFunc( + pathPattern: string, + options?: { charEncoding?: "percent" | "none" }, +): (params: Params) => string { const paramRE = /\{([a-zA-Z0-9_]+?)\}/g; return function buildURLPath(params: Params = {}): string { return pathPattern.replace(paramRE, function (_, placeholder) { if (!hasOwn.call(params, placeholder)) { throw new Error(`Parameter '${placeholder}' is required`); } const value = params[placeholder]; if (typeof value !== "string" && typeof value !== "number") { throw new Error( `Parameter '${placeholder}' must be a string or number`, ); } return options?.charEncoding === "percent" ? encodeURIComponent(`${value}`) : `${value}`; }); }; }Committable suggestion was skipped due to low confidence.
cardinal/sdk/typescript/RUNTIMES.md (1)
15-20: Use asterisks for unordered lists.
The unordered list should use asterisks for consistency with Markdownlint rules.
Apply this diff to use asterisks:
- - Evergreen browsers which include: Chrome, Safari, Edge, Firefox - - Node.js active and maintenance LTS releases - - Currently, this is v18 and v20 - - Bun v1 and above - - Deno v1.39 - - Note that Deno does not currently have native support for streaming file uploads backed by the filesystem ([issue link][deno-file-streaming]) + * Evergreen browsers which include: Chrome, Safari, Edge, Firefox + * Node.js active and maintenance LTS releases + * Currently, this is v18 and v20 + * Bun v1 and above + * Deno v1.39 + * Note that Deno does not currently have native support for streaming file uploads backed by the filesystem ([issue link][deno-file-streaming])Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.* Evergreen browsers which include: Chrome, Safari, Edge, Firefox * Node.js active and maintenance LTS releases * Currently, this is v18 and v20 * Bun v1 and above * Deno v1.39 * Note that Deno does not currently have native support for streaming file uploads backed by the filesystem ([issue link][deno-file-streaming])Tools
Markdownlint
15-15: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
16-16: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
17-17: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
18-18: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
19-19: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
20-20: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
cardinal/sdk/typescript/tsconfig.json (1)
16-16: Specify output directory
The
outDiroption is set to.(current directory), which might clutter the root directory with build artifacts.Consider specifying a dedicated output directory to keep the project structure clean:
- "outDir": ".", + "outDir": "dist",Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements."outDir": "dist",cardinal/sdk/typescript/docs/models/components/cqlqueryresponse.md (2)
13-15: Address line length issues
The field descriptions exceed the recommended line length limit of 250 characters.
Consider breaking the lines to improve readability:
| Field | Type | Required | Description | | ----- | ---- | -------- | ----------- | | `results` | [components.EntityStateElement](../../models/components/entitystateelement.md)[] | :heavy_minus_sign: | N/A |Tools
Markdownlint
13-13: Expected: 250; Actual: 333
Line length(MD013, line-length)
14-14: Expected: 250; Actual: 333
Line length(MD013, line-length)
15-15: Expected: 250; Actual: 333
Line length(MD013, line-length)
15-15: null
Files should end with a single newline character(MD047, single-trailing-newline)
15-15: Add trailing newline
The file is missing a trailing newline.
Add a newline at the end of the file to follow markdown best practices.
Tools
Markdownlint
15-15: Expected: 250; Actual: 333
Line length(MD013, line-length)
15-15: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/CONTRIBUTING.md (2)
3-3: Reduce line length.
The line length exceeds the recommended limit.
Apply this diff to reduce the line length:
-Thank you for your interest in contributing to this repository. Please note that this repository contains generated code. As such, we do not accept direct changes or pull requests. Instead, we encourage you to follow the guidelines below to report issues and suggest improvements. +Thank you for your interest in contributing to this repository. Please note that this repository contains generated code. As such, we do not accept direct changes or pull requests. Instead, we encourage you to follow the guidelines below to report issues and suggest improvements.Committable suggestion was skipped due to low confidence.
Tools
Markdownlint
3-3: Expected: 250; Actual: 280
Line length(MD013, line-length)
14-14: Fix unordered list indentation.
The unordered list indentation does not match the expected format.
Apply this diff to fix the indentation:
- - For example can be collected using the `npx envinfo` command from your terminal if you have Node.js installed + - For example can be collected using the `npx envinfo` command from your terminal if you have Node.js installedCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- For example can be collected using the `npx envinfo` command from your terminal if you have Node.js installedTools
Markdownlint
14-14: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
cardinal/sdk/typescript/docs/models/operations/transactrequest.md (1)
16-21: Address line length issues and add a newline at the end of the file.
The field descriptions are clear and informative. However, the line length exceeds the recommended limit, and the file is missing a newline at the end.
Apply this diff to address the issues:
-| `txBody` | [components.TxBody](../../models/components/txbody.md) | :heavy_check_mark: | Transaction details & message to be submitted | {<br/>"personaTag": "CoolMage"<br/>} | +| `txBody` | [components.TxBody](../../models/components/txbody.md) | :heavy_check_mark: | Transaction details & message to be submitted | {<br/>"personaTag": "CoolMage"<br/>} | +Committable suggestion was skipped due to low confidence.
Tools
Markdownlint
18-18: Expected: 250; Actual: 286
Line length(MD013, line-length)
19-19: Expected: 250; Actual: 286
Line length(MD013, line-length)
20-20: Expected: 250; Actual: 286
Line length(MD013, line-length)
21-21: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/src/types/rfcdate.ts (1)
27-45: Improve constructor implementation.
The constructor is correctly implemented but can be improved by using template literals and
Number.isNaN.Apply this diff to improve the constructor:
constructor(date: Date | string) { if (typeof date === "string" && !dateRE.test(date)) { throw new RangeError( - "RFCDate: date strings must be in the format YYYY-MM-DD: " + date, + `RFCDate: date strings must be in the format YYYY-MM-DD: ${date}`, ); } const value = new Date(date); - if (isNaN(+value)) { + if (Number.isNaN(+value)) { throw new RangeError(`RFCDate: invalid date provided: ${date}`); } this.serialized = value.toISOString().slice(0, "YYYY-MM-DD".length); if (!dateRE.test(this.serialized)) { throw new TypeError( - `RFCDate: failed to build valid date with given value: ${date} serialized to ${this.serialized}`, + `RFCDate: failed to build valid date with given value: ${date}, serialized to ${this.serialized}`, ); } }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.constructor(date: Date | string) { if (typeof date === "string" && !dateRE.test(date)) { throw new RangeError( `RFCDate: date strings must be in the format YYYY-MM-DD: ${date}`, ); } const value = new Date(date); if (Number.isNaN(+value)) { throw new RangeError(`RFCDate: invalid date provided: ${date}`); } this.serialized = value.toISOString().slice(0, "YYYY-MM-DD".length); if (!dateRE.test(this.serialized)) { throw new TypeError( `RFCDate: failed to build valid date with given value: ${date}, serialized to ${this.serialized}`, ); } }Tools
Biome
[error] 30-30: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
[error] 36-36: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
[error] 35-35: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
cardinal/sdk/typescript/docs/models/components/receiptentry.md (1)
1-18: LGTM! But add a newline character at the end of the file.
The documentation is clear and well-structured. Adding a newline character at the end of the file is a minor improvement.
Apply this diff to add a newline character at the end of the file:
+Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.# ReceiptEntry ## Example Usage ```typescript import { ReceiptEntry } from "@arguslabs/cardinal/models/components"; let value: ReceiptEntry = {}; ``` ## Fields | Field | Type | Required | Description | | ------------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------------ | | `errors` | *string*[] | :heavy_minus_sign: | N/A | | `result` | [components.Result](../../models/components/result.md) | :heavy_minus_sign: | N/A | | `tick` | *number* | :heavy_minus_sign: | N/A | | `txHash` | *string* | :heavy_minus_sign: | N/A |Tools
Markdownlint
18-18: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/models/components/getreceiptsresponse.md (2)
13-17: Fix the line length issue.
The line length exceeds the recommended limit of 250 characters.
Consider breaking the lines to adhere to the recommended limit.
Tools
Markdownlint
13-13: Expected: 250; Actual: 285
Line length(MD013, line-length)
14-14: Expected: 250; Actual: 285
Line length(MD013, line-length)
15-15: Expected: 250; Actual: 285
Line length(MD013, line-length)
16-16: Expected: 250; Actual: 285
Line length(MD013, line-length)
17-17: Expected: 250; Actual: 285
Line length(MD013, line-length)
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
17-17: Add a newline character at the end of the file.
The file should end with a single newline character.
Add a newline character at the end of the file.
Tools
Markdownlint
17-17: Expected: 250; Actual: 285
Line length(MD013, line-length)
17-17: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/docs/lib/utils/retryconfig.md (4)
24-24: Add a newline character at the end of the file.
The file should end with a single newline character.
Add a newline character at the end of the file.
Tools
Markdownlint
24-24: null
Files should end with a single newline character(MD047, single-trailing-newline)
9-9: Fix the table column count issue.
The table column count is incorrect.
Consider fixing the table column count:
- | `strategy` | `"backoff" | "none"` | The retry strategy to use. | `"backoff"` | + | `strategy` | `"backoff" \| "none"` | The retry strategy to use. | `"backoff"` |Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `strategy` | `"backoff" \| "none"` | The retry strategy to use. | `"backoff"` |Tools
Markdownlint
9-9: Expected: 4; Actual: 5; Too many cells, extra data will be missing
Table column count(MD056, table-column-count)
13-24: Fix duplicate headings.
There are duplicate headings in the file.
Consider renaming the duplicate heading:
- ## BackoffStrategy + ## Backoff StrategyCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.## Backoff Strategy The backoff strategy allows retrying a request with an exponential backoff between each retry. ### Fields | Name | Type | Description | Example | | ------------------ | ------------ | ----------------------------------------- | -------- | | `initialInterval` | `*number*` | The initial interval in milliseconds. | `500` | | `maxInterval` | `*number*` | The maximum interval in milliseconds. | `60000` | | `exponent` | `*number*` | The exponent to use for the backoff. | `1.5` | | `maxElapsedTime` | `*number*` | The maximum elapsed time in milliseconds. | `300000` |Tools
Markdownlint
17-17: null
Multiple headings with the same content(MD024, no-duplicate-heading)
24-24: null
Files should end with a single newline character(MD047, single-trailing-newline)
7-11: Fix missing articles.
The articles "the" are missing in the descriptions.
Consider adding "the" to the descriptions:
- When strategy is "backoff", this configurates for the backoff parameters. + When the strategy is "backoff", this configurates for the backoff parameters. - When strategy is "backoff", this determines whether or not to retry on connection errors. + When the strategy is "backoff", this determines whether to retry on connection errors.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| Name | Type | Description | Example | | ------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------ | ----------- | | `strategy` | `"backoff" | "none"` | The retry strategy to use. | `"backoff"` | | `backoff` | [BackoffStrategy](#backoffstrategy) | When the strategy is "backoff", this configurates for the backoff parameters. | | | `retryConnectionErrors` | `*boolean*` | When the strategy is "backoff", this determines whether to retry on connection errors. | `true` |Tools
LanguageTool
[uncategorized] ~10-~10: You might be missing the article “the” here.
Context: ...ckoffStrategy](#backoffstrategy) | When strategy is "backoff", this configurates for the...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[uncategorized] ~11-~11: You might be missing the article “the” here.
Context: ...oolean*` | When strategy is "backoff", this determines whether o...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[style] ~11-~11: Consider shortening this phrase to just ‘whether’, unless you mean ‘regardless of whether’.
Context: ... strategy is "backoff", this determines whether or not to retry on connection errors. | `true...(WHETHER)
Markdownlint
9-9: Expected: 4; Actual: 5; Too many cells, extra data will be missing
Table column count(MD056, table-column-count)
cardinal/sdk/typescript/src/models/errors/httpclienterrors.ts (1)
8-24: Fix the assignment of the
causeproperty.The
causeproperty should be assigned directly in the constructor to ensure compatibility with older runtimes.constructor(message: string, opts?: { cause?: unknown }) { let msg = message; if (opts?.cause) { msg += `: ${opts.cause}`; } super(msg, opts); // In older runtimes, the cause field would not have been assigned through // the super() call. - if (typeof this.cause === "undefined") { - this.cause = opts?.cause; - } + this.cause = opts?.cause; }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export class HTTPClientError extends Error { /** The underlying cause of the error. */ override readonly cause: unknown; override name = "HTTPClientError"; constructor(message: string, opts?: { cause?: unknown }) { let msg = message; if (opts?.cause) { msg += `: ${opts.cause}`; } super(msg, opts); // In older runtimes, the cause field would not have been assigned through // the super() call. this.cause = opts?.cause; }cardinal/sdk/typescript/src/lib/config.ts (1)
43-57: Consider adding validation for the
serverURLformat.The function is correctly implemented, but additional validation for the
serverURLformat would improve robustness.if (!serverURL) { const serverIdx = options.serverIdx ?? 0; if (serverIdx < 0 || serverIdx >= ServerList.length) { throw new Error(`Invalid server index ${serverIdx}`); } serverURL = ServerList[serverIdx] || ""; } + if (!/^https?:\/\/.+/.test(serverURL)) { + throw new Error(`Invalid server URL format: ${serverURL}`); + } const u = pathToFunc(serverURL)(params); return new URL(u);Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export function serverURLFromOptions(options: SDKOptions): URL | null { let serverURL = options.serverURL; const params: Params = {}; if (!serverURL) { const serverIdx = options.serverIdx ?? 0; if (serverIdx < 0 || serverIdx >= ServerList.length) { throw new Error(`Invalid server index ${serverIdx}`); } serverURL = ServerList[serverIdx] || ""; } if (!/^https?:\/\/.+/.test(serverURL)) { throw new Error(`Invalid server URL format: ${serverURL}`); } const u = pathToFunc(serverURL)(params); return new URL(u);cardinal/sdk/typescript/src/lib/dlv.ts (1)
40-52: Avoid reassigning function parameters.
Reassigning function parameters can be confusing. Use local variables instead.
Apply this diff to use local variables:
export function dlv<T = any>( obj: any, key: string | string[], def?: T, p?: number, undef?: never, ): T | undefined { - key = Array.isArray(key) ? key : key.split("."); - for (p = 0; p < key.length; p++) { + const keys = Array.isArray(key) ? key : key.split("."); + let result = obj; + for (p = 0; p < keys.length; p++) { const k = keys[p]; - obj = k != null && obj ? obj[k] : undef; + result = k != null && result ? result[k] : undef; } - return obj === undef ? def : obj; + return result === undef ? def : result; }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export function dlv<T = any>( obj: any, key: string | string[], def?: T, p?: number, undef?: never, ): T | undefined { const keys = Array.isArray(key) ? key : key.split("."); let result = obj; for (p = 0; p < keys.length; p++) { const k = keys[p]; result = k != null && result ? result[k] : undef; } return result === undef ? def : result; }Tools
Biome
[error] 50-50: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
[error] 47-47: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
[error] 48-48: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
[error] 48-48: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
cardinal/sdk/typescript/docs/models/components/getworldresponse.md (2)
11-18: Split long lines for better readability.
The fields documentation exceeds the recommended line length. Consider splitting the lines for better readability.
Apply this diff to split the lines:
-| `components` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | list of component names | -| `messages` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | N/A | -| `namespace` | *string* | :heavy_minus_sign: | N/A | -| `queries` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | N/A | +| `components` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | list of component names | +| `messages` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | N/A | +| `namespace` | *string* | :heavy_minus_sign: | N/A | +| `queries` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | N/A |Committable suggestion was skipped due to low confidence.
Tools
Markdownlint
13-13: Expected: 250; Actual: 317
Line length(MD013, line-length)
14-14: Expected: 250; Actual: 317
Line length(MD013, line-length)
15-15: Expected: 250; Actual: 317
Line length(MD013, line-length)
16-16: Expected: 250; Actual: 317
Line length(MD013, line-length)
17-17: Expected: 250; Actual: 317
Line length(MD013, line-length)
18-18: Expected: 250; Actual: 317
Line length(MD013, line-length)
18-18: null
Files should end with a single newline character(MD047, single-trailing-newline)
18-18: Add a newline character at the end of the file.
The file should end with a newline character to adhere to best practices.
Apply this diff to add a newline character at the end of the file:
-N/A | +N/A | +Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| `queries` | [components.WorldFieldDetail](../../models/components/worldfielddetail.md)[] | :heavy_minus_sign: | N/A |Tools
Markdownlint
18-18: Expected: 250; Actual: 317
Line length(MD013, line-length)
18-18: null
Files should end with a single newline character(MD047, single-trailing-newline)
cardinal/sdk/typescript/src/hooks/cardinal.ts (4)
64-68: Add error handling to the fetch request.
The method is correctly implemented but could benefit from error handling in case the fetch request fails.
Consider adding error handling like this:
+ try { const res = await fetch(`${url.origin}/world`) const data = await res.json() this.namespace = data.namespace + } catch (error) { + console.error('Failed to fetch namespace:', error) + }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.private async setNamespace(url: URL) { try { const res = await fetch(`${url.origin}/world`) const data = await res.json() this.namespace = data.namespace } catch (error) { console.error('Failed to fetch namespace:', error) } }
5-20: Add a comment to explain the function's purpose.
The function is correctly implemented but could benefit from a comment explaining its purpose.
Consider adding a comment like this:
+/** + * Modifies the request object with the provided body. + */ function modifyRequest(request: Request, body: {[k: string]: any}) {Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements./** * Modifies the request object with the provided body. */ function modifyRequest(request: Request, body: {[k: string]: any}) { const url = new URL(request.url) return new Request(url.origin + url.pathname, { method: request.method, headers: request.headers, body: JSON.stringify(body), cache: request.cache, credentials: request.credentials, integrity: request.integrity, keepalive: request.keepalive, mode: request.mode, referrer: request.referrer, referrerPolicy: request.referrerPolicy, signal: request.signal, }) }
25-59: Replace non-null assertions with optional chaining.
The method is correctly implemented but has forbidden non-null assertions that should be replaced with optional chaining.
Apply this diff to replace non-null assertions with optional chaining:
- const body = await request.json() + const body = await request.json() ?? {} - const msg = createMsgToSign(body!.personaTag, this.namespace!, txBody) + const msg = createMsgToSign(body?.personaTag, this.namespace!, txBody) - const msg = createMsgToSign(body!.personaTag, this.namespace!, body!.body) + const msg = createMsgToSign(body?.personaTag, this.namespace!, body?.body)Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.async beforeRequest(_hookCtx: BeforeRequestContext, request: Request): Promise<Request> { const url = new URL(request.url) if (!this.namespace) await this.setNamespace(url) if (url.pathname === '/tx/persona/create-persona') { const body = await request.json() ?? {} const privateKey = url.searchParams.get('_privateKey') as `0x{string}` const account = privateKeyToAccount(privateKey) const txBody = { personaTag: body?.personaTag, signerAddress: account.address } const msg = createMsgToSign(body?.personaTag, this.namespace!, txBody) const signature = customSign(msg, privateKey) return modifyRequest(request, { ...body, signature, body: txBody }) } if (url.pathname.startsWith('/tx/game/')) { const body = await request.json() ?? {} const msg = createMsgToSign(body?.personaTag, this.namespace!, body?.body) const privateKey = url.searchParams.get('_privateKey') as `0x{string}` const signature = customSign(msg, privateKey) return modifyRequest(request, { ...body, signature, }) } return request; }Tools
Biome
[error] 35-35: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 38-38: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 38-38: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
22-69: Add a comment to explain the class's purpose.
The class is correctly implemented but could benefit from a comment explaining its purpose.
Consider adding a comment like this:
+/** + * CardinalHook modifies requests to add signatures based on URL paths. + */ export class CardinalHook implements BeforeRequestHook {Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.+/** + * CardinalHook modifies requests to add signatures based on URL paths. + */ export class CardinalHook implements BeforeRequestHook { private namespace?: string; async beforeRequest(_hookCtx: BeforeRequestContext, request: Request): Promise<Request> { const url = new URL(request.url) if (!this.namespace) await this.setNamespace(url) if (url.pathname === '/tx/persona/create-persona') { const body = await request.json() const privateKey = url.searchParams.get('_privateKey') as `0x{string}` const account = privateKeyToAccount(privateKey) const txBody = { personaTag: body!.personaTag, signerAddress: account.address } const msg = createMsgToSign(body!.personaTag, this.namespace!, txBody) const signature = customSign(msg, privateKey) return modifyRequest(request, { ...body, signature, body: txBody }) } if (url.pathname.startsWith('/tx/game/')) { const body = await request.json() const msg = createMsgToSign(body!.personaTag, this.namespace!, body!.body) const privateKey = url.searchParams.get('_privateKey') as `0x{string}` const signature = customSign(msg, privateKey) return modifyRequest(request, { ...body, signature, }) } return request; } // this is called in beforeRequest instead of sdkInit because it can't be called // synchronously in sdkInit, which could result in a race condition where the beforeRequest // is called before the setNamespace in sdkInit finishes. private async setNamespace(url: URL) { const res = await fetch(`${url.origin}/world`) const data = await res.json() this.namespace = data.namespace } }Tools
Biome
[error] 35-35: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 38-38: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 38-38: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 49-49: Forbidden non-null assertion.
Unsafe fix: Replace with optional chain operator ?. This operator includes runtime checks, so it is safer than the compile-only non-null assertion operator
(lint/style/noNonNullAssertion)
cardinal/sdk/typescript/src/models/components/receiptentry.ts (2)
7-7: Avoid using
{}as a type.Using
{}as a type means "any non-nullable value" and should be avoided. Instead, explicitly define the object shape.Apply this diff to explicitly define the object shape:
-export type Result = {}; +export type Result = { + // Define the properties of the Result type here +};Committable suggestion was skipped due to low confidence.
Tools
Biome
[error] 7-7: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
20-20: Avoid using
{}as a type.Using
{}as a type means "any non-nullable value" and should be avoided. Instead, explicitly define the object shape.Apply this diff to explicitly define the object shape:
-export type Result$Outbound = {}; +export type Result$Outbound = { + // Define the properties of the Result$Outbound type here +};Committable suggestion was skipped due to low confidence.
Tools
Biome
[error] 20-20: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
cardinal/sdk/typescript/src/funcs/getDebugState.ts (4)
51-60: Handle potential errors when creating the request.
The function should handle potential errors when creating the request using
client$.createRequest$.Apply this diff to handle potential errors:
const requestRes = client$.createRequest$( context, { method: "POST", path: path$, headers: headers$, timeoutMs: options?.timeoutMs || client$.options$.timeoutMs || -1, }, options ); if (!requestRes.ok) { return requestRes; } const request$ = requestRes.value; + if (!request$) { + throw new SDKError("Failed to create request"); + }Committable suggestion was skipped due to low confidence.
66-71: Handle potential errors when performing the request.
The function should handle potential errors when performing the request using
client$.do$.Apply this diff to handle potential errors:
const doResult = await client$.do$(request$, { context, errorCodes: ["4XX", "5XX"], retryConfig: options?.retries || client$.options$.retryConfig, retryCodes: options?.retryCodes || ["429", "500", "502", "503", "504"], }); if (!doResult.ok) { return doResult; } const response = doResult.value; + if (!response) { + throw new SDKError("Failed to perform request"); + }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.const doResult = await client$.do$(request$, { context, errorCodes: ["4XX", "5XX"], retryConfig: options?.retries || client$.options$.retryConfig, retryCodes: options?.retryCodes || ["429", "500", "502", "503", "504"], }); if (!doResult.ok) { return doResult; } const response = doResult.value; if (!response) { throw new SDKError("Failed to perform request"); }
28-31: Validate
client$parameter.The function should validate the
client$parameter to ensure it is not null or undefined before proceeding.Apply this diff to add validation:
export async function getDebugState( client$: CardinalCore, options?: RequestOptions ): Promise< Result< Array<components.DebugStateElement>, | SDKError | SDKValidationError | UnexpectedClientError | InvalidRequestError | RequestAbortedError | RequestTimeoutError | ConnectionError > > { + if (!client$) { + throw new SDKError("Client is not initialized"); + }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.export async function getDebugState( client$: CardinalCore, options?: RequestOptions ): Promise< Result< Array<components.DebugStateElement>, | SDKError | SDKValidationError | UnexpectedClientError | InvalidRequestError | RequestAbortedError | RequestTimeoutError | ConnectionError > > { if (!client$) { throw new SDKError("Client is not initialized"); }
77-89: Handle potential errors when matching the response.
The function should handle potential errors when matching the response using
m$.match.Apply this diff to handle potential errors:
const [result$] = await m$.match< Array<components.DebugStateElement>, | SDKError | SDKValidationError | UnexpectedClientError | InvalidRequestError | RequestAbortedError | RequestTimeoutError | ConnectionError >( m$.json(200, z.array(components.DebugStateElement$inboundSchema)), m$.fail(["4XX", "5XX"]) )(response); if (!result$.ok) { return result$; } + if (!result$.value) { + throw new SDKError("Failed to match response"); + }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.const [result$] = await m$.match< Array<components.DebugStateElement>, | SDKError | SDKValidationError | UnexpectedClientError | InvalidRequestError | RequestAbortedError | RequestTimeoutError | ConnectionError >( m$.json(200, z.array(components.DebugStateElement$inboundSchema)), m$.fail(["4XX", "5XX"]) )(response); if (!result$.ok) { return result$; } if (!result$.value) { throw new SDKError("Failed to match response"); }cardinal/sdk/typescript/src/models/errors/sdkvalidationerror.ts (2)
31-37: Handle potential errors when formatting the
ZodError.The
prettymethod should handle potential errors when formatting theZodError.Apply this diff to handle potential errors:
public pretty(): string { if (this.cause instanceof z.ZodError) { + try { return `${this.rawMessage}\n${formatZodError(this.cause)}`; + } catch (error) { + return this.toString(); + } } else { return this.toString(); } }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public pretty(): string { if (this.cause instanceof z.ZodError) { try { return `${this.rawMessage}\n${formatZodError(this.cause)}`; } catch (error) { return this.toString(); } } else { return this.toString(); } }
18-23: Validate
messageandrawValueparameters.The constructor should validate the
messageandrawValueparameters to ensure they are not null or undefined before proceeding.Apply this diff to add validation:
constructor(message: string, cause: unknown, rawValue: unknown) { + if (!message) { + throw new Error("Message is required"); + } + if (rawValue === undefined || rawValue === null) { + throw new Error("Raw value is required"); + } super(`${message}: ${cause}`); this.name = "SDKValidationError"; this.cause = cause; this.rawValue = rawValue; this.rawMessage = message; }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.constructor(message: string, cause: unknown, rawValue: unknown) { if (!message) { throw new Error("Message is required"); } if (rawValue === undefined || rawValue === null) { throw new Error("Raw value is required"); } super(`${message}: ${cause}`); this.name = "SDKValidationError"; this.cause = cause; this.rawValue = rawValue; this.rawMessage = message; }cardinal/sdk/typescript/src/hooks/hooks.ts (1)
53-55: Consider using
Promise.allfor better performance.The methods
beforeRequest,afterSuccess, andafterErroruseawaitinside a loop. UsingPromise.allcan improve performance by running the hooks concurrently.Apply this diff to use
Promise.all:async beforeRequest(hookCtx: BeforeRequestContext, request: Request): Promise<Request> { - let req = request; + let req = await Promise.all(this.beforeRequestHooks.map(hook => hook.beforeRequest(hookCtx, request))); return req; } async afterSuccess(hookCtx: AfterSuccessContext, response: Response): Promise<Response> { - let res = response; + let res = await Promise.all(this.afterSuccessHooks.map(hook => hook.afterSuccess(hookCtx, response))); return res; } async afterError( hookCtx: AfterErrorContext, response: Response | null, error: unknown ): Promise<{ response: Response | null; error: unknown }> { - let res = response; - let err = error; + let [res, err] = await Promise.all(this.afterErrorHooks.map(hook => hook.afterError(hookCtx, response, error))); return { response: res, error: err }; }Also applies to: 57-65, 67-75, 77-85, 87-102
cardinal/sdk/typescript/src/funcs/queryCQL.ts (1)
47-51: Improve error handling by providing detailed error messages.
The function handles various errors but the error messages can be more detailed to help with debugging.
Apply this diff to provide more detailed error messages:
if (!parsed$.ok) { - return parsed$; + return { ok: false, error: new SDKValidationError("Input validation failed: " + parsed$.error.message) }; } if (!requestRes.ok) { - return requestRes; + return { ok: false, error: new SDKError("Request creation failed: " + requestRes.error.message) }; } if (!doResult.ok) { - return doResult; + return { ok: false, error: new SDKError("Request execution failed: " + doResult.error.message) }; } if (!result$.ok) { - return result$; + return { ok: false, error: new SDKError("Response processing failed: " + result$.error.message) }; }Also applies to: 52-54, 78-80, 89-91, 107-109
cardinal/sdk/typescript/src/funcs/getReceipts.ts (1)
47-51: Improve error handling by providing detailed error messages.
The function handles various errors but the error messages can be more detailed to help with debugging.
Apply this diff to provide more detailed error messages:
if (!parsed$.ok) { - return parsed$; + return { ok: false, error: new SDKValidationError("Input validation failed: " + parsed$.error.message) }; } if (!requestRes.ok) { - return requestRes; + return { ok: false, error: new SDKError("Request creation failed: " + requestRes.error.message) }; } if (!doResult.ok) { - return doResult; + return { ok: false, error: new SDKError("Request execution failed: " + doResult.error.message) }; } if (!result$.ok) { - return result$; + return { ok: false, error: new SDKError("Response processing failed: " + result$.error.message) }; }Also applies to: 52-54, 78-80, 89-91, 107-109
cardinal/sdk/typescript/src/hooks/sign.ts (1)
1-4: Use the
node:protocol for importing Node.js built-in modules.Using the
node:protocol is more explicit and signals that the imported module belongs to Node.js.-import * as crypto from 'crypto' +import * as crypto from 'node:crypto'The code changes are approved with the suggested modification.
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.import { secp256k1 } from '@noble/curves/secp256k1' // import { generatePrivateKey, privateKeyToAccount } from 'viem/accounts' import { keccak256, toHex } from 'viem/utils' import * as crypto from 'node:crypto'Tools
Biome
[error] 4-4: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.(lint/style/useNodejsImportProtocol)
cardinal/sdk/typescript/FUNCTIONS.md (4)
5-5: Fix trailing spaces and missing newline.
Remove trailing spaces and add a newline at the end of the file.
Apply this diff to fix the trailing spaces and missing newline:
- > runtimes where the size of an application affects performance and load times. + > runtimes where the size of an application affects performance and load times. +Also applies to: 107-107
Tools
Markdownlint
5-5: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
15-15: Fix redundant comparative.
Remove the redundant "more" for correctness.
Apply this diff to fix the redundant comparative:
- Calling methods through the main SDK class remains a valid and generally more more ergonomic option. + Calling methods through the main SDK class remains a valid and generally more ergonomic option.Committable suggestion was skipped due to low confidence.
Tools
LanguageTool
[grammar] ~15-~15: Use only “more” (without ‘more’) when you use the comparative.
Context: ...SDK class remains a valid and generally more more ergonomic option. Standalone functions ...(MOST_COMPARATIVE)
11-12: Fix grammar and style issues.
The sentence should be revised for clarity and correctness.
Apply this diff to fix the grammar and style issues:
- The result is dramatically smaller impact on the application's final bundle size which grows very slowly as you use more and more functionality from this SDK. + The result is a dramatically smaller impact on the application's final bundle size, which grows very slowly as you use more and more functionality from this SDK.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.encoding helpers and response handlers. The result is a dramatically smaller impact on the application's final bundle size, which grows very slowly as you useTools
LanguageTool
[uncategorized] ~11-~11: You might be missing the article “a” here.
Context: ...rs and response handlers. The result is dramatically smaller impact on the application's fin...(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~12-~12: A comma might be missing here.
Context: ...mpact on the application's final bundle size which grows very slowly as you use more...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
78-78: Fix redundancy.
Remove the redundant "because" for clarity.
Apply this diff to fix the redundancy:
- The second reason for this style of programming is because these functions will typically be used in front-end applications where exception throwing is sometimes discouraged or considered unidiomatic. + The second reason for this style of programming is that these functions will typically be used in front-end applications where exception throwing is sometimes discouraged or considered unidiomatic.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.The second reason for this style of programming is that these functions willTools
LanguageTool
[style] ~78-~78: The word “because” means “for the reason that” and thus introduces redundancy.
Context: ...nd reason for this style of programming is because these functions will typically be used ...(REASON_IS_BECAUSE)
cardinal/sdk/typescript/src/lib/retries.ts (2)
128-183: Use
Number.isNaNinstead ofisNaN.The function
retryBackoffis correctly implemented, but the usage ofisNaNcan be optimized.- if (!isNaN(parsedNumber) && Number.isInteger(parsedNumber)) { + if (!Number.isNaN(parsedNumber) && Number.isInteger(parsedNumber)) {- if (!isNaN(parsedDate)) { + if (!Number.isNaN(parsedDate)) {Tools
Biome
[error] 160-160: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
[error] 164-164: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
106-125: Use a regular expression literal.
The function
isRetryableResponseis correctly implemented, but the regular expression can be optimized by using a literal notation.-const codeRangeRE = new RegExp("^[0-9]xx$", "i"); +const codeRangeRE = /^[0-9]xx$/i;Committable suggestion was skipped due to low confidence.
scripts/pre-speakeasy.js (2)
1-2: Use
node:protocol for Node.js built-in modules.Using the
node:protocol is more explicit and signals that the imported module belongs to Node.js.-const fs = require('fs') +const fs = require('node:fs')Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.const fs = require('node:fs')Tools
Biome
[error] 1-1: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.(lint/style/useNodejsImportProtocol)
85-103: Avoid using the
deleteoperator.Using the
deleteoperator can impact performance. Consider setting properties toundefinedinstead.-delete data.components.schemas['pkg_world_dev_world-engine_cardinal_types.EntityStateElement'].properties.data.items.properties +data.components.schemas['pkg_world_dev_world-engine_cardinal_types.EntityStateElement'].properties.data.items.properties = undefined -delete data.components.schemas['pkg_world_dev_world-engine_cardinal_types.DebugStateElement'].properties.components.properties +data.components.schemas['pkg_world_dev_world-engine_cardinal_types.DebugStateElement'].properties.components.properties = undefined -delete data.components.schemas['cardinal_server_handler.Transaction'].properties.body.properties +data.components.schemas['cardinal_server_handler.Transaction'].properties.body.properties = undefinedCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.// POST /cql data.components.schemas['pkg_world_dev_world-engine_cardinal_types.EntityStateElement'].properties.data.items.properties = undefined data.components.schemas['pkg_world_dev_world-engine_cardinal_types.EntityStateElement'].properties.data.items.additionalProperties = {} // POST /debug/state data.components.schemas['pkg_world_dev_world-engine_cardinal_types.DebugStateElement'].properties.components.properties = undefined data.components.schemas['pkg_world_dev_world-engine_cardinal_types.DebugStateElement'].properties.components.additionalProperties = {} // POST /query/game/{queryName} data.paths['/query/game/{queryName}'].post.requestBody.content['application/json'].schema.additionalProperties = {} data.paths['/query/game/{queryName}'].post.responses['200'].content['application/json'].schema.additionalProperties = {} // POST /tx/persona/create-persona, POST /tx/game/{txName} data.components.schemas['cardinal_server_handler.Transaction'].properties.body.properties = undefined data.components.schemas['cardinal_server_handler.Transaction'].properties.body.additionalProperties = {} // GET /world data.components.schemas['pkg_world_dev_world-engine_cardinal_types.FieldDetail'].properties.fields.additionalProperties = {}Tools
Biome
[error] 85-86: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 89-90: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 97-98: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
cardinal/sdk/typescript/src/lib/http.ts (1)
208-208: Use a regular expression literal instead of the
RegExpconstructor.Using a regular expression literal is recommended for simplicity and performance.
-const codeRangeRE = new RegExp("^[0-9]xx$", "i"); +const codeRangeRE = /^[0-9]xx$/i;Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.const codeRangeRE = /^[0-9]xx$/i;Tools
Biome
[error] 208-208: Use a regular expression literal instead of the RegExp constructor.
Regular expression literals avoid some escaping required in a string literal, and are easier to analyze statically.
Safe fix: Use a literal notation instead.(lint/complexity/useRegexLiterals)
cardinal/server/docs/swagger.yaml (3)
226-255: LGTM! But fix indentation issues.
The new endpoint
/query/game/{queryName}expands the available API operations. Fix the indentation issues flagged by static analysis tools.Apply this diff to fix the indentation issues:
- post: - consumes: - - application/json + post: + consumes: + - application/jsonCommittable suggestion was skipped due to low confidence.
Tools
yamllint
[error] 229-229: wrong indentation: expected 8 but found 6
(indentation)
[error] 233-233: wrong indentation: expected 8 but found 6
(indentation)
[error] 245-245: wrong indentation: expected 8 but found 6
(indentation)
261-261: LGTM! But fix indentation issues.
The addition of
operationIdfor thegetReceiptsendpoint standardizes the API's structure. Fix the indentation issues flagged by static analysis tools.Apply this diff to fix the indentation issues:
- post: - consumes: - - application/json + post: + consumes: + - application/jsonCommittable suggestion was skipped due to low confidence.
103-105: > [!TIP]
Codebase Verification
Incomplete Renaming Detected: Update All References
The renaming from
DebugStateElementtoEntityStateElementis incomplete. There are still references toDebugStateElementin theswagger.yamlfile. Please update the following lines to ensure consistency:
cardinal/server/docs/swagger.yaml: References toDebugStateElementare still present.Analysis chain
LGTM! But verify all references.
The renaming of
DebugStateElementtoEntityStateElementmight indicate a shift in its intended use or context. Ensure all references are updated accordingly.Run the following script to verify all references to
EntityStateElement:Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all references to `EntityStateElement`. # Test: Search for the references. Expect: Only occurrences of the new name. rg --type yaml 'EntityStateElement'Length of output: 260
Script:
#!/bin/bash # Description: Verify all references to `DebugStateElement` to ensure they are updated. # Test: Search for any remaining references to `DebugStateElement`. rg --type yaml 'DebugStateElement'Length of output: 261
cardinal/server/docs/openapi.json (1)
509-734: > [!TIP]
Codebase Verification
Define Maximum Item Limits for Arrays
The OpenAPI specification contains several array definitions without a specified maximum number of items. To ensure the robustness and performance of the API, it's recommended to define these limits. Consider reviewing the following locations:
cardinal/server/docs/openapi.json: Multiple arrays without maximum item limits.Analysis chain
LGTM! But address potential issues.
The schema definitions are correctly defined and aligned with the endpoints. However, consider addressing the following potential issues:
- Ensure that the global security field has rules defined.
- Ensure that security operations are not empty.
- Ensure that arrays have a maximum number of items.
The code changes are approved.
Run the following script to verify the potential issues:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the potential issues in the OpenAPI specification. # Test: Ensure that the global security field has rules defined. rg --type json -A 5 '"security": \[\]' # Test: Ensure that security operations are not empty. rg --type json -A 5 '"security": \[\]' # Test: Ensure that arrays have a maximum number of items. rg --type json -A 5 '"type": "array"'Length of output: 9301
Tools
checkov
[HIGH] 1-734: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[HIGH] 1-734: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
cardinal/sdk/typescript/README.md (7)
178-223: Correct missing comma and grammatical issue.
Address the missing comma and grammatical issue in the error handling section.
- Validation errors can also occur when either method arguments or data returned from the server do not match the expected format. The `SDKValidationError` that is thrown as a result will capture the raw value that failed validation in an attribute called `rawValue`. Additionally, a `pretty()` method is available on this error that can be used to log a nicely formatted string since validation errors can list many issues and the plain error string may be difficult read when debugging. + Validation errors can also occur when either method arguments or data returned from the server do not match the expected format. The `SDKValidationError` that is thrown as a result will capture the raw value that failed validation in an attribute called `rawValue`. Additionally, a `pretty()` method is available on this error that can be used to log a nicely formatted string, since validation errors can list many issues, and the plain error string may be difficult to read when debugging.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.Validation errors can also occur when either method arguments or data returned from the server do not match the expected format. The `SDKValidationError` that is thrown as a result will capture the raw value that failed validation in an attribute called `rawValue`. Additionally, a `pretty()` method is available on this error that can be used to log a nicely formatted string, since validation errors can list many issues, and the plain error string may be difficult to read when debugging.Tools
LanguageTool
[uncategorized] ~187-~187: Possible missing comma found.
Context: ...t can be used to log a nicely formatted string since validation errors can list many i...(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~187-~187: The infinitive “read” after “be” requires “to”. Did you mean “be difficult to read”?
Context: ...y issues and the plain error string may be difficult read when debugging. ```typescript import...(WOULD_BE_JJ_VB)
Markdownlint
187-187: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
189-189: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
187-187: Expected: 250; Actual: 487
Line length(MD013, line-length)
277-291: Correct grammatical issue.
Address the grammatical issue in the debugging section.
- You can setup your SDK to emit debug logs for SDK requests and responses. + You can set up your SDK to emit debug logs for SDK requests and responses.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.<!-- Start Debugging [debug] --> ## Debugging You can set up your SDK to emit debug logs for SDK requests and responses. You can pass a logger that matches `console`'s interface as an SDK option. > [!WARNING] > Beware that debug logging will reveal secrets, like API tokens in headers, in log messages printed to a console or files. It's recommended to use this feature only during local development and not in production. ```typescript import { Cardinal } from "@arguslabs/cardinal"; const sdk = new Cardinal({ debugLogger: console }); ```Tools
LanguageTool
[grammar] ~280-~280: The word “setup” is a noun. The verb is spelled with a space.
Context: ...gging [debug] --> ## Debugging You can setup your SDK to emit debug logs for SDK req...(NOUN_VERB_CONFUSION)
294-319: Correct unordered list style and multiple consecutive blank lines.
Address the unordered list style and multiple consecutive blank lines in the standalone functions section.
- - [createPersona](docs/sdks/cardinal/README.md#createpersona) - - [getDebugState](docs/sdks/cardinal/README.md#getdebugstate) - - [getHealth](docs/sdks/cardinal/README.md#gethealth) - - [getReceipts](docs/sdks/cardinal/README.md#getreceipts) - - [getWorld](docs/sdks/cardinal/README.md#getworld) - - [queryCQL](docs/sdks/cardinal/README.md#querycql) - - [query](docs/sdks/cardinal/README.md#query) - - [transact](docs/sdks/cardinal/README.md#transact) + * [createPersona](docs/sdks/cardinal/README.md#createpersona) + * [getDebugState](docs/sdks/cardinal/README.md#getdebugstate) + * [getHealth](docs/sdks/cardinal/README.md#gethealth) + * [getReceipts](docs/sdks/cardinal/README.md#getreceipts) + * [getWorld](docs/sdks/cardinal/README.md#getworld) + * [queryCQL](docs/sdks/cardinal/README.md#querycql) + * [query](docs/sdks/cardinal/README.md#query) + * [transact](docs/sdks/cardinal/README.md#transact)Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.<!-- Start Standalone functions [standalone-funcs] --> ## Standalone functions All the methods listed above are available as standalone functions. These functions are ideal for use in applications running in the browser, serverless runtimes or other environments where application bundle size is a primary concern. When using a bundler to build your application, all unused functionality will be either excluded from the final bundle or tree-shaken away. To read more about standalone functions, check [FUNCTIONS.md](./FUNCTIONS.md). <details> <summary>Available standalone functions</summary> * [createPersona](docs/sdks/cardinal/README.md#createpersona) * [getDebugState](docs/sdks/cardinal/README.md#getdebugstate) * [getHealth](docs/sdks/cardinal/README.md#gethealth) * [getReceipts](docs/sdks/cardinal/README.md#getreceipts) * [getWorld](docs/sdks/cardinal/README.md#getworld) * [queryCQL](docs/sdks/cardinal/README.md#querycql) * [query](docs/sdks/cardinal/README.md#query) * [transact](docs/sdks/cardinal/README.md#transact) </details>Tools
Markdownlint
309-309: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
310-310: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
311-311: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
312-312: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
313-313: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
314-314: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
315-315: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
316-316: Expected: asterisk; Actual: dash
Unordered list style(MD004, ul-style)
318-318: Expected: 1; Actual: 2
Multiple consecutive blank lines(MD012, no-multiple-blanks)
305-305: Element: details
Inline HTML(MD033, no-inline-html)
307-307: Element: summary
Inline HTML(MD033, no-inline-html)
326-339: Correct trailing spaces, grammatical issue, and style issue.
Address the trailing spaces, grammatical issue, and style issue in the development section.
- This SDK is in beta, and there may be breaking changes between versions without a major version update. Therefore, we recommend pinning usage - to a specific package version. This way, you can install the same version each time without breaking changes unless you are intentionally - looking for the latest version. + This SDK is in beta, and there may be breaking changes between versions without a major version update. Therefore, we recommend pinning usage to a specific package version. This way, you can install the same version each time without breaking changes unless you are intentionally looking for the latest version. - While we value open-source contributions to this SDK, this library is generated programmatically. Any manual changes added to internal files will be overwritten on the next generation. + While we value open-source contributions to this SDK, this library is generated programmatically. Any manual changes added to internal files will be overwritten on the next generation. - We look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of concept and we'll do our best to include it in a future release. + We look forward to hearing your feedback. Please open a PR or an issue with a proof of concept, and we'll do our best to include it in a future release.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.# Development ## Maturity This SDK is in beta, and there may be breaking changes between versions without a major version update. Therefore, we recommend pinning usage to a specific package version. This way, you can install the same version each time without breaking changes unless you are intentionally looking for the latest version. ## Contributions While we value open-source contributions to this SDK, this library is generated programmatically. Any manual changes added to internal files will be overwritten on the next generation. We look forward to hearing your feedback. Please open a PR or an issue with a proof of concept, and we'll do our best to include it in a future release. ### SDK Created by [Speakeasy](https://www.speakeasy.com/?utm_source=&utm_campaign=typescript)Tools
LanguageTool
[style] ~337-~337: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ... look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of c...(FEEL_FREE_TO_STYLE_ME)
[uncategorized] ~337-~337: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...a PR or an issue with a proof of concept and we'll do our best to include it in a fu...(COMMA_COMPOUND_SENTENCE)
Markdownlint
336-336: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
337-337: Expected: 0 or 2; Actual: 1
Trailing spaces(MD009, no-trailing-spaces)
326-326: null
Multiple top-level headings in the same document(MD025, single-title, single-h1)
94-107: Use asterisks for unordered list.
The unordered list style should be consistent. Use asterisks instead of dashes.
- [createPersona](docs/sdks/cardinal/README.md#createpersona) - [getDebugState](docs/sdks/cardinal/README.md#getdebugstate) - [getHealth](docs/sdks/cardinal/README.md#gethealth) - [getReceipts](docs/sdks/cardinal/README.md#getreceipts) - [getWorld](docs/sdks/cardinal/README.md#getworld) - [queryCQL](docs/sdks/cardinal/README.md#querycql) - [query](docs/sdks/cardinal/README.md#query) - [transact](docs/sdks/cardinal/README.md#transact) + * [createPersona](docs/sdks/cardinal/README.md#createpersona) + * [getDebugState](docs/sdks/cardinal/README.md#getdebugstate) + * [getHealth](docs/sdks/cardinal/README.md#gethealth) + * [getReceipts](docs/sdks/cardinal/README.md#getreceipts) + * [getWorld](docs/sdks/cardinal/README.md#getworld) + * [queryCQL](docs/sdks/cardinal/README.md#querycql) + * [query](docs/sdks/cardinal/README.md#query) + * [transact](docs/sdks/cardinal/README.md#transact)Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.<!-- Start Available Resources and Operations [operations] --> ## Available Resources and Operations ### [Cardinal SDK](docs/sdks/cardinal/README.md) * [queryCQL](docs/sdks/cardinal/README.md#querycql) - Executes a CQL (Cardinal Query Language) query * [getDebugState](docs/sdks/cardinal/README.md#getdebugstate) - Retrieves a list of all entities in the game state * [getHealth](docs/sdks/cardinal/README.md#gethealth) - Retrieves the status of the server and game loop * [query](docs/sdks/cardinal/README.md#query) - Executes a query * [getReceipts](docs/sdks/cardinal/README.md#getreceipts) - Retrieves all transaction receipts * [transact](docs/sdks/cardinal/README.md#transact) - Submits a transaction * [createPersona](docs/sdks/cardinal/README.md#createpersona) - Creates a persona * [getWorld](docs/sdks/cardinal/README.md#getworld) - Retrieves details of the game world <!-- End Available Resources and Operations [operations] -->
109-175: Address line length issue.
The line length exceeds the recommended limit. Consider breaking the line into shorter segments.
- Some of the endpoints in this SDK support retries. If you use the SDK without any configuration, it will fall back to the default retry strategy provided by the API. However, the default retry strategy can be overridden on a per-operation basis, or across the entire SDK. + Some of the endpoints in this SDK support retries. If you use the SDK without any configuration, + it will fall back to the default retry strategy provided by the API. However, the default retry + strategy can be overridden on a per-operation basis, or across the entire SDK.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.<!-- Start Retries [retries] --> ## Retries Some of the endpoints in this SDK support retries. If you use the SDK without any configuration, it will fall back to the default retry strategy provided by the API. However, the default retry strategy can be overridden on a per-operation basis, or across the entire SDK. To change the default retry strategy for a single API call, simply provide a retryConfig object to the call: ```typescript import { Cardinal } from "@arguslabs/cardinal"; const cardinal = new Cardinal(); async function run() { const result = await cardinal.queryCQL( { cql: "CONTAINS(Health)", }, { retries: { strategy: "backoff", backoff: { initialInterval: 1, maxInterval: 50, exponent: 1.1, maxElapsedTime: 100, }, retryConnectionErrors: false, }, } ); // Handle the result console.log(result); } run(); ``` If you'd like to override the default retry strategy for all operations that support retries, you can provide a retryConfig at SDK initialization: ```typescript import { Cardinal } from "@arguslabs/cardinal"; const cardinal = new Cardinal({ retryConfig: { strategy: "backoff", backoff: { initialInterval: 1, maxInterval: 50, exponent: 1.1, maxElapsedTime: 100, }, retryConnectionErrors: false, }, }); async function run() { const result = await cardinal.queryCQL({ cql: "CONTAINS(Health)", }); // Handle the result console.log(result); } run(); ```Tools
Markdownlint
112-112: Expected: 250; Actual: 273
Line length(MD013, line-length)
115-115: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
148-148: null
Fenced code blocks should be surrounded by blank lines(MD031, blanks-around-fences)
228-274: Correct repeated word.
Address the repeated word in the custom HTTP client section.
- The following example shows how to use the `"beforeRequest"` hook to to add a custom header and a timeout to requests and how to use the `"requestError"` hook to log errors: + The following example shows how to use the `"beforeRequest"` hook to add a custom header and a timeout to requests and how to use the `"requestError"` hook to log errors:Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.<!-- Start Custom HTTP Client [http-client] --> ## Custom HTTP Client The TypeScript SDK makes API calls using an `HTTPClient` that wraps the native [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API). This client is a thin wrapper around `fetch` and provides the ability to attach hooks around the request lifecycle that can be used to modify the request or handle errors and response. The `HTTPClient` constructor takes an optional `fetcher` argument that can be used to integrate a third-party HTTP client or when writing tests to mock out the HTTP client and feed in fixtures. The following example shows how to use the `"beforeRequest"` hook to add a custom header and a timeout to requests and how to use the `"requestError"` hook to log errors: ```typescript import { Cardinal } from "@arguslabs/cardinal"; import { HTTPClient } from "@arguslabs/cardinal/lib/http"; const httpClient = new HTTPClient({ // fetcher takes a function that has the same signature as native `fetch`. fetcher: (request) => { return fetch(request); } }); httpClient.addHook("beforeRequest", (request) => { const nextRequest = new Request(request, { signal: request.signal || AbortSignal.timeout(5000) }); nextRequest.headers.set("x-custom-header", "custom value"); return nextRequest; }); httpClient.addHook("requestError", (error, request) => { console.group("Request Error"); console.log("Reason:", `${error}`); console.log("Endpoint:", `${request.method} ${request.url}`); console.groupEnd(); }); const sdk = new Cardinal({ httpClient });Tools
LanguageTool
[duplication] ~241-~241: Possible typo: you repeated a word
Context: ...s how to use the"beforeRequest"hook to to add a custom header and a timeout to re...(ENGLISH_WORD_REPEAT_RULE)
|
closing this for now |
Closes: WORLD-1180
Overview
Setup Speakeasy to generate SDKs for cardinal.
Change Breakdown
Speakeasy configuration
Speakeasy is configured using the
workflow.yamlandgen.yamlin the.speakeasydir in the root directory. Package names, SDK languages, input/output dir, etc. goes here. The generated SDKs go incardinal/sdk/[language-name]. ATM only typescript is generated.Speakeasy Generation Workflow
This PR introduces some scripts that needs to be run before and after generating the SDK for everyting to work correctly. See
makefiles/api.mk,scripts/pre-speakeasy.js,andscripts/post-speakeasy.sh. Here are the steps to generate the SDK:make swaggerto generate theswagger.jsonfile.make swagger-codegen-installto install the swagger -> openapi 3 convertermake speakeasy. this will:a. Convert
swagger.jsontoopenapi.jsonb. Run
scripts/pre-speakeasy.jsto modifyopenapi.jsonfilesc. Run
speakeasy runto generate the SDKd. Run
scripts/post-speakeasy.shto modify the generated SDKThis workflow works, but requires the machine to have Java and Node installed.
Generated TypeScript SDK
The SDK is generated in
cardinal/sdk/typescript. The only code that needs review here are in thecardinal/sdk/typescript/src/hooksdir, which contains custom hooks to sign transactions for the users. Seehooks/cardinal.ts, which contains the custom hooks, andhooks/sign.ts, which contains the signing function (also used in the cardinal editor).To get a quick feel of the SDK, read the README and the SDK docs.
Changes in Cardinal
Most of the changes in the cardinal code are only in the swaggo/swag comments/docstrings.
NOTE: 1 breaking change in cardinal is introduced in this PR. Transaction responses keys are changed to follow JSON conventions. See
cardinal/server/handler/tx.go.New GitHub Actions
See
.github/workflows/sdk_generation.yamland.github/workflows/sdk_publish.yaml.Testing and Verifying
Manually tested & verified
Summary by CodeRabbit
New Features
Documentation