feat(sdk-agnostic-lib): add config package - #331
Conversation
… app-data project into the monorepo
…repo-structure-into-cow-sdk-repository Jefferson/cow 468 integrate new monorepo structure into cow sdk repository
Create app data package
WalkthroughThis update introduces a new monorepo structure for the CoW Protocol SDK, splitting functionality into modular packages. It adds the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant MetadataApi
participant Adapter
participant IPFS
participant SchemaLoader
User->>MetadataApi: new MetadataApi(adapter)
MetadataApi->>Adapter: setGlobalAdapter(adapter)
User->>MetadataApi: getAppDataSchema(version)
MetadataApi->>SchemaLoader: importSchema(version)
SchemaLoader-->>MetadataApi: JSON Schema
User->>MetadataApi: generateAppDataDoc(params)
MetadataApi-->>User: AppDataDoc
User->>MetadataApi: getAppDataInfo(doc)
MetadataApi->>Adapter: validateAppDataDoc(doc)
Adapter-->>MetadataApi: ValidationResult
MetadataApi->>IPFS: (optional) fetchDocFromAppDataHex(hex)
IPFS-->>MetadataApi: AppDataDoc
MetadataApi-->>User: AppDataInfo / AppDataDoc
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
I have read the CLA Document and I hereby sign the CLA 1 out of 2 committers have signed the CLA. |
jean-neiverth
changed the title
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 49
🔭 Outside diff range comments (1)
packages/app-data/src/generatedTypes/v0.8.0.ts (1)
53-84: 💡 Verification agent🧩 Analysis chain
Missing index signatures reduce extensibility.
Unlike earlier versions (v0.3.0, v0.5.0), this version doesn't include
[k: string]: unknownindex signatures in the interfaces, making them less extensible for additional properties.Verify whether the removal of index signatures in v0.8.0 is intentional:
🏁 Script executed:
#!/bin/bash # Description: Check for index signature patterns across schema versions # Search for index signatures in generated types rg "\[k: string\]: unknown" packages/app-data/src/generatedTypes/Length of output: 2339
Missing index signatures in v0.8.0 reduce extensibility
A quick grep confirms that every prior version (v0.1.0–v0.7.0) included
[k: string]: unknownon its generated interfaces, but v0.8.0 has dropped them entirely. Without these index signatures, consumers can’t safely add extra properties to the data objects.Please re-introduce the index signatures (or confirm this was an intentional breaking change):
• File:
packages/app-data/src/generatedTypes/v0.8.0.tsexport interface AppDataRootSchema { version: Version; appCode?: AppCode; environment?: Environment; metadata: Metadata; + [k: string]: unknown; } /** * Each metadata will specify one aspect of the order. */ export interface Metadata { referrer?: Referrer; utm?: UTMCodes; quote?: Quote; orderClass?: OrderClass; + [k: string]: unknown; } // …and similarly on Referrer, UTMCodes, Quote, OrderClassIf this removal was intentional, please call it out in the changelog; otherwise, let’s restore the signatures for consistency and backwards-compatibility.
🧹 Nitpick comments (32)
packages/app-data/src/api/cidToAppDataHex.ts (1)
9-11: Simplify promise forwarding
Since you’re directly returning the promise fromextractDigest, you can drop theasynckeyword:-export async function cidToAppDataHex(cid: string): Promise<string> { - return extractDigest(cid) -} +export function cidToAppDataHex(cid: string): Promise<string> { + return extractDigest(cid) +}packages/app-data/setupTests.cjs (1)
1-7: ESLint configuration needs adjustment for test files.The static analysis warnings are false positives in this test setup context. The code correctly uses:
global(available in Node.js)require()(valid in.cjsfiles)jestandfetchMock(available in test environment)Consider adding ESLint overrides for test files to avoid these false positive warnings:
{ "overrides": [ { "files": ["**/*.cjs", "**/setupTests.*"], "env": { "node": true, "jest": true }, "rules": { "@typescript-eslint/no-require-imports": "off", "no-undef": "off" } } ] }🧰 Tools
🪛 ESLint
[error] 1-1: 'global' is not defined.
(no-undef)
[error] 1-1: A
require()style import is forbidden.(@typescript-eslint/no-require-imports)
[error] 1-1: 'require' is not defined.
(no-undef)
[error] 3-3: 'global' is not defined.
(no-undef)
[error] 3-3: 'global' is not defined.
(no-undef)
[error] 5-5: 'fetchMock' is not defined.
(no-undef)
[error] 7-7: 'jest' is not defined.
(no-undef)
[error] 7-7: 'fetchMock' is not defined.
(no-undef)
packages/app-data/src/api/fetchDocFromCid.spec.ts (1)
4-20: Consider adding error handling test cases.The current test only covers the happy path. Consider adding tests for error scenarios such as network failures, invalid JSON responses, or HTTP error status codes.
Example additional test cases:
test('Network error handling', async () => { // given const cid = 'QmZZhNnqMF1gRywNKnTPuZksX7rVjQgTT3TJAZ7R6VE3b2' fetchMock.mockRejectOnce(new Error('Network error')) // when/then await expect(fetchDocFromCid(cid)).rejects.toThrow('Network error') }) test('Invalid JSON response', async () => { // given const cid = 'QmZZhNnqMF1gRywNKnTPuZksX7rVjQgTT3TJAZ7R6VE3b2' fetchMock.mockResponseOnce('invalid json') // when/then await expect(fetchDocFromCid(cid)).rejects.toThrow() })packages/app-data/src/api/cidToAppDataHex.test.ts (2)
1-1: Remove unnecessary fetchMock import.The
cidToAppDataHexfunction doesn't use fetch (it callsextractDigestdirectly), so thefetchMockimport is unnecessary.-import fetchMock from 'jest-fetch-mock' import { APP_DATA_HEX, APP_DATA_HEX_2, CID, CID_2 } from '../mocks' import { cidToAppDataHex } from './cidToAppDataHex'
5-7: Remove unnecessary fetchMock reset.Since
fetchMockis not needed for this test, the reset call should be removed.-beforeEach(() => { - fetchMock.resetMocks() -})packages/app-data/src/schemas/quote/v0.3.0.json (1)
9-16: Consider consistency in schema definition approach.This schema defines
slippageBipsinline as a string with pattern validation, while the v1.0.0 schema references an external definitions file. Consider standardizing the approach across versions for better maintainability.For consistency with v1.0.0, consider using the external reference approach:
"slippageBips": { - "$id": "#/properties/slippageBips", - "title": "Slippage Bips", - "description": "Slippage tolerance that was applied to the order to get the limit price. Expressed in Basis Points (BPS)", - "examples": ["5", "10", "20", "100"], - "pattern": "^\\d+(\\.\\d+)?$", - "type": "string" + "title": "Slippage Bips", + "description": "Slippage tolerance that was applied to the order to get the limit price. Expressed in Basis Points (BPS)", + "$ref": "../definitions.json#/definitions/bps" }packages/app-data/src/schemas/utm/v0.2.0.json (1)
16-16: Clarify description differences between utmSource and utmMedium.Both
utmSourceandutmMediumdescriptions mention "medium" but they track different aspects. The descriptions should be more distinct.Apply this diff to improve clarity:
- "description": "Tracks in which medium the traffic originated from (twitter, facebook, etc.)" + "description": "Tracks the source that sent traffic (twitter, facebook, etc.)"Also applies to: 25-25
packages/app-data/jest.config.cjs (1)
1-9: Address ESLint configuration for CommonJS files.The ESLint error about
'module' is not definedis a false positive since this is a CommonJS file (.cjsextension) wheremoduleis provided by the Node.js runtime. The Jest configuration itself looks correct for a TypeScript project with ESM support.Consider adding an ESLint configuration override for
.cjsfiles to avoid this false positive:{ "overrides": [ { "files": ["*.cjs"], "env": { "node": true, "commonjs": true } } ] }🧰 Tools
🪛 ESLint
[error] 1-1: 'module' is not defined.
(no-undef)
packages/app-data/src/api/getAppDataSchema.spec.ts (1)
10-11: Consider improving type safety for schema access.The
@ts-expect-errorcomments indicate that TypeScript doesn't know about the$idproperty. Consider adding proper typing for the schema objects to eliminate the need for error suppression.If the schema types can be enhanced to include the
$idproperty, it would improve type safety:// Instead of @ts-expect-error, consider typing the schema properly interface JSONSchema { $id?: string; // ... other schema properties }Alternatively, use type assertion if the property is guaranteed to exist:
- // @ts-expect-error schema.$id exists but TypeScript doesn't know about it - expect(schema.$id).toMatch(version) + expect((schema as any).$id).toMatch(version)Also applies to: 52-53
packages/app-data/src/api/getAppDataSchema.ts (3)
5-10: Fix JSDoc inconsistency.The JSDoc comment mentions "CowError" but the implementation uses
MetaDataError. Update the documentation to match the actual implementation./** * Wrapper around @cowprotocol/sdk-app-data getAppDataSchema * * Returns the appData schema for given version, if any - * Throws CowError when version doesn't exist + * Throws MetaDataError when version doesn't exist */
14-18: Improve error handling with proper type checking.The current error casting assumes the caught error is always an
Errorinstance, which may not be true in all cases.} catch (e) { // Wrapping @cowprotocol/sdk-app-data Error into MetaDataError // TODO - Use CowError after moving cowError to common package - const error = e as Error - throw new MetaDataError(error.message) + const message = e instanceof Error ? e.message : String(e) + throw new MetaDataError(message) }
16-16: Consider the TODO for future error handling consistency.The TODO indicates plans to use
CowErrorafter moving it to the common package. This suggests a broader error handling strategy across the SDK.Would you like me to help track this refactoring task or create an issue for the error handling consolidation?
packages/app-data/tsconfig.json (1)
6-7: Consider target/module compatibility for broader ecosystem support.Using
ESNextfor both module and target provides cutting-edge features but may limit compatibility. Consider if the package needs to support older environments or bundlers.If broader compatibility is needed, consider:
- "module": "ESNext", - "target": "ESNext", + "module": "ES2022", + "target": "ES2022",packages/common/src/adapters/context.ts (1)
17-19: Consider adding adapter validation.The
setAdaptermethod doesn't validate the input parameter. Consider adding basic validation to ensure a valid adapter is being set.public setAdapter(adapter: AbstractProviderAdapter): void { + if (!adapter) { + throw new Error('Adapter cannot be null or undefined') + } this._adapter = adapter }packages/app-data/src/api/generateAppDataDoc.spec.ts (1)
14-25: Consider more specific version validation.The test only checks that version is truthy. Consider verifying the actual version value matches the expected latest version constant.
- expect(version).toBeTruthy() + expect(version).toBe(LATEST_APP_DATA_VERSION) // Import this constantpackages/app-data/src/api/generateAppDataDoc.ts (1)
17-30: Update example comment to match latest version.The example in the documentation shows version "1.2.0" but the function uses
LATEST_APP_DATA_VERSIONwhich is "1.4.0" according to the relevant code snippets.Apply this diff to update the example:
- * "version": "1.2.0" + * "version": "1.4.0"packages/app-data/src/importSchema.ts (1)
20-21: Consider using asynchronous file operations.Synchronous file operations can block the event loop. Since the function is already async, consider using
fs.promises.readFilefor better performance.- const content = fs.readFileSync(schemaPath, 'utf8') - const schema = JSON.parse(content) as AnyAppDataDocVersion + const content = await fs.promises.readFile(schemaPath, 'utf8') + const schema = JSON.parse(content) as AnyAppDataDocVersionpackages/app-data/src/schemas/v0.11.0.json (1)
38-58: Consider adding validation for metadata property interdependencies.If certain metadata properties have relationships or constraints between them, consider adding schema-level validation rules to enforce these business logic constraints.
packages/app-data/src/schemas/v0.1.0.json (1)
10-32: Consider adding strictness viaadditionalProperties: false
To prevent undocumented fields at the root and withinmetadata, you may want to add"additionalProperties": falseat line 10 (root) and inside the metadata object.
packages/app-data/src/schemas/v0.7.0.json (1)
28-28: Minor inconsistency in description punctuation.The environment description lacks a period while other descriptions include one. Consider adding a period for consistency.
- "description": "Environment from which the order came from", + "description": "Environment from which the order came from.",packages/app-data/src/api/getAppDataInfo.spec.ts (2)
157-180: Global JSON.stringify mocking could affect other tests.Mocking
global.JSON.stringifytemporarily works for this test but could potentially interfere with other tests if not properly isolated. Consider using a more localized mocking approach or ensuring test isolation.Consider wrapping the JSON.stringify usage in a testable utility function instead of mocking the global:
// In getAppDataInfo.ts +import { legacyStringify } from '../utils/stringify' export async function getAppDataInfoLegacy( appDataAux: AnyAppDataDocVersion | string, ): Promise<AppDataInfo | undefined> { - const fullAppData = JSON.stringify(appDataAux) + const fullAppData = legacyStringify(appDataAux) return _appDataToCidAux(fullAppData, _appDataToCidLegacy) }
67-86: Dynamic require() calls could be replaced with more explicit imports.The pattern of using
require()within beforeEach for mock updates could be made more explicit and type-safe by importing the mocked modules directly.Consider this pattern for better type safety:
+import { extractDigest } from '../utils/ipfs' +import { appDataHexToCid } from './appDataHexToCid' beforeEach(() => { fetchMock.resetMocks() jest.clearAllMocks() - const { extractDigest } = require('../utils/ipfs') - extractDigest.mockImplementation((cid: string) => { + (extractDigest as jest.MockedFunction<typeof extractDigest>).mockImplementation((cid: string) => { // ... implementation })packages/app-data/src/utils/ipfs.ts (2)
35-35: Replace Buffer with cross-platform alternative.Using
Buffermay cause issues in browser environments where it's not natively available. Consider using a cross-platform alternative.Use a more universal approach:
- return `0x${Buffer.from(digest).toString('hex')}` + return `0x${Array.from(digest, byte => byte.toString(16).padStart(2, '0')).join('')}`Or ensure Buffer is available by importing it from a polyfill when needed.
20-29: Document supported multibase encodings.The function supports base16 and defaults to base58btc, but this isn't clearly documented. Consider adding JSDoc comments to clarify the supported encodings.
Add documentation:
+/** + * Gets the appropriate multibase decoder for the given IPFS hash. + * Supports: + * - base16 (prefix 'f') - used by CoW Protocol backend + * - base58btc (default) - standard IPFS encoding + */ async function getDecoder<Prefix extends string>(ipfsHash: string): Promise<MultibaseDecoder<Prefix> | undefined> {packages/app-data/src/schemas/v1.3.0.json (1)
79-79: Remove trailing blank line for consistency.Other schema files don't have a trailing blank line. Consider removing it to maintain consistency across the schema files.
- } -} - + } +}packages/app-data/test/schema.spec.ts (1)
1-1182: Consider splitting this large test file for better maintainability.While the test coverage is comprehensive, this 1182-line file tests 13 different schema versions. Consider refactoring into separate test files per schema version or logical groupings (e.g.,
v0.x.x.spec.ts,v1.x.x.spec.ts) to improve maintainability and make it easier to locate specific tests.packages/app-data/src/types.ts (1)
47-50: Consider improving type safety for ValidationResult.The current ValidationResult type allows
errorsto be present whensuccessis true, which could be confusing. Consider using a discriminated union for better type safety.-export type ValidationResult = { - success: boolean - errors?: string -} +export type ValidationResult = + | { success: true } + | { success: false; errors: string }This ensures that errors are only present when validation fails, providing better type safety and preventing invalid states.
packages/app-data/src/generatedTypes/v0.3.0.ts (1)
21-31: Redundant documentation for version types.The Version1 and Version2 types have identical documentation ("Semantic versioning of document") as the main Version type, which may be confusing since they serve the same purpose.
Consider having more specific documentation for Version1 and Version2 to clarify they're versioning for nested metadata objects, or use a shared JSDoc comment reference.
packages/app-data/src/scripts/compile.ts (2)
214-243: getLatestMetadataDocVersion function needs better error handling.The function has good error handling patterns but could benefit from more specific error messages and validation.
Consider adding more specific validation:
async function getLatestMetadataDocVersion(metadataDocName: string): Promise<string> { const metadataPath = path.join(SCHEMAS_SRC_PATH, metadataDocName) try { + // Validate input parameter + if (!metadataDocName.trim()) { + console.warn('Empty metadata document name provided') + return '' + } + const exists = await fs.promises .access(metadataPath) .then(() => true) .catch(() => false)
197-199: Regex for semver extraction could be more robust.The current regex only captures basic semver patterns but doesn't validate that they're actually valid semantic versions.
Consider using a more robust semver validation:
function extractSemver(name: string): string { - return /(\d+\.\d+\.\d+)/.exec(name)?.[0] || '' + const match = /v?(\d+\.\d+\.\d+)/.exec(name)?.[1] + return match || '' }packages/app-data/src/api/appDataHexToCid.ts (1)
31-33: Consider improving error message specificity.The validation function throws a generic error message that could be more informative about what constitutes a valid CID.
export async function _assertCid(cid: string, appDataHex: string) { - if (!cid) throw new MetaDataError('Error getting CID from appDataHex: ' + appDataHex) + if (!cid || cid.length === 0) { + throw new MetaDataError(`Failed to generate valid CID from appDataHex: ${appDataHex}. CID is empty or null.`) + } }packages/app-data/src/api/getAppDataInfo.ts (1)
72-74: Document the risk of using JSON.stringify for legacy compatibility.The comment mentions the issue but doesn't clearly explain why this approach is maintained and what problems it could cause.
// For the legacy-mode we use plain JSON.stringify to maintain backwards compatibility, however this is not a good idea to do since JSON.stringify. Better specify the doc as a fullAppData string or use stringifyDeterministic + // WARNING: JSON.stringify does not guarantee deterministic output across different environments, + // which could lead to different hashes for the same logical content. This is maintained only for + // backwards compatibility with existing legacy implementations. const fullAppData = JSON.stringify(appDataAux)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (49)
packages/config/src/chains/images/arbitrum-logo-dark.svgis excluded by!**/*.svgpackages/config/src/chains/images/arbitrum-logo-light.svgis excluded by!**/*.svgpackages/config/src/chains/images/avax-logo.svgis excluded by!**/*.svgpackages/config/src/chains/images/base-logo.svgis excluded by!**/*.svgpackages/config/src/chains/images/gnosis-logo.svgis excluded by!**/*.svgpackages/config/src/chains/images/mainnet-logo.svgis excluded by!**/*.svgpackages/config/src/chains/images/optimism-logo.svgis excluded by!**/*.svgpackages/config/src/chains/images/polygon-logo.svgis excluded by!**/*.svgpackages/config/src/chains/images/sepolia-logo.svgis excluded by!**/*.svgpackages/cow-sdk/docs/images/CoW.pngis excluded by!**/*.pngpackages/cow-sdk/examples/cra/yarn.lockis excluded by!**/yarn.lock,!**/*.lockpackages/cow-sdk/examples/nodejs/yarn.lockis excluded by!**/yarn.lock,!**/*.lockpackages/cow-sdk/examples/vanilla/yarn.lockis excluded by!**/yarn.lock,!**/*.lockpackages/cow-sdk/src/bridging/providers/across/across-logo.pngis excluded by!**/*.pngpackages/cow-sdk/src/composable/generated/ComposableCoW.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/ExtensibleFallbackHandler.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/TWAP.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/common.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/factories/ComposableCoW__factory.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/factories/ExtensibleFallbackHandler__factory.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/factories/TWAP__factory.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/factories/index.tsis excluded by!**/generated/**packages/cow-sdk/src/composable/generated/index.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/index.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/Address.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/AppData.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/AppDataHash.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/AppDataObject.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/Auction.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/AuctionOrder.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/AuctionPrices.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/BigUint.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/BuyTokenDestination.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/CallData.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/CompetitionAuction.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/CompetitionOrderStatus.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/EcdsaSignature.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/EcdsaSigningScheme.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/EthflowData.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/ExecutedAmounts.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/ExecutedProtocolFee.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/FeePolicy.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/InteractionData.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/NativePriceResponse.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/OnchainOrderData.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/Order.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/OrderCancellation.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/OrderCancellationError.tsis excluded by!**/generated/**packages/cow-sdk/src/order-book/generated/models/OrderCancellations.tsis excluded by!**/generated/**
📒 Files selected for processing (107)
.devcontainer/devcontainer.json(1 hunks).gitignore(1 hunks).npmrc(1 hunks).nvmrc(1 hunks).prettierrc(1 hunks).vscode/settings.json(1 hunks)eslint.config.js(1 hunks)package.json(1 hunks)packages/app-data/babel.config.cjs(1 hunks)packages/app-data/jest.config.cjs(1 hunks)packages/app-data/package.json(1 hunks)packages/app-data/setupTests.cjs(1 hunks)packages/app-data/src/api/appDataHexToCid.spec.ts(1 hunks)packages/app-data/src/api/appDataHexToCid.ts(1 hunks)packages/app-data/src/api/cidToAppDataHex.test.ts(1 hunks)packages/app-data/src/api/cidToAppDataHex.ts(1 hunks)packages/app-data/src/api/fetchDocFromAppData.spec.ts(1 hunks)packages/app-data/src/api/fetchDocFromAppData.ts(1 hunks)packages/app-data/src/api/fetchDocFromCid.spec.ts(1 hunks)packages/app-data/src/api/fetchDocFromCid.ts(1 hunks)packages/app-data/src/api/generateAppDataDoc.spec.ts(1 hunks)packages/app-data/src/api/generateAppDataDoc.ts(1 hunks)packages/app-data/src/api/getAppDataInfo.spec.ts(1 hunks)packages/app-data/src/api/getAppDataInfo.ts(1 hunks)packages/app-data/src/api/getAppDataSchema.spec.ts(1 hunks)packages/app-data/src/api/getAppDataSchema.ts(1 hunks)packages/app-data/src/api/index.ts(1 hunks)packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.spec.ts(1 hunks)packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts(1 hunks)packages/app-data/src/api/validateAppDataDoc.spec.ts(1 hunks)packages/app-data/src/api/validateAppDataDoc.ts(1 hunks)packages/app-data/src/consts.ts(1 hunks)packages/app-data/src/exports.ts(1 hunks)packages/app-data/src/generatedTypes/index.ts(1 hunks)packages/app-data/src/generatedTypes/latest.ts(1 hunks)packages/app-data/src/generatedTypes/v0.1.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.10.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.11.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.2.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.3.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.4.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.5.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.6.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.7.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.8.0.ts(1 hunks)packages/app-data/src/generatedTypes/v0.9.0.ts(1 hunks)packages/app-data/src/generatedTypes/v1.0.0.ts(1 hunks)packages/app-data/src/generatedTypes/v1.1.0.ts(1 hunks)packages/app-data/src/generatedTypes/v1.2.0.ts(1 hunks)packages/app-data/src/generatedTypes/v1.3.0.ts(1 hunks)packages/app-data/src/generatedTypes/v1.4.0.ts(1 hunks)packages/app-data/src/importSchema.ts(1 hunks)packages/app-data/src/index.ts(1 hunks)packages/app-data/src/latest.ts(1 hunks)packages/app-data/src/mocks.ts(1 hunks)packages/app-data/src/schemas/definitions.json(1 hunks)packages/app-data/src/schemas/hook/v0.1.0.json(1 hunks)packages/app-data/src/schemas/hook/v0.2.0.json(1 hunks)packages/app-data/src/schemas/hooks/v0.1.0.json(1 hunks)packages/app-data/src/schemas/hooks/v0.2.0.json(1 hunks)packages/app-data/src/schemas/orderClass/v0.1.0.json(1 hunks)packages/app-data/src/schemas/orderClass/v0.2.0.json(1 hunks)packages/app-data/src/schemas/orderClass/v0.3.0.json(1 hunks)packages/app-data/src/schemas/partnerFee/v0.1.0.json(1 hunks)packages/app-data/src/schemas/partnerFee/v1.0.0.json(1 hunks)packages/app-data/src/schemas/quote/v0.1.0.json(1 hunks)packages/app-data/src/schemas/quote/v0.2.0.json(1 hunks)packages/app-data/src/schemas/quote/v0.3.0.json(1 hunks)packages/app-data/src/schemas/quote/v1.0.0.json(1 hunks)packages/app-data/src/schemas/quote/v1.1.0.json(1 hunks)packages/app-data/src/schemas/referrer/v0.1.0.json(1 hunks)packages/app-data/src/schemas/referrer/v0.2.0.json(1 hunks)packages/app-data/src/schemas/replacedOrder/v0.1.0.json(1 hunks)packages/app-data/src/schemas/signer/v0.1.0.json(1 hunks)packages/app-data/src/schemas/utm/v0.1.0.json(1 hunks)packages/app-data/src/schemas/utm/v0.2.0.json(1 hunks)packages/app-data/src/schemas/v0.1.0.json(1 hunks)packages/app-data/src/schemas/v0.10.0.json(1 hunks)packages/app-data/src/schemas/v0.11.0.json(1 hunks)packages/app-data/src/schemas/v0.2.0.json(1 hunks)packages/app-data/src/schemas/v0.3.0.json(1 hunks)packages/app-data/src/schemas/v0.4.0.json(1 hunks)packages/app-data/src/schemas/v0.5.0.json(1 hunks)packages/app-data/src/schemas/v0.6.0.json(1 hunks)packages/app-data/src/schemas/v0.7.0.json(1 hunks)packages/app-data/src/schemas/v0.8.0.json(1 hunks)packages/app-data/src/schemas/v0.9.0.json(1 hunks)packages/app-data/src/schemas/v1.0.0.json(1 hunks)packages/app-data/src/schemas/v1.1.0.json(1 hunks)packages/app-data/src/schemas/v1.2.0.json(1 hunks)packages/app-data/src/schemas/v1.3.0.json(1 hunks)packages/app-data/src/schemas/v1.4.0.json(1 hunks)packages/app-data/src/schemas/widget/v0.1.0.json(1 hunks)packages/app-data/src/scripts/compile.ts(1 hunks)packages/app-data/src/types.ts(1 hunks)packages/app-data/src/utils/ipfs.ts(1 hunks)packages/app-data/src/utils/stringify.ts(1 hunks)packages/app-data/test/schema.spec.ts(1 hunks)packages/app-data/tsconfig.json(1 hunks)packages/common/package.json(1 hunks)packages/common/src/adapters/AbstractProviderAdapter.ts(1 hunks)packages/common/src/adapters/context.ts(1 hunks)packages/common/src/adapters/index.ts(1 hunks)packages/common/src/adapters/types/AdapterUtils.ts(1 hunks)packages/common/src/adapters/types/index.ts(1 hunks)packages/common/src/index.ts(1 hunks)packages/common/tsconfig.json(1 hunks)
⛔ Files not processed due to max files limit (60)
- packages/config/README.md
- packages/config/package.json
- packages/config/src/chains/const/chainIds.ts
- packages/config/src/chains/const/contracts.ts
- packages/config/src/chains/const/index.ts
- packages/config/src/chains/const/utils.ts
- packages/config/src/chains/details/arbitrum.ts
- packages/config/src/chains/details/avalanche.ts
- packages/config/src/chains/details/base.ts
- packages/config/src/chains/details/gnosis.ts
- packages/config/src/chains/details/mainnet.ts
- packages/config/src/chains/details/optimism.ts
- packages/config/src/chains/details/polygon.ts
- packages/config/src/chains/details/sepolia.ts
- packages/config/src/chains/index.ts
- packages/config/src/chains/types.ts
- packages/config/src/constants/index.ts
- packages/config/src/constants/paths.ts
- packages/config/src/constants/tokens.ts
- packages/config/src/index.ts
- packages/config/src/types/configs.ts
- packages/config/src/types/index.ts
- packages/config/src/types/tokens.ts
- packages/config/tsconfig.json
- packages/cow-sdk/README.md
- packages/cow-sdk/examples/cra/src/hooks/useWeb3Info.ts
- packages/cow-sdk/examples/cra/src/index.tsx
- packages/cow-sdk/examples/cra/src/pages/cowShedHook/index.tsx
- packages/cow-sdk/examples/cra/src/pages/getOrders/index.tsx
- packages/cow-sdk/examples/cra/src/pages/getQuote/index.tsx
- packages/cow-sdk/examples/cra/src/pages/getTrades/index.tsx
- packages/cow-sdk/examples/cra/src/pages/quickStart/index.tsx
- packages/cow-sdk/examples/cra/src/pages/sendOrder/index.tsx
- packages/cow-sdk/examples/cra/src/pages/sendOrderCancellation/index.tsx
- packages/cow-sdk/examples/cra/src/pages/signOrder/index.tsx
- packages/cow-sdk/examples/cra/src/pages/signOrderCancellation/index.tsx
- packages/cow-sdk/examples/cra/src/pages/smartContractWallet/index.tsx
- packages/cow-sdk/examples/cra/src/pages/smartContractWallet/useSafeSdkAndKit.ts
- packages/cow-sdk/examples/vanilla/src/index.ts
- packages/cow-sdk/examples/vanilla/src/tokens.ts
- packages/cow-sdk/package.json
- packages/cow-sdk/scripts/generateTradingSchemas.ts
- packages/cow-sdk/src/bridging/BridgingSdk/BridgingSdk.ts
- packages/cow-sdk/src/bridging/BridgingSdk/getCrossChainOrder.ts
- packages/cow-sdk/src/bridging/providers/across/AcrossApi.test.ts
- packages/cow-sdk/src/bridging/providers/across/AcrossApi.ts
- packages/cow-sdk/src/bridging/providers/across/AcrossBridgeProvider.test.ts
- packages/cow-sdk/src/bridging/providers/across/AcrossBridgeProvider.ts
- packages/cow-sdk/src/bridging/providers/across/const/tokens.ts
- packages/cow-sdk/src/bridging/providers/across/createAcrossDepositCall.ts
- packages/cow-sdk/src/bridging/providers/across/util.ts
- packages/cow-sdk/src/bridging/types.ts
- packages/cow-sdk/src/common/utils/config.ts
- packages/cow-sdk/src/composable/Multiplexer.spec.ts
- packages/cow-sdk/src/composable/orderTypes/Twap.spec.ts
- packages/cow-sdk/src/composable/orderTypes/test/TestConditionalOrder.ts
- packages/cow-sdk/src/cow-shed/README.md
- packages/cow-sdk/src/cow-shed/contracts/CoWShedHooks.spec.ts
- packages/cow-sdk/src/cow-shed/contracts/CoWShedHooks.ts
- packages/cow-sdk/src/order-book/api.ts
🧰 Additional context used
🧬 Code Graph Analysis (32)
packages/app-data/src/api/cidToAppDataHex.ts (1)
packages/app-data/src/utils/ipfs.ts (1)
extractDigest(31-36)
packages/app-data/src/api/generateAppDataDoc.ts (2)
packages/app-data/src/generatedTypes/index.ts (2)
LATEST_APP_DATA_VERSION(22-22)LatestAppDataDocVersion(33-33)packages/app-data/src/types.ts (1)
AppDataParams(3-3)
packages/app-data/src/api/cidToAppDataHex.test.ts (2)
packages/app-data/src/api/cidToAppDataHex.ts (1)
cidToAppDataHex(9-11)packages/app-data/src/mocks.ts (4)
CID(11-11)APP_DATA_HEX(12-12)CID_2(33-33)APP_DATA_HEX_2(34-34)
packages/app-data/src/api/generateAppDataDoc.spec.ts (2)
packages/app-data/src/api/generateAppDataDoc.ts (1)
generateAppDataDoc(32-38)packages/app-data/src/mocks.ts (1)
APP_DATA_DOC_CUSTOM(14-27)
packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.spec.ts (4)
packages/app-data/src/mocks.ts (3)
PINATA_API_KEY(41-41)PINATA_API_SECRET(42-42)APP_DATA_DOC_CUSTOM(14-27)packages/app-data/src/api/generateAppDataDoc.ts (1)
generateAppDataDoc(32-38)packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts (1)
uploadMetadataDocToIpfsLegacy(23-33)packages/app-data/src/consts.ts (1)
DEFAULT_IPFS_WRITE_URI(2-2)
packages/app-data/src/api/fetchDocFromAppData.spec.ts (4)
packages/app-data/src/mocks.ts (3)
CID_LEGACY(38-38)APP_DATA_DOC_CUSTOM(14-27)APP_DATA_HEX_LEGACY(39-39)packages/app-data/src/api/fetchDocFromAppData.ts (2)
fetchDocFromAppDataHexLegacy(32-37)fetchDocFromAppDataHex(16-21)packages/app-data/src/api/appDataHexToCid.ts (1)
appDataHexToCidLegacy(24-29)packages/app-data/src/api/fetchDocFromCid.ts (1)
fetchDocFromCid(11-16)
packages/app-data/src/api/fetchDocFromCid.spec.ts (2)
packages/app-data/src/api/fetchDocFromCid.ts (1)
fetchDocFromCid(11-16)packages/app-data/src/consts.ts (1)
DEFAULT_IPFS_READ_URI(1-1)
packages/app-data/src/api/getAppDataSchema.spec.ts (1)
packages/app-data/src/api/getAppDataSchema.ts (1)
getAppDataSchema(11-20)
packages/app-data/src/importSchema.ts (1)
packages/app-data/src/generatedTypes/index.ts (1)
AnyAppDataDocVersion(34-50)
packages/app-data/src/api/getAppDataInfo.spec.ts (5)
packages/app-data/src/mocks.ts (9)
APP_DATA_HEX(12-12)CID(11-11)APP_DATA_STRING(10-10)CID_LEGACY(38-38)CID_2(33-33)APP_DATA_HEX_2(34-34)APP_DATA_HEX_LEGACY(39-39)APP_DATA_DOC(4-8)APP_DATA_STRING_2(31-32)packages/app-data/src/utils/ipfs.ts (1)
extractDigest(31-36)packages/app-data/src/api/appDataHexToCid.ts (1)
appDataHexToCid(10-14)packages/app-data/src/utils/stringify.ts (1)
stringifyDeterministic(1-4)packages/app-data/src/api/getAppDataInfo.ts (2)
getAppDataInfo(35-37)getAppDataInfoLegacy(69-75)
packages/common/src/adapters/types/AdapterUtils.ts (1)
packages/common/src/adapters/types/index.ts (1)
Bytes(3-3)
packages/app-data/src/api/validateAppDataDoc.spec.ts (2)
packages/app-data/src/mocks.ts (1)
APP_DATA_DOC(4-8)packages/app-data/src/api/validateAppDataDoc.ts (1)
validateAppDataDoc(43-63)
packages/app-data/src/api/appDataHexToCid.spec.ts (3)
packages/app-data/src/mocks.ts (4)
CID(11-11)CID_LEGACY(38-38)APP_DATA_HEX(12-12)APP_DATA_HEX_LEGACY(39-39)packages/app-data/src/api/appDataHexToCid.ts (2)
appDataHexToCid(10-14)appDataHexToCidLegacy(24-29)packages/common/src/adapters/context.ts (1)
getGlobalAdapter(32-34)
packages/app-data/src/api/validateAppDataDoc.ts (3)
packages/app-data/src/importSchema.ts (1)
importSchema(8-29)packages/app-data/src/generatedTypes/index.ts (1)
AnyAppDataDocVersion(34-50)packages/app-data/src/types.ts (1)
ValidationResult(47-50)
packages/app-data/src/utils/ipfs.ts (1)
packages/app-data/src/mocks.ts (1)
CID(11-11)
packages/app-data/src/api/index.ts (10)
packages/common/src/adapters/context.ts (1)
setGlobalAdapter(37-40)packages/app-data/src/api/getAppDataSchema.ts (1)
getAppDataSchema(11-20)packages/app-data/src/api/generateAppDataDoc.ts (1)
generateAppDataDoc(32-38)packages/app-data/src/api/validateAppDataDoc.ts (1)
validateAppDataDoc(43-63)packages/app-data/src/api/getAppDataInfo.ts (2)
getAppDataInfo(35-37)getAppDataInfoLegacy(69-75)packages/app-data/src/api/appDataHexToCid.ts (2)
appDataHexToCid(10-14)appDataHexToCidLegacy(24-29)packages/app-data/src/api/cidToAppDataHex.ts (1)
cidToAppDataHex(9-11)packages/app-data/src/api/fetchDocFromAppData.ts (2)
fetchDocFromAppDataHex(16-21)fetchDocFromAppDataHexLegacy(32-37)packages/app-data/src/api/fetchDocFromCid.ts (1)
fetchDocFromCid(11-16)packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts (1)
uploadMetadataDocToIpfsLegacy(23-33)
packages/app-data/src/types.ts (2)
packages/app-data/src/generatedTypes/v0.2.0.ts (1)
AppDataRootSchema(32-37)packages/app-data/src/generatedTypes/v1.4.0.ts (1)
AppDataRootSchema(154-159)
packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts (5)
packages/app-data/src/generatedTypes/index.ts (1)
AnyAppDataDocVersion(34-50)packages/app-data/src/types.ts (1)
Ipfs(39-45)packages/app-data/src/utils/ipfs.ts (1)
extractDigest(31-36)packages/app-data/src/consts.ts (2)
DEFAULT_IPFS_WRITE_URI(2-2)MetaDataError(4-4)packages/app-data/src/utils/stringify.ts (1)
stringifyDeterministic(1-4)
packages/app-data/src/generatedTypes/v0.2.0.ts (2)
packages/app-data/src/generatedTypes/v0.3.0.ts (12)
Version(11-11)AppCode(15-15)Version1(23-23)ReferrerAddress(24-24)QuoteId(25-25)QuoteSellAmount(26-26)QuoteBuyAmount(27-27)Version2(31-31)AppDataRootSchema(36-42)Metadata(46-50)Referrer(51-55)Quote(56-62)packages/app-data/src/generatedTypes/v0.1.0.ts (7)
Version(11-11)AppCode(15-15)Version1(19-19)ReferrerAddress(20-20)AppDataRootSchema(25-30)Metadata(34-37)Referrer(38-42)
packages/app-data/src/api/fetchDocFromAppData.ts (4)
packages/app-data/src/generatedTypes/index.ts (1)
AnyAppDataDocVersion(34-50)packages/app-data/src/api/appDataHexToCid.ts (2)
appDataHexToCid(10-14)appDataHexToCidLegacy(24-29)packages/app-data/src/consts.ts (1)
MetaDataError(4-4)packages/app-data/src/api/fetchDocFromCid.ts (1)
fetchDocFromCid(11-16)
packages/app-data/src/generatedTypes/v0.5.0.ts (4)
packages/app-data/src/generatedTypes/v0.1.0.ts (7)
Version(11-11)AppCode(15-15)Version1(19-19)ReferrerAddress(20-20)AppDataRootSchema(25-30)Metadata(34-37)Referrer(38-42)packages/app-data/src/generatedTypes/v0.4.0.ts (11)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(28-28)SlippageBips(32-32)AppDataRootSchema(37-43)Metadata(47-51)Referrer(52-56)Quote(57-61)packages/app-data/src/generatedTypes/v0.6.0.ts (14)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(48-48)SlippageBips(52-52)Version3(56-56)OrderClass1(60-60)AppDataRootSchema(65-71)Metadata(75-81)Referrer(82-86)Quote(95-99)OrderClass(100-104)packages/app-data/src/generatedTypes/v0.7.0.ts (14)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(48-48)SlippageBips(52-52)Version3(56-56)OrderClass1(60-60)AppDataRootSchema(65-71)Metadata(75-81)Referrer(82-86)Quote(95-99)OrderClass(100-104)
packages/app-data/src/api/appDataHexToCid.ts (2)
packages/app-data/src/consts.ts (1)
MetaDataError(4-4)packages/common/src/adapters/context.ts (1)
getGlobalAdapter(32-34)
packages/app-data/src/generatedTypes/v0.3.0.ts (3)
packages/app-data/src/generatedTypes/v0.2.0.ts (12)
Version(11-11)AppCode(15-15)Version1(19-19)ReferrerAddress(20-20)QuoteId(21-21)QuoteSellAmount(22-22)QuoteBuyAmount(23-23)Version2(27-27)AppDataRootSchema(32-37)Metadata(41-45)Referrer(46-50)Quote(51-57)packages/app-data/src/generatedTypes/v0.4.0.ts (10)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(28-28)AppDataRootSchema(37-43)Metadata(47-51)Referrer(52-56)Quote(57-61)packages/app-data/src/generatedTypes/v0.8.0.ts (8)
Version(11-11)AppCode(15-15)Environment(19-19)ReferrerAddress(20-20)AppDataRootSchema(53-58)Metadata(62-67)Referrer(68-70)Quote(78-80)
packages/app-data/src/api/getAppDataSchema.ts (3)
packages/app-data/src/generatedTypes/index.ts (1)
AnyAppDataDocVersion(34-50)packages/app-data/src/importSchema.ts (1)
importSchema(8-29)packages/app-data/src/consts.ts (1)
MetaDataError(4-4)
packages/app-data/src/generatedTypes/v1.4.0.ts (1)
packages/app-data/src/generatedTypes/v1.3.0.ts (35)
Version(11-11)AppCode(15-15)Environment(19-19)Signer(23-23)ReferrerAddress(24-24)UTMSource(28-28)UTMMedium(32-32)UTMCampaign(36-36)UTMContent(40-40)UTMKeywordTerm(44-44)SlippageBips(48-48)SmartSlippage(52-52)OrderClass1(56-56)Version1(60-60)HookTarget(64-64)HookCallData(68-68)HookGasLimit(72-72)IdOfTheDAppWhichHasBuiltTheHook(76-76)PreHooks(80-80)CoWHook(154-159)PostHooks(84-84)AppCode1(88-88)Environment1(92-92)PartnerFee(164-167)PartnerAccount(100-100)ReplacedOrderUID(104-104)AppDataRootSchema(109-114)Metadata(118-128)Referrer(129-131)UTMCodes(132-138)Quote(139-142)OrderClass(143-145)OrderInteractionHooks(149-153)Widget(160-163)ReplacedOrder(168-170)
packages/app-data/src/generatedTypes/v0.4.0.ts (3)
packages/app-data/src/generatedTypes/v0.3.0.ts (10)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(31-31)AppDataRootSchema(36-42)Metadata(46-50)Referrer(51-55)Quote(56-62)packages/app-data/src/generatedTypes/v0.7.0.ts (11)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(48-48)SlippageBips(52-52)AppDataRootSchema(65-71)Metadata(75-81)Referrer(82-86)Quote(95-99)packages/app-data/src/generatedTypes/v0.5.0.ts (11)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)Version2(28-28)SlippageBips(32-32)AppDataRootSchema(45-51)Metadata(55-60)Referrer(61-65)Quote(66-70)
packages/app-data/src/generatedTypes/index.ts (16)
packages/app-data/src/generatedTypes/v0.2.0.ts (1)
AppDataRootSchema(32-37)packages/app-data/src/generatedTypes/v0.3.0.ts (1)
AppDataRootSchema(36-42)packages/app-data/src/generatedTypes/v0.11.0.ts (1)
AppDataRootSchema(89-94)packages/app-data/src/generatedTypes/v0.10.0.ts (1)
AppDataRootSchema(81-86)packages/app-data/src/generatedTypes/v0.1.0.ts (1)
AppDataRootSchema(25-30)packages/app-data/src/generatedTypes/v0.4.0.ts (1)
AppDataRootSchema(37-43)packages/app-data/src/generatedTypes/v0.6.0.ts (1)
AppDataRootSchema(65-71)packages/app-data/src/generatedTypes/v0.8.0.ts (1)
AppDataRootSchema(53-58)packages/app-data/src/generatedTypes/v0.7.0.ts (1)
AppDataRootSchema(65-71)packages/app-data/src/generatedTypes/v0.9.0.ts (1)
AppDataRootSchema(77-82)packages/app-data/src/generatedTypes/v1.0.0.ts (1)
AppDataRootSchema(97-102)packages/app-data/src/generatedTypes/v1.2.0.ts (1)
AppDataRootSchema(105-110)packages/app-data/src/generatedTypes/v0.5.0.ts (1)
AppDataRootSchema(45-51)packages/app-data/src/generatedTypes/v1.1.0.ts (1)
AppDataRootSchema(101-106)packages/app-data/src/generatedTypes/v1.3.0.ts (1)
AppDataRootSchema(109-114)packages/app-data/src/generatedTypes/v1.4.0.ts (1)
AppDataRootSchema(154-159)
packages/app-data/src/generatedTypes/v0.6.0.ts (1)
packages/app-data/src/generatedTypes/v0.7.0.ts (20)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)UTMSource(28-28)UTMMedium(32-32)UTMCampaign(36-36)UTMContent(40-40)UTMKeywordTerm(44-44)Version2(48-48)SlippageBips(52-52)Version3(56-56)OrderClass1(60-60)AppDataRootSchema(65-71)Metadata(75-81)Referrer(82-86)UTMCodes(87-94)Quote(95-99)OrderClass(100-104)
packages/app-data/src/generatedTypes/v0.7.0.ts (1)
packages/app-data/src/generatedTypes/v0.6.0.ts (20)
Version(11-11)AppCode(15-15)Environment(19-19)Version1(23-23)ReferrerAddress(24-24)UTMSource(28-28)UTMMedium(32-32)UTMCampaign(36-36)UTMContent(40-40)UTMKeywordTerm(44-44)Version2(48-48)SlippageBips(52-52)Version3(56-56)OrderClass1(60-60)AppDataRootSchema(65-71)Metadata(75-81)Referrer(82-86)UTMCodes(87-94)Quote(95-99)OrderClass(100-104)
packages/app-data/src/generatedTypes/v0.9.0.ts (2)
packages/app-data/src/generatedTypes/v0.10.0.ts (25)
Version(11-11)AppCode(15-15)Environment(19-19)ReferrerAddress(24-24)UTMSource(28-28)UTMMedium(32-32)UTMCampaign(36-36)UTMContent(40-40)UTMKeywordTerm(44-44)SlippageBips(48-48)OrderClass1(52-52)Version1(56-56)HookTarget(60-60)HookCallData(64-64)HookGasLimit(68-68)PreHooks(72-72)CoWHook(122-126)PostHooks(76-76)AppDataRootSchema(81-86)Metadata(90-97)Referrer(98-100)UTMCodes(101-107)Quote(108-110)OrderClass(111-113)OrderInteractionHooks(117-121)packages/app-data/src/generatedTypes/v0.8.0.ts (17)
Version(11-11)AppCode(15-15)Environment(19-19)ReferrerAddress(20-20)UTMSource(24-24)UTMMedium(28-28)UTMCampaign(32-32)UTMContent(36-36)UTMKeywordTerm(40-40)SlippageBips(44-44)OrderClass1(48-48)AppDataRootSchema(53-58)Metadata(62-67)Referrer(68-70)UTMCodes(71-77)Quote(78-80)OrderClass(81-83)
packages/app-data/src/generatedTypes/v1.0.0.ts (1)
packages/app-data/src/generatedTypes/v1.1.0.ts (32)
Version(11-11)AppCode(15-15)Environment(19-19)Signer(23-23)ReferrerAddress(24-24)UTMSource(28-28)UTMMedium(32-32)UTMCampaign(36-36)UTMContent(40-40)UTMKeywordTerm(44-44)SlippageBips(48-48)OrderClass1(52-52)Version1(56-56)HookTarget(60-60)HookCallData(64-64)HookGasLimit(68-68)PreHooks(72-72)CoWHook(145-149)PostHooks(76-76)AppCode1(80-80)Environment1(84-84)BasisPointBPS(88-88)PartnerAccount(92-92)AppDataRootSchema(101-106)Metadata(110-120)Referrer(121-123)UTMCodes(124-130)Quote(131-133)OrderClass(134-136)OrderInteractionHooks(140-144)Widget(150-153)PartnerFee(154-157)
packages/app-data/src/generatedTypes/v0.11.0.ts (1)
packages/app-data/src/generatedTypes/v1.0.0.ts (29)
Version(11-11)AppCode(15-15)Environment(19-19)Signer(23-23)ReferrerAddress(24-24)UTMSource(28-28)UTMMedium(32-32)UTMCampaign(36-36)UTMContent(40-40)UTMKeywordTerm(44-44)SlippageBips(48-48)OrderClass1(52-52)Version1(56-56)HookTarget(60-60)HookCallData(64-64)HookGasLimit(68-68)PreHooks(72-72)CoWHook(140-144)PostHooks(76-76)AppCode1(80-80)Environment1(84-84)AppDataRootSchema(97-102)Metadata(106-115)Referrer(116-118)UTMCodes(119-125)Quote(126-128)OrderClass(129-131)OrderInteractionHooks(135-139)Widget(145-148)
🪛 ESLint
packages/app-data/babel.config.cjs
[error] 1-1: 'module' is not defined.
(no-undef)
packages/app-data/setupTests.cjs
[error] 1-1: 'global' is not defined.
(no-undef)
[error] 1-1: A require() style import is forbidden.
(@typescript-eslint/no-require-imports)
[error] 1-1: 'require' is not defined.
(no-undef)
[error] 3-3: 'global' is not defined.
(no-undef)
[error] 3-3: 'global' is not defined.
(no-undef)
[error] 5-5: 'fetchMock' is not defined.
(no-undef)
[error] 7-7: 'jest' is not defined.
(no-undef)
[error] 7-7: 'fetchMock' is not defined.
(no-undef)
packages/app-data/jest.config.cjs
[error] 1-1: 'module' is not defined.
(no-undef)
🪛 Biome (1.9.4)
packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts
[error] 26-26: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
packages/app-data/src/api/fetchDocFromAppData.ts
[error] 19-19: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 35-35: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 43-43: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
🔇 Additional comments (151)
.nvmrc (1)
1-1: Bump Node.js version to v20.x
Aligns the development environment with the updated monorepo requirements (Node.js >=18)..devcontainer/devcontainer.json (2)
2-4: Reformat devcontainer identification fields
Indentation and spacing adjustments onnameandimagemaintain consistency without altering functionality.
5-17: Reformat features block
Spacing changes in thefeaturesmapping improve readability and align with project style guidelines..gitignore (1)
1-28: Expand ignore patterns for the monorepo layout
The new rules for Turborepo, PnP, macOS files, and generated directories correctly prevent unwanted artifacts from being committed..prettierrc (1)
4-5: Enforce consistent print width and LF line endings
AddingprintWidth: 120andendOfLine: "lf"ensures uniform formatting across contributors.packages/app-data/src/latest.ts (1)
1-3: Establish a consolidated export entry point
Re-exporting from./exportsand./generatedTypes/latestprovides a clear single import path for the app-data package.packages/app-data/src/generatedTypes/latest.ts (1)
1-3: LGTM! Well-structured generated type export.This follows the standard pattern for versioned API management, providing a stable "latest" reference while maintaining the underlying version structure. The generated code comment appropriately warns against manual editing.
packages/app-data/babel.config.cjs (1)
1-4: LGTM! Standard Babel configuration for TypeScript Node.js project.The configuration appropriately targets the current Node.js version and includes TypeScript support. The ESLint error about 'module' not being defined is a false positive since this is a CommonJS file (.cjs extension) where
moduleis a Node.js global.🧰 Tools
🪛 ESLint
[error] 1-1: 'module' is not defined.
(no-undef)
packages/common/tsconfig.json (1)
1-9: LGTM! Well-configured TypeScript setup for monorepo package.The configuration properly extends the base monorepo config and sets up standard build and module resolution settings. The include/exclude patterns are appropriate for the package structure.
packages/app-data/src/index.ts (1)
1-2: Clean modular re-export
This file correctly consolidates exports into a single entry point, improving import ergonomics.packages/common/src/adapters/index.ts (1)
1-3: Convenient adapter re-exports
Re-exporting the adapter modules in one place is a good pattern for discoverability and tree-shaking..vscode/settings.json (1)
1-16: Consistent VS Code formatting settings
The workspace settings enforce Prettier and ESLint fixes on save, aligning IDE behavior with project standards.packages/common/src/index.ts (1)
6-6: Unified package entry point
Re-exporting./adaptershere provides a clear public API surface for the@cowprotocol/sdk-commonpackage.packages/app-data/src/schemas/referrer/v0.2.0.json (1)
1-16: Schema structure looks well-defined.The referrer schema is properly structured with required address field, appropriate references to shared definitions, and follows JSON Schema Draft-07 standards.
.npmrc (1)
1-3: LGTM! Appropriate monorepo configuration.These
.npmrcsettings are well-suited for the monorepo structure:
shamefully-hoist=falseprevents dependency conflicts between packagesstrict-peer-dependencies=falseavoids common monorepo peer dependency issuesnode-linker=isolatedprovides better package isolationpackages/app-data/src/exports.ts (1)
1-3: Clean barrel export pattern.The centralized export structure is well-organized, providing easy access to the package's main APIs and explicitly exposing the commonly-used
stringifyDeterministicutility.packages/app-data/src/schemas/replacedOrder/v0.1.0.json (1)
1-15: Well-structured schema definition.The replacedOrder schema is properly implemented with:
- Consistent versioning between filename and
$id- Appropriate reference to shared
orderUiddefinition- Proper validation constraints with
additionalProperties: falsepackages/app-data/src/schemas/signer/v0.1.0.json (1)
1-7: Well-structured JSON schema.The schema correctly follows JSON Schema draft-07 conventions and appropriately references the shared ethereum address definition. The description provides valuable context about when this field should be used, particularly for smart contract wallets using EIP-1271 signatures.
packages/app-data/src/api/cidToAppDataHex.test.ts (1)
13-39: Excellent test coverage.The test suite provides comprehensive coverage with two happy path scenarios using different CID/hex pairs and proper error handling for malformed CIDs. The test structure is clean and follows good testing practices.
packages/app-data/src/consts.ts (1)
1-4: Clean and well-structured constants.The IPFS URI constants use appropriate default gateways, and the custom
MetaDataErrorclass follows standard error handling patterns. This provides a solid foundation for IPFS operations and metadata error handling throughout the package.packages/common/src/adapters/types/AdapterUtils.ts (1)
1-22: LGTM! Well-designed adapter abstraction.The abstract class is well-structured with clear method signatures, good documentation, and appropriate type safety. The interface provides essential utility functions for crypto operations while maintaining flexibility for different implementations.
packages/app-data/src/schemas/orderClass/v0.3.0.json (1)
22-27: Order class enum values are well-defined.The enum constraint properly defines the four supported order classes with clear, descriptive values that align with trading terminology.
packages/app-data/src/schemas/referrer/v0.1.0.json (2)
11-15: Good use of versioning pattern.The read-only version property with a default value follows best practices for schema versioning and ensures consistency across documents.
16-19: Proper use of external schema references.Referencing the shared
ethereumAddressdefinition fromdefinitions.jsonpromotes consistency and maintainability across schemas.packages/app-data/src/schemas/hooks/v0.1.0.json (2)
11-15: Consistent versioning pattern.The version property implementation is consistent with other schemas in the package, using read-only with default value.
16-33: Well-structured hook arrays with proper references.The pre and post hook arrays properly reference the external hook schema, enabling modular hook definitions while maintaining clear semantics for execution order.
packages/app-data/src/schemas/partnerFee/v0.1.0.json (1)
1-20:Details
✅ Verification successful
Well-structured JSON schema with appropriate validation.
The schema correctly defines the partner fee structure with proper validation rules. The use of external references (
../definitions.json#/definitions/bpsand../definitions.json#/definitions/ethereumAddress) promotes consistency across schemas, andadditionalProperties: falseensures strict validation.Verify that the referenced definitions exist in the definitions.json file:
🏁 Script executed:
#!/bin/bash # Check if the referenced definitions exist if [ -f "packages/app-data/src/schemas/definitions.json" ]; then echo "Checking for 'bps' definition:" jq '.definitions.bps' packages/app-data/src/schemas/definitions.json echo "Checking for 'ethereumAddress' definition:" jq '.definitions.ethereumAddress' packages/app-data/src/schemas/definitions.json else echo "definitions.json file not found" fiLength of output: 847
All external references validated successfully. Ready to merge.
- Verified that
bpsandethereumAddressdefinitions exist inpackages/app-data/src/schemas/definitions.json.- References (
../definitions.json#/definitions/bpsand../definitions.json#/definitions/ethereumAddress) resolve correctly.packages/app-data/src/schemas/quote/v0.1.0.json (1)
1-34: Excellent schema design with proper version handling.The schema is well-structured with appropriate use of
readOnly: trueanddefault: "0.1.0"for the version field, which ensures version consistency. The external references to shared definitions maintain consistency across the schema ecosystem.The schema correctly handles:
- Required fields for essential quote data
- Optional ID field for flexibility
- Immutable version field with default value
- Consistent type references for big numbers
packages/app-data/src/schemas/orderClass/v0.1.0.json (1)
1-33: Well-structured JSON schema with appropriate constraints.The schema follows JSON Schema Draft 7 best practices with proper validation constraints, external references for shared definitions, and meaningful enum values for order classification.
packages/app-data/src/schemas/widget/v0.1.0.json (1)
1-24: Excellent schema design with strict validation.The use of
"additionalProperties": falseensures strict validation, while the requiredappCodeand optionalenvironmentprovide appropriate flexibility for widget configuration.packages/common/src/adapters/AbstractProviderAdapter.ts (1)
1-14: Clean abstraction following solid design principles.The abstract class provides a clear interface for provider implementations with appropriate async methods for blockchain operations and well-documented purpose.
packages/app-data/src/schemas/hooks/v0.2.0.json (1)
22-22:Details
✅ Verification successful
Verify external schema reference consistency.
Both pre and post hooks reference
../hook/v0.2.0.json#. Ensure this referenced schema file exists and is compatible with this hooks schema version.Also applies to: 31-31
🏁 Script executed:
#!/bin/bash # Check if the referenced hook schema exists fd -t f "v0.2.0.json" packages/app-data/src/schemas/hook/Length of output: 104
🏁 Script executed:
#!/bin/bash # Show the first 20 lines of the hook schema to verify version and $id sed -n '1,20p' packages/app-data/src/schemas/hook/v0.2.0.jsonLength of output: 572
Referenced hook schema is consistent.
- Located packages/app-data/src/schemas/hook/v0.2.0.json and confirmed it exists.
- Its
$id(#hook/v0.2.0.json) and version (draft-07) match the hooks schema.- The
"$ref": "../hook/v0.2.0.json#"in both pre and post hooks correctly points to the root of the v0.2.0 hook schema.No changes required.
packages/app-data/tsconfig.json (1)
1-14: Configuration structure looks good.The TypeScript configuration follows best practices with proper extension of base config, appropriate compiler options, and clear include/exclude patterns.
packages/common/src/adapters/context.ts (2)
4-29: Well-implemented singleton pattern.The singleton implementation is correct and follows best practices with proper private constructor, static instance management, and clear error handling.
23-25: Clear and helpful error message.The error message provides good guidance on how to configure the adapter, mentioning both CowSdk and direct AdapterContext usage.
packages/app-data/src/schemas/orderClass/v0.2.0.json (1)
27-32: Well-defined enum values for order class.The enum values (market, limit, liquidity, twap) are clear and comprehensive for different order types. The examples property provides good documentation.
packages/app-data/src/schemas/quote/v0.2.0.json (1)
1-22: LGTM! Well-structured JSON schema with proper validation.The schema correctly defines a Quote object with appropriate validation patterns and external references for reusability.
packages/app-data/src/schemas/quote/v1.1.0.json (1)
9-22: Good schema design with proper constraints.The use of
additionalProperties: falseand external BPS reference promotes consistency and prevents unexpected properties.packages/app-data/src/api/validateAppDataDoc.ts (1)
43-63: Excellent error handling and validation logic.The function properly extracts the version, handles both validation success/failure cases, and provides meaningful error messages. The error handling correctly differentiates between Error instances and other exceptions.
packages/app-data/src/api/generateAppDataDoc.spec.ts (2)
5-11: Good test setup with proper isolation.The beforeEach/afterEach hooks ensure proper test isolation by resetting mocks and restoring all mocks between tests.
27-48: Good test coverage for custom metadata scenario.The test properly verifies that custom parameters are correctly merged into the generated document structure.
packages/app-data/src/schemas/hook/v0.1.0.json (1)
1-35: Well-structured JSON schema with proper validation rules.The hook schema correctly defines the essential properties for a blockchain hook with appropriate validation:
targetreferences an Ethereum address definitioncallDatauses a proper hex string pattern^0x[a-fA-F0-9]*$gasLimitreferences a big number definitionadditionalProperties: falseensures strict validationThe schema follows JSON Schema draft-07 standards and integrates well with external definitions.
packages/app-data/src/api/appDataHexToCid.spec.ts (1)
21-32:Details
✅ Verification successful
Verify mock adapter interface matches actual implementation.
The mock adapter structure uses
utilsproperty directly, but from the relevant code snippets, the actual implementation might expect different method organization. Ensure the mock structure accurately reflects the real adapter interface.Run the following script to verify the adapter interface structure:
🏁 Script executed:
#!/bin/bash # Description: Check the actual adapter interface structure used in the implementation # Search for adapter usage patterns in the actual implementation ast-grep --pattern $'getGlobalAdapter().$_' # Search for adapter method usage rg -A 3 "getGlobalAdapter\(\)" packages/app-data/src/api/Length of output: 980
Mock adapter interface matches the real implementation
Verified thatgetGlobalAdapter().utils.arrayify,keccak256, andtoUtf8Bytesare used exactly as defined in the mock:
- packages/app-data/src/api/appDataHexToCid.ts (line 79):
getGlobalAdapter().utils.arrayify(...)- packages/app-data/src/api/getAppDataInfo.ts:
•adapter.utils.keccak256(...)
•adapter.utils.toUtf8Bytes(...)No changes required.
packages/app-data/src/schemas/v0.4.0.json (1)
1-55: Well-designed schema with proper structure and validation.The schema effectively defines the app data metadata structure with:
- Appropriate required fields (
version,metadata)- Proper external references for reusable components
- Clear descriptions and examples for each property
- Semantic versioning in the schema ID
- Flexible metadata object allowing for extensibility
The schema follows JSON Schema draft-07 standards and integrates well with the broader schema ecosystem.
packages/app-data/src/api/validateAppDataDoc.spec.ts (1)
17-50: Test coverage looks comprehensive.The test cases appropriately cover:
- Version matching scenarios
- Schema validation failures
- Non-existent version handling
- Valid and invalid document structures
The error message assertions align well with the expected behavior of the validation function.
packages/app-data/src/schemas/v0.5.0.json (1)
1-58: Well-structured JSON schema definition.The schema follows JSON Schema Draft 07 standards correctly with:
- Proper
$idand$schemadeclarations- Clear required fields specification
- Appropriate use of external references for modular schema design
- Descriptive titles, descriptions, and examples
- Sensible default values
The modular approach with external references (
referrer/v0.1.0.json,quote/v0.2.0.json,orderClass/v0.1.0.json) promotes maintainability and reusability.packages/app-data/src/api/fetchDocFromAppData.spec.ts (3)
8-26: Effective mocking strategy for external dependencies.The mocking setup correctly isolates the module under test by mocking:
- Global adapter from
@cowprotocol/sdk-common- CID conversion functions
- Document fetching functionality
The mock implementations provide realistic behavior patterns that enable meaningful testing.
47-54: Good test isolation practices.The
beforeEachandafterEachhooks properly reset and restore mocks, ensuring test independence and preventing test pollution.
56-74: Comprehensive test coverage for success and error scenarios.The tests cover:
- Legacy app data decoding with proper function call verification
- Error handling for invalid hash formats with appropriate error message pattern matching
The assertions verify both the function calls and the expected outcomes effectively.
packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.spec.ts (3)
6-14: Good use of constants for test data.The use of constants for HTTP status codes, test hashes, and API credentials improves readability and maintainability.
15-21: Proper test isolation setup.The
beforeEachandafterEachhooks ensure clean test state by resetting fetch mocks and restoring all mocks.
23-82: Comprehensive test coverage for IPFS upload scenarios.The test suite effectively covers:
- Missing credentials: Verifies proper error thrown when credentials are not provided
- Invalid credentials: Tests API error response handling with mocked server error
- Successful upload: Validates complete upload flow including:
- Correct API endpoint usage
- Proper request headers and body formatting
- Expected response structure
The assertions verify both the functional outcomes and the underlying API interactions, ensuring the implementation correctly interfaces with the Pinata IPFS service.
packages/app-data/src/importSchema.ts (1)
8-11: LGTM! Good version validation.The regex validation ensures only semantic version format is accepted, preventing directory traversal attacks.
packages/app-data/src/schemas/hook/v0.2.0.json (3)
23-27: LGTM! Proper hex string validation for callData.The regex pattern
^0x[a-fA-F0-9]*$correctly validates hex strings with 0x prefix and provides good examples.
34-38: Good addition of dappId for hook attribution.The optional
dappIdfield provides valuable tracking for hook origins, which is important for analytics and debugging.
11-11:Details
❓ Verification inconclusive
Consider the security implications of additionalProperties: false.
While this enforces strict schema validation, ensure this doesn't break backward compatibility if new properties need to be added in the future.
🏁 Script executed:
#!/bin/bash # Description: Check for usage patterns of hook objects to ensure strict validation won't break existing code # Search for hook object creation patterns rg -A 10 -B 5 "target.*callData.*gasLimit" --type tsLength of output: 54
#!/bin/bash # Search for references to the v0.2.0 hook schema in TS/JS code rg -n "hook/v0\.2\.0\.json"
Enforce strict schema validation but watch for backward compatibility
The addition of
"additionalProperties": falseinpackages/app-data/src/schemas/hook/v0.2.0.jsonwill prevent any fields not explicitly defined in the schema—improving security by rejecting unexpected input. However, it also means that any future extensions to hook objects will require a schema bump and coordinated updates in all code paths that construct or validate these objects.Please verify:
- No existing code relies on extra/untyped properties on hook objects when calling into validation.
- Downstream consumers of this schema are aware that adding new properties will now cause validation failures and plan versioning accordingly.
packages/common/package.json (2)
14-14: LGTM! Good build configuration with dual format output.The tsup configuration properly generates both ESM and CJS formats with TypeScript declarations, supporting various import patterns.
20-25:Details
✅ Verification successful
Check for potential dependency version mismatches.
Verify that the TypeScript and ESLint versions are compatible across the monorepo to avoid conflicts.
🌐 Web query:
What are the compatibility requirements between TypeScript 5.2.2 and @typescript-eslint/parser 8.32.1?💡 Result:
Based on the search results, TypeScript 5.2.2 is compatible with @typescript-eslint/parser 8.32.1. The TypeScript version range currently supported by typescript-eslint is ">=4.8.4 <5.9.0"[3], which includes TypeScript 5.2.2.
The typescript-eslint project tracks support for new TypeScript releases through dedicated issues. For TypeScript 5.2, there was an issue (#7155) to track implementation of its features[1]. The issue shows that support for TypeScript 5.2 was being implemented promptly after the RC (Release Candidate) was released.
Some users reported issues when upgrading to TypeScript 5.2, particularly regarding a deprecation error for 'originalKeywordKind'[1][9]. This error appeared because the function was deprecated in v5.0.0 and could no longer be used in TypeScript 5.2. The error message suggested using 'identifierToKeywordKind(identifier)' instead.
To resolve compatibility issues between TypeScript 5.2.2 and older versions of @typescript-eslint packages, users need to ensure they're using a compatible version of @typescript-eslint/parser. The current latest version (as of June 2025) is 8.33.0, released about 6 days before the current date[2].
If you encounter any issues with TypeScript 5.2.2 and @typescript-eslint/parser, make sure you're using an up-to-date version of the parser. The typescript-eslint packages typically maintain compatibility with TypeScript versions less than 2 years old[3].
Citations:
- 1: typescript-eslint/typescript-eslint#7155
- 2: https://www.npmjs.com/package/@typescript-eslint/parser?activeTab=versions
- 3: https://typescript-eslint.io/users/dependency-versions/
- 4: https://github.com/typescript-eslint/typescript-eslint/releases
- 5: https://www.npmjs.com/package/@typescript-eslint/eslint-plugin
- 6: https://visualstudiomagazine.com/articles/2023/08/28/typescript-5-2.aspx
- 7: https://typescript-eslint.io/packages/parser
- 8: https://classic.yarnpkg.com/en/package/@typescript-eslint/parser
- 9: vercel/next.js#56195
- 10: https://typescript-eslint.io/packages/eslint-plugin/
Confirmed dependency compatibility
The versions in packages/common/package.json (TypeScript 5.2.2, @typescript-eslint/parser 8.32.1, @typescript-eslint/eslint-plugin 8.32.1, ESLint 9.27.0) all fall within the officially supported ranges (TypeScript ≥4.8.4 <5.9.0). No conflicts detected; no changes required.
packages/app-data/src/schemas/v0.11.0.json (1)
2-2: LGTM! Proper schema ID with version.The schema ID follows a clear versioning pattern that aligns with the file structure.
packages/app-data/src/schemas/v0.1.0.json (5)
1-4: Validate schema ID and draft version
The$idcorrectly references the v0.1.0 URL and the$schemauses JSON-Schema Draft-07.
5-8: Required properties are explicit
Listing"version"and"metadata"as required keys ensures minimal document compliance.
11-16: Version property is well-defined
Referencing the external version definition and setting"readOnly": truewith the proper default"0.1.0"is correct.
17-25: OptionalappCodeproperty looks good
TheappCodestring with examples and description aligns with usage requirements.
26-38: Rootmetadataschema setup is correct
Defining an empty default and nesting thereferrersub-schema as the sole initial metadata facet is appropriate.packages/app-data/src/schemas/v0.6.0.json (6)
1-4: Schema ID and draft reference are correct
The$idpoints to v0.6.0 and the Draft-07 schema declaration is accurate.
5-8: Required fields are consistent
Maintaining"version"and"metadata"as required ensures backward compatibility for parsers.
12-17:versionproperty updated properly
Default"0.6.0"and the external$refremain consistent with versioning.
17-25:appCoderemains unchanged
The optionalappCodeproperty is reused correctly from earlier schema versions.
26-37: Newenvironmentproperty is well-defined
Including examples (production,development, etc.) offers clear guidance to consumers.
38-59: Extendedmetadatafacets are accurate
Addingutm,quote, andorderClassreferences aligns with v0.6.0 requirements.packages/app-data/src/schemas/v0.9.0.json (3)
9-12: Restrict additional properties at the root
Using"additionalProperties": falseat the top level prevents unexpected fields—good inclusion.
13-17: Version default aligns with schema version
The"default": "0.9.0"matches the file name and file intent.
45-63:metadatadefinitions are extended correctly
The added references toreferrer,utm,quote,orderClass, andhooksfollow expected version bumps.packages/app-data/src/schemas/v1.4.0.json (3)
1-4: Schema declaration is correct
The$idand$schemadeclarations correctly identify v1.4.0 with Draft-07.
13-17:versionproperty updated to 1.4.0
Default value and external reference are consistent.
46-75: Comprehensive metadata facets
Incorporatingsigner,widget,partnerFee,replacedOrder, etc., reflects v1.4.0’s expanded feature set.packages/app-data/src/schemas/v0.10.0.json (3)
1-4: Validate schema identity and draft
The$idcorrectly points to v0.10.0, and Draft-07 is consistent with other versions.
13-17: Version default set to 0.10.0
The"default": "0.10.0"is in line with the file naming.
46-66: Metadata properties match expected facets
References forsigner,referrer,utm,quote,orderClass, andhooksare properly versioned.packages/app-data/package.json (1)
1-56: Well-structured package.json for the new app-data SDK package.The package configuration looks comprehensive with appropriate ES module support, TypeScript integration, and comprehensive build/test scripts.
packages/app-data/src/schemas/v0.7.0.json (1)
1-61: Well-structured JSON schema following best practices.The schema properly uses JSON Schema Draft 07, includes appropriate descriptions and examples, and uses modular references for complex metadata types.
packages/app-data/src/api/getAppDataInfo.spec.ts (1)
1-195: Comprehensive test suite with good coverage of both current and legacy functionality.The test structure is well-organized with appropriate mocking of dependencies and covers both success and error scenarios effectively.
packages/app-data/src/schemas/v0.3.0.json (2)
1-55: Consistent schema structure maintaining backward compatibility.The v0.3.0 schema follows the same structural patterns as the newer v0.7.0 schema while providing a subset of metadata options, which demonstrates good schema evolution practices.
49-51:Details
✅ Verification successful
Verify schema reference versions align with the overall versioning strategy.
The metadata references point to
quote/v0.1.0.jsonwhile in v0.7.0 it referencesquote/v0.2.0.json. Ensure this version progression is intentional and that the referenced schemas exist.
🏁 Script executed:
#!/bin/bash # Description: Verify that the referenced schema files exist and check version progression echo "Checking for referenced schema files..." fd -t f "referrer" packages/app-data/src/schemas/ fd -t f "quote" packages/app-data/src/schemas/ echo "Checking quote schema versions..." fd -t f -e json . packages/app-data/src/schemas/ --exec grep -l "quote"Length of output: 1206
🏁 Script executed:
#!/bin/bash # Verify the quote schema reference in v0.7.0.json echo "Context for ‘quote’ in v0.7.0.json:" grep -n -C2 '"quote"' packages/app-data/src/schemas/v0.7.0.jsonLength of output: 278
All referenced quote schemas exist and version progression is correct.
- In v0.3.0.json the
quotefield refers toquote/v0.1.0.json#.- In v0.7.0.json the
quotefield refers toquote/v0.2.0.json#.No missing files were found under
packages/app-data/src/schemas/quote/. If this schema-version mapping is intentional, no further changes are required.packages/app-data/src/schemas/v1.2.0.json (1)
1-78: Well-structured JSON schema following best practices.The schema properly defines the app-data metadata structure with appropriate validation constraints, clear documentation, and modular references to external schemas.
packages/app-data/src/schemas/definitions.json (2)
1-52: Well-designed reusable definitions with appropriate constraints.All definitions have correct patterns and constraints for their intended data types. The centralization of these definitions promotes consistency across schemas.
44-50: Verify the intentional absence of0xprefix for dappId.Unlike
ethereumAddressandorderUid, thedappIdpattern doesn't require a0xprefix. Please confirm this is intentional based on the expected dApp ID format.packages/app-data/src/types.ts (3)
3-3: LGTM! Clean type definition using TypeScript utility types.The
AppDataParamstype correctly excludes the version field and makes all other fields optional, which is appropriate for partial updates or user input.
5-37: Excellent comprehensive documentation for AppDataInfo.The JSDoc comments provide clear explanations of each field, including technical details about IPFS CIDs, content addressing, and the relationship between different representations of app data.
1-1:Details
✅ Verification successful
Verify the import path resolves correctly.
Ensure that
./generatedTypesresolves to the expected index file that exports thelatestmodule.
🏁 Script executed:
#!/bin/bash # Description: Verify that the generatedTypes import resolves correctly # Expected: Should find an index file that exports a 'latest' module # Check if there's an index file in generatedTypes directory fd -t f "index\.(ts|js)" packages/app-data/src/generatedTypes/ # Check if any file exports 'latest' rg -A 3 "export.*latest" packages/app-data/src/generatedTypes/Length of output: 570
Import path resolved correctly
The
packages/app-data/src/generatedTypes/index.tsfile re-exports* from './latest', andlatest.tsexposes thelatestnamespace from./v1.4.0. The importimport { latest } from './generatedTypes'resolves as expected—no changes needed here.
packages/app-data/src/generatedTypes/v0.1.0.ts (2)
1-6: LGTM! Proper auto-generation markers and warnings.The file is correctly marked as auto-generated with appropriate warnings not to modify manually.
25-30: Note: Flexible schema design with index signatures.The interfaces use
[k: string]: unknownindex signatures, which provides extensibility but reduces type safety. This appears to be an intentional design choice for the app-data schema to allow future extensions without breaking changes.Also applies to: 34-37, 38-42
eslint.config.js (3)
2-2: LGTM! Proper namespace import for TypeScript ESLint.The change to namespace import (
* as tseslint) is appropriate for the new configuration structure.
5-10: LGTM! Clean array-based configuration structure.The new flat config format is more flexible and maintainable than the legacy configuration format.
22-49: Excellent comprehensive rule configuration.The ESLint rules are well-chosen for maintaining code quality:
- Strict TypeScript rules preventing
anyand non-null assertions- Unused imports/variables detection with sensible ignore patterns
- Consistent code formatting with
eol-lastpackage.json (4)
2-4: LGTM! Proper monorepo root configuration.The package is correctly configured as a private monorepo with ES modules, which is appropriate for the new structure.
12-22: LGTM! Minimal and focused devDependencies for monorepo tooling.The dependencies are appropriately focused on:
- ESLint and TypeScript tooling for linting
- Prettier for formatting
- TurboRepo for monorepo orchestration
- tsup for building
23-26: LGTM! Proper package manager and Node.js version constraints.Specifying pnpm as the package manager and requiring Node.js >=18 ensures consistency across development environments.
6-10:Details
✅ Verification successful
Verify the exclusion filter for @cowprotocol/cow-sdk.
The build and lint scripts exclude
@cowprotocol/cow-sdk. Ensure this package either doesn't exist yet or is intentionally excluded during the migration period.
🏁 Script executed:
#!/bin/bash # Description: Check if @cowprotocol/cow-sdk package exists and understand why it's filtered # Expected: Either the package doesn't exist or there's a specific reason for exclusion # Check if the excluded package exists fd "package\.json" packages/ --exec grep -l "@cowprotocol/cow-sdk" {} # Check for any turbo.json configuration cat turbo.json 2>/dev/null || echo "No turbo.json found"Length of output: 675
🏁 Script executed:
#!/bin/bash # Verify the published package name(s) to confirm the filter matches correctly grep '"name"' packages/cow-sdk/package.json grep '"name"' packages/cow-sdk/examples/nodejs/package.json grep '"name"' packages/cow-sdk/examples/cra/package.jsonLength of output: 253
Exclusion filter for
@cowprotocol/cow-sdkis correctVerified that the
@cowprotocol/cow-sdkpackage exists underpackages/cow-sdkand is intentionally excluded from both the build and lint pipelines via the--filter='!@cowprotocol/cow-sdk'flag. No changes required.packages/app-data/src/api/index.ts (1)
17-51: Well-designed API class with clear separation of concerns.The MetadataApi class provides a clean, unified interface for app-data functionality. The constructor properly sets up the global adapter context, and the separation between current and legacy methods enhances maintainability and backward compatibility.
packages/app-data/src/schemas/partnerFee/v1.0.0.json (1)
1-101: Comprehensive and well-structured partner fee schema.The schema effectively defines three mutually exclusive fee variants with appropriate validation constraints. The volume fee cap at 100 BPS (1%) and the higher caps for surplus/price improvement fees at 9999 BPS provide reasonable protocol-level boundaries while maintaining flexibility.
packages/app-data/src/generatedTypes/v0.4.0.ts (1)
1-62: Well-structured auto-generated types following consistent patterns.The generated TypeScript interfaces properly represent the JSON schema structure with appropriate type definitions, optional properties, and documentation. The types are consistent with other schema versions in the codebase.
packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts (5)
1-6: LGTM: Clean imports structure.The imports are well-organized and properly reference the required modules and types from the package.
8-11: LGTM: Clear interface definition.The
IpfsUploadResultinterface clearly defines the expected return structure with app data digest and CID.
27-33: LGTM: Correct implementation logic.The function correctly calls the helper and extracts the digest from the CID.
35-39: LGTM: Appropriate type definition.The
PinataPinResponsetype correctly matches Pinata's API response structure.
41-74: LGTM: Solid implementation with proper error handling.The helper function correctly:
- Validates required credentials
- Uses deterministic JSON stringification for consistent hashing
- Handles HTTP errors appropriately
- Returns the expected response structure
The implementation follows best practices for API integration.
packages/app-data/src/mocks.ts (6)
1-2: LGTM: Standard HTTP status constants.Clear and commonly used HTTP status code definitions.
4-12: LGTM: Well-structured base mock data.The app data document, its stringified form, CID, and hex representation provide a complete set of related test data.
14-27: LGTM: Comprehensive custom mock data.The extended mock properly demonstrates more complex metadata structure with referrer and quote information.
29-34: LGTM: Backend compatibility mock data.Good to have test data that matches backend service expectations for cross-system validation.
36-39: LGTM: Legacy format preservation.The legacy mock data correctly demonstrates the difference in JSON serialization approaches (non-deterministic vs deterministic stringify).
41-42: LGTM: Simple test API credentials.Clear mock API keys for testing purposes.
packages/app-data/src/generatedTypes/v0.2.0.ts (3)
1-6: LGTM: Standard generated file header.Appropriate header for auto-generated TypeScript files with clear warning not to modify manually.
8-27: LGTM: Well-defined type aliases.The type aliases provide clear semantic meaning and are properly documented with JSDoc comments.
29-57: LGTM: Consistent interface structure.The interfaces follow a consistent pattern with:
- Proper JSDoc documentation
- Index signatures for extensibility
- Clear property definitions matching the schema evolution
The structure aligns well with other schema versions in the codebase.
packages/app-data/src/generatedTypes/index.ts (6)
1-1: LGTM: Clear generated file marker.Appropriate header indicating this is a generated file.
3-18: LGTM: Complete version imports.All schema versions from v0.1.0 to v1.4.0 are properly imported with consistent naming convention.
20-20: LGTM: Latest exports re-export.Proper re-export pattern for accessing the latest schema definitions.
22-31: LGTM: Comprehensive version constants.The version constants cover all metadata types and provide clear access to latest versions for each component.
33-50: LGTM: Well-structured type unions.The type aliases provide:
LatestAppDataDocVersion: Clear reference to the current schemaAnyAppDataDocVersion: Comprehensive union supporting all versionsThe union is properly ordered from newest to oldest versions.
52-69: LGTM: Complete module re-exports.All imported schema versions are properly re-exported, maintaining consistent ordering and providing external access to specific versions.
packages/app-data/src/generatedTypes/v0.3.0.ts (2)
1-6: Generated file follows standard conventions.The auto-generation header and TSLint disable are appropriate for generated TypeScript files.
36-62: Schema structure is well-designed.The interfaces follow a logical hierarchy with proper optional/required field designations and extensibility through index signatures.
packages/app-data/src/generatedTypes/v0.5.0.ts (3)
1-7: Generated file follows standard conventions.Proper auto-generation header with modification warning.
40-40: OrderClass enumeration is appropriately versioned.The OrderClass1 type defines the expected order types for this schema version. Note that "twap" is not included yet, which is consistent with the schema evolution seen in later versions.
71-75: OrderClass interface structure is well-defined.The OrderClass interface properly combines versioning with the enumerated order class values.
packages/app-data/src/generatedTypes/v1.4.0.ts (4)
1-7: Generated file follows standard conventions.Proper auto-generation header with clear modification warnings.
93-125: Complex PartnerFee union type is well-structured.The PartnerFee type elegantly handles multiple fee calculation schemes (volume-based, surplus-based, and price improvement-based) while supporting both single objects and arrays. The union type ensures type safety for different fee models.
191-198: OrderInteractionHooks interface is well-documented.The hooks functionality is clearly documented and structured, providing good type safety for pre/post order interactions.
48-48:Details
❌ Incorrect review comment
SlippageBips type change to number.
Note that SlippageBips has changed from string (in earlier versions) to number in this version. This is a breaking change that should be handled carefully in migration logic.
Verify that the schema migration logic properly handles the SlippageBips type change from string to number:
🏁 Script executed:
#!/bin/bash # Description: Check for SlippageBips type consistency across versions # Search for SlippageBips type definitions across all versions rg "export type SlippageBips" packages/app-data/src/generatedTypes/Length of output: 1137
🏁 Script executed:
#!/bin/bash set -e echo "Finding migration-related files by filename..." find packages/app-data/src -type f \( -iname "*migration*.ts" -o -iname "*migrate*.ts" \) echo echo "Searching for migration code in content..." rg -n "migration" packages/app-data/src || true rg -n "migrate" packages/app-data/src || trueLength of output: 400
Ignore SlippageBips type change comment
SlippageBips was already changed from
stringtonumberin v1.0.0 and has remainednumberin all subsequent versions (including v1.3.0). There is no new breaking change in v1.4.0, so no migration logic updates are required here.Likely an incorrect or invalid review comment.
packages/app-data/src/generatedTypes/v0.8.0.ts (3)
1-7: Generated file follows standard conventions.Proper auto-generation header and TSLint disable directive.
48-48: OrderClass evolution includes TWAP.The addition of "twap" to the OrderClass1 union type represents a natural evolution of the trading order types supported by the protocol.
71-83: UTM tracking interface is comprehensive.The UTMCodes interface properly captures all standard UTM parameters for tracking campaign effectiveness.
packages/app-data/src/scripts/compile.ts (4)
1-14: Import statements and path setup are correct.The imports include all necessary modules and the ES module path resolution is properly handled.
72-74: Schema bundling implementation looks correct.The use of $RefParser to bundle schemas with resolved references is appropriate, and the output format is correct.
78-90: TypeScript compilation has proper error handling.The try-catch around TypeScript compilation ensures that a single schema failure doesn't stop the entire process, which is good for robustness.
108-131: Metadata version discovery uses Promise.allSettled appropriately.The use of Promise.allSettled ensures that failures in discovering individual metadata versions don't prevent the overall compilation from succeeding.
packages/app-data/src/api/appDataHexToCid.ts (1)
78-88: LGTM! Well-structured CID byte construction.The helper function correctly constructs CID bytes by concatenating the prefix with the hash bytes. The implementation properly handles the byte array operations.
packages/app-data/src/generatedTypes/v0.6.0.ts (2)
1-6: LGTM! Proper auto-generation warning.The file correctly includes the standard warning against manual modification and identifies it as auto-generated from json-schema-to-typescript.
60-60:Details
✅ Verification successful
Verify completeness of OrderClass1 union type.
The OrderClass1 type includes "market", "limit", "liquidity" but excludes "twap" which is present in v0.7.0. Ensure this difference is intentional for v0.6.0 schema requirements.
🏁 Script executed:
#!/bin/bash # Verify if 'twap' order class should be included in v0.6.0 schema echo "Checking schema differences between v0.6.0 and v0.7.0:" fd "v0.6.0.json" packages/app-data/src/schemas --exec cat {} \; | jq '.definitions.orderClass.properties.orderClass.enum // .properties.metadata.properties.orderClass.properties.orderClass.enum // empty' echo "---" fd "v0.7.0.json" packages/app-data/src/schemas --exec cat {} \; | jq '.definitions.orderClass.properties.orderClass.enum // .properties.metadata.properties.orderClass.properties.orderClass.enum // empty'Length of output: 547
🏁 Script executed:
#!/bin/bash set -e # Check that the generatedTypes files exist echo "Checking for generatedTypes files..." for file in v0.6.0.ts v0.7.0.ts; do path="packages/app-data/src/generatedTypes/$file" if [[ -f "$path" ]]; then echo " ✓ $file found" else echo " ✗ $file missing" fi done # Show the OrderClass1 union in both versions echo echo "v0.6.0.ts – export type OrderClass1:" rg -n 'export type OrderClass1' -A1 packages/app-data/src/generatedTypes/v0.6.0.ts || true echo echo "v0.7.0.ts – export type OrderClass1:" rg -n 'export type OrderClass1' -A1 packages/app-data/src/generatedTypes/v0.7.0.ts || trueLength of output: 976
OrderClass1 union is correct for v0.6.0
The v0.6.0 generated types intentionally include only
"market" | "limit" | "liquidity"—the
"twap"option was added in v0.7.0. Both the JSON schemas and the TypeScript outputs accurately reflect this versioned change.packages/app-data/src/api/getAppDataInfo.ts (1)
114-118: LGTM! Correct implementation of current CID derivation.The function properly uses keccak256 hashing and converts to CID using the current method. The implementation aligns with the documented approach.
packages/app-data/src/generatedTypes/v0.9.0.ts (2)
109-121: LGTM! Well-structured hooks interface design.The
OrderInteractionHooksandCoWHookinterfaces are well-designed with clear separation of pre/post execution hooks and comprehensive hook definition including target, callData, and gasLimit.
54-72:Details
❓ Verification inconclusive
Verify hook type definitions align with protocol requirements.
The hook-related types (target, callData, gasLimit) are defined as strings. Ensure these align with the actual protocol requirements for contract addresses, hex-encoded calldata, and numeric gas limits.
🏁 Script executed:
#!/bin/bash # Check the JSON schema definition for hooks to verify string types are correct echo "Checking hook definitions in v0.9.0 schema:" fd "v0.9.0.json" packages/app-data/src/schemas --exec cat {} \; | jq '.definitions.CoWHook // .properties.metadata.properties.hooks.properties.pre.items // empty' echo "---" echo "Looking for hook validation patterns:" fd "*.json" packages/app-data/src/schemas --exec grep -l "target\|callData\|gasLimit" {} \;Length of output: 745
🏁 Script executed:
#!/bin/bash # List all JSON schema files to ensure we locate the correct one echo "JSON schema files in packages/app-data/src/schemas:" fd -e json packages/app-data/src/schemas echo # Find the schema file that defines CoWHook schema_file=$(rg -l '"CoWHook"' packages/app-data/src/schemas | head -n1) echo "Using schema file: $schema_file" echo # Extract the properties for target, callData, and gasLimit from the CoWHook definition jq '.definitions.CoWHook.properties | {target, callData, gasLimit}' "$schema_file"Length of output: 852
🏁 Script executed:
#!/bin/bash # List all JSON schema files in the schemas directory echo "JSON schema files in packages/app-data/src/schemas:" find packages/app-data/src/schemas -type f -name '*.json' echo # Locate the v0.9.0 schema file explicitly schema_file=$(find packages/app-data/src/schemas -type f -name 'v0.9.0.json') echo "Using schema file: $schema_file" echo # Confirm CoWHook definition exists and extract its target, callData, and gasLimit types echo "Extracting CoWHook properties:" jq '.definitions.CoWHook.properties | {target, callData, gasLimit}' "$schema_file" echo # Also show where CoWHook is referenced across all schemas echo "Occurrences of CoWHook in all schemas:" grep -Rnl '"CoWHook"' packages/app-data/src/schemasLength of output: 2596
🏁 Script executed:
#!/bin/bash # Inspect the CoWHook definition in the central definitions.json schema="packages/app-data/src/schemas/definitions.json" echo "Reading CoWHook from $schema" jq '.definitions.CoWHook' "$schema"Length of output: 278
#!/bin/bash # Inspect hook schemas for property definitions echo "=== Listing hook schema files ===" find packages/app-data/src/schemas/hooks -type f -name '*.json' echo echo "=== Searching for gasLimit, callData, target in hooks schemas ===" grep -R -n '"gasLimit"' packages/app-data/src/schemas/hooks grep -R -n '"callData"' packages/app-data/src/schemas/hooks grep -R -n '"target"' packages/app-data/src/schemas/hooks
#!/bin/bash # Examine CoWHook definitions in hook-specific schema files for schema in packages/app-data/src/schemas/hooks/*.json; do echo "=== $schema ===" jq ' if .definitions.CoWHook then .definitions.CoWHook.properties | {target, callData, gasLimit} elif .properties?.pre?.items? then .properties.pre.items | {target, callData, gasLimit} else "CoWHook not found in this schema" end ' "$schema" echo done
Verify Hook type definitions align with protocol requirements
The generated types in
packages/app-data/src/generatedTypes/v0.9.0.tsare all defined asstring:export type HookTarget = string; // contract address export type HookCallData = string; // hex-encoded calldata export type HookGasLimit = string; // gas unitsPlease confirm against your JSON schemas and on-chain protocol spec that:
targetshould indeed be a hex string (and if so, that you’re enforcing address checksums/prefixes)callDatais always a hex-encoded payloadgasLimitis meant to remain a string or should instead be a numeric typePoints of review:
- Inspect the
CoWHookdefinition and its use inpackages/app-data/src/generatedTypes/v0.9.0.ts- Review the hook schemas under
packages/app-data/src/schemas/hooks/*(any version) to see how these properties are typed/validated- Align your schema and generated types so that consumers get the correct runtime type (e.g.
numbervs.stringfor gas limits)packages/app-data/src/generatedTypes/v0.7.0.ts (1)
1-104: Skip autogenerated file.
This file is generated byjson-schema-to-typescriptand should not be modified manually.packages/app-data/src/generatedTypes/v0.10.0.ts (1)
1-127: Skip autogenerated file.
This file is generated byjson-schema-to-typescriptand should not be modified manually.packages/app-data/src/generatedTypes/v0.11.0.ts (1)
1-139: Skip autogenerated file.
This file is generated byjson-schema-to-typescriptand should not be modified manually.packages/app-data/src/generatedTypes/v1.2.0.ts (1)
1-166: Skip autogenerated file.
This file is generated byjson-schema-to-typescriptand should not be modified manually.packages/app-data/src/generatedTypes/v1.1.0.ts (1)
1-161: Skip autogenerated file.
This file is generated byjson-schema-to-typescriptand should not be modified manually.packages/app-data/src/generatedTypes/v1.0.0.ts (1)
1-153: Auto-generated schema types — no manual changes needed.
This file is fully generated byjson-schema-to-typescript. No manual edits or refactoring required.packages/app-data/src/generatedTypes/v1.3.0.ts (1)
1-171: Auto-generated schema types — no manual changes needed.
This file is fully generated byjson-schema-to-typescript. No manual edits or refactoring required.
| export async function stringifyDeterministic(obj: Record<string, unknown>): Promise<string> { | ||
| const { default: stringify } = await import('json-stringify-deterministic') | ||
| return stringify(obj) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling for robustness.
The function implementation is correct, but consider adding error handling for potential failures:
export async function stringifyDeterministic(obj: Record<string, unknown>): Promise<string> {
- const { default: stringify } = await import('json-stringify-deterministic')
- return stringify(obj)
+ try {
+ const { default: stringify } = await import('json-stringify-deterministic')
+ return stringify(obj)
+ } catch (error) {
+ throw new Error(`Failed to stringify object deterministically: ${error instanceof Error ? error.message : String(error)}`)
+ }
}This prevents unhandled promise rejections if the dynamic import fails or if the stringify operation throws an 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.
| export async function stringifyDeterministic(obj: Record<string, unknown>): Promise<string> { | |
| const { default: stringify } = await import('json-stringify-deterministic') | |
| return stringify(obj) | |
| } | |
| export async function stringifyDeterministic(obj: Record<string, unknown>): Promise<string> { | |
| try { | |
| const { default: stringify } = await import('json-stringify-deterministic') | |
| return stringify(obj) | |
| } catch (error) { | |
| throw new Error( | |
| `Failed to stringify object deterministically: ${ | |
| error instanceof Error ? error.message : String(error) | |
| }` | |
| ) | |
| } | |
| } |
🤖 Prompt for AI Agents
In packages/app-data/src/utils/stringify.ts around lines 1 to 4, add error
handling to the stringifyDeterministic function to catch potential failures from
the dynamic import or the stringify operation. Wrap the import and stringify
calls in a try-catch block, and handle or rethrow errors appropriately to
prevent unhandled promise rejections and improve robustness.
| @@ -0,0 +1,16 @@ | |||
| { | |||
| "$id": "#referrer/v0.1.0.json", | |||
There was a problem hiding this comment.
Fix version mismatch between filename and schema $id.
The filename indicates v0.2.0.json but the $id field references #referrer/v0.1.0.json. This version inconsistency could cause issues with schema resolution and create confusion in the versioning system.
Apply this diff to fix the version mismatch:
- "$id": "#referrer/v0.1.0.json",
+ "$id": "#referrer/v0.2.0.json",📝 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": "#referrer/v0.1.0.json", | |
| "$id": "#referrer/v0.2.0.json", |
🤖 Prompt for AI Agents
In packages/app-data/src/schemas/referrer/v0.2.0.json at line 2, the $id field
incorrectly references version v0.1.0 instead of v0.2.0. Update the $id value to
"#referrer/v0.2.0.json" to match the filename and maintain consistent versioning
in the schema.
| import { DEFAULT_IPFS_READ_URI } from '../consts' | ||
| import { fetchDocFromCid } from './fetchDocFromCid' | ||
|
|
There was a problem hiding this comment.
Missing import for fetchMock.
The test uses fetchMock but it's not imported. This will cause a compilation error.
Add the missing import:
+import fetchMock from 'jest-fetch-mock'
import { DEFAULT_IPFS_READ_URI } from '../consts'
import { fetchDocFromCid } from './fetchDocFromCid'📝 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 { DEFAULT_IPFS_READ_URI } from '../consts' | |
| import { fetchDocFromCid } from './fetchDocFromCid' | |
| import fetchMock from 'jest-fetch-mock' | |
| import { DEFAULT_IPFS_READ_URI } from '../consts' | |
| import { fetchDocFromCid } from './fetchDocFromCid' |
🤖 Prompt for AI Agents
In packages/app-data/src/api/fetchDocFromCid.spec.ts at the beginning of the
file (lines 1 to 3), the test uses fetchMock but it is not imported, causing a
compilation error. Add the appropriate import statement for fetchMock from the
relevant testing or mocking library at the top of the file along with the
existing imports.
| @@ -0,0 +1,15 @@ | |||
| { | |||
| "$id": "#quote/v0.2.0.json", | |||
There was a problem hiding this comment.
Fix version inconsistency in schema ID.
The schema ID shows #quote/v0.2.0.json but the filename is v1.0.0.json. This inconsistency will cause schema resolution issues and confusion in the versioning system.
Apply this fix to align the schema ID with the filename:
- "$id": "#quote/v0.2.0.json",
+ "$id": "#quote/v1.0.0.json",📝 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": "#quote/v0.2.0.json", | |
| "$id": "#quote/v1.0.0.json", |
🤖 Prompt for AI Agents
In packages/app-data/src/schemas/quote/v1.0.0.json at line 2, the schema ID is
incorrectly set to "#quote/v0.2.0.json" which does not match the file version.
Update the "$id" value to "#quote/v1.0.0.json" to ensure the schema ID aligns
with the filename version and avoid resolution issues.
| "description": "Tracks in which medium the traffic originated from (mail, CPC, social, etc.)" | ||
| }, | ||
| "utmCampaign": { | ||
| "$id": "#/properties/utmCampagin", |
There was a problem hiding this comment.
Fix typo in property ID.
The property ID contains a typo: utmCampagin should be utmCampaign.
- "$id": "#/properties/utmCampagin",
+ "$id": "#/properties/utmCampaign",📝 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": "#/properties/utmCampagin", | |
| "$id": "#/properties/utmCampaign", |
🤖 Prompt for AI Agents
In packages/app-data/src/schemas/utm/v0.1.0.json at line 27, correct the typo in
the property ID by changing "utmCampagin" to "utmCampaign" to ensure consistency
and correctness in the schema definition.
| @@ -0,0 +1,63 @@ | |||
| { | |||
| "$id": "https://cowswap.exchange/schemas/app-data/v0.7.0.json", | |||
There was a problem hiding this comment.
Fix critical version mismatch in schema.
The schema has a severe version inconsistency: the $id references v0.7.0.json (line 2) while the filename is v0.8.0.json and the default version is "0.8.0" (line 16). This will break schema resolution and validation.
Correct the $id to match the filename and version:
- "$id": "https://cowswap.exchange/schemas/app-data/v0.7.0.json",
+ "$id": "https://cowswap.exchange/schemas/app-data/v0.8.0.json",Also applies to: 16-16
🤖 Prompt for AI Agents
In packages/app-data/src/schemas/v0.8.0.json at lines 2 and 16, the $id field
and the default version string reference v0.7.0 instead of v0.8.0, causing a
version mismatch. Update the $id URL on line 2 to end with v0.8.0.json and
change the default version string on line 16 to "0.8.0" to ensure consistency
with the filename and correct schema resolution.
| "version": { | ||
| "$ref": "definitions.json#/definitions/version", | ||
| "readOnly": true, | ||
| "default": "0.11.0" | ||
| }, |
There was a problem hiding this comment.
Critical: Version mismatch - filename is v1.1.0 but default version is "0.11.0".
The schema filename and $id indicate version 1.1.0, but the default version value is set to "0.11.0". This inconsistency will cause documents to be created with the wrong version identifier.
"version": {
"$ref": "definitions.json#/definitions/version",
"readOnly": true,
- "default": "0.11.0"
+ "default": "1.1.0"
},📝 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.
| "version": { | |
| "$ref": "definitions.json#/definitions/version", | |
| "readOnly": true, | |
| "default": "0.11.0" | |
| }, | |
| "version": { | |
| "$ref": "definitions.json#/definitions/version", | |
| "readOnly": true, | |
| "default": "1.1.0" | |
| }, |
🤖 Prompt for AI Agents
In packages/app-data/src/schemas/v1.1.0.json around lines 10 to 14, the default
version value is incorrectly set to "0.11.0" which conflicts with the schema
filename and $id indicating version 1.1.0. Update the default version value to
"1.1.0" to ensure consistency and correct version identification in created
documents.
| { | ||
| instancePath: '/metadata/quote/slippageBips', | ||
| keyword: 'minimum', | ||
| message: 'must be >= 0', | ||
| params: { | ||
| comparison: '>=', | ||
| limit: 0, | ||
| }, | ||
| schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/minimum', | ||
| }, | ||
| ] | ||
| ) |
There was a problem hiding this comment.
Fix incorrect schema path in error assertion.
The schemaPath references partnerFee properties but this test is validating quote metadata.
- schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/minimum',
+ schemaPath: '#/properties/metadata/properties/quote/properties/slippageBips/minimum',📝 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.
| { | |
| instancePath: '/metadata/quote/slippageBips', | |
| keyword: 'minimum', | |
| message: 'must be >= 0', | |
| params: { | |
| comparison: '>=', | |
| limit: 0, | |
| }, | |
| schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/minimum', | |
| }, | |
| ] | |
| ) | |
| { | |
| instancePath: '/metadata/quote/slippageBips', | |
| keyword: 'minimum', | |
| message: 'must be >= 0', | |
| params: { | |
| comparison: '>=', | |
| limit: 0, | |
| }, | |
| - schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/minimum', | |
| + schemaPath: '#/properties/metadata/properties/quote/properties/slippageBips/minimum', | |
| }, |
🤖 Prompt for AI Agents
In packages/app-data/test/schema.spec.ts between lines 854 and 865, the
schemaPath in the error assertion incorrectly references 'partnerFee' properties
while the test is validating 'quote' metadata. Update the schemaPath to
correctly point to the 'quote' metadata properties path that corresponds to
'slippageBips' to accurately reflect the validation context.
| { | ||
| instancePath: '/metadata/quote/slippageBips', | ||
| keyword: 'maximum', | ||
| message: 'must be <= 10000', | ||
| params: { | ||
| comparison: '<=', | ||
| limit: 10000, | ||
| }, | ||
| schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/maximum', | ||
| }, | ||
| ] | ||
| ) |
There was a problem hiding this comment.
Fix incorrect schema path in error assertion.
The schemaPath references partnerFee properties but this test is validating quote metadata.
- schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/maximum',
+ schemaPath: '#/properties/metadata/properties/quote/properties/slippageBips/maximum',📝 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.
| { | |
| instancePath: '/metadata/quote/slippageBips', | |
| keyword: 'maximum', | |
| message: 'must be <= 10000', | |
| params: { | |
| comparison: '<=', | |
| limit: 10000, | |
| }, | |
| schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/maximum', | |
| }, | |
| ] | |
| ) | |
| { | |
| instancePath: '/metadata/quote/slippageBips', | |
| keyword: 'maximum', | |
| message: 'must be <= 10000', | |
| params: { | |
| comparison: '<=', | |
| limit: 10000, | |
| }, | |
| schemaPath: '#/properties/metadata/properties/quote/properties/slippageBips/maximum', | |
| }, | |
| ] | |
| ) |
🤖 Prompt for AI Agents
In packages/app-data/test/schema.spec.ts between lines 877 and 888, the
schemaPath in the error assertion incorrectly references 'partnerFee' properties
instead of the 'quote' metadata being validated. Update the schemaPath to
correctly point to the 'quote' metadata slippageBips maximum property to match
the instancePath and validation context.
| test( | ||
| 'Invalid partner fee: missing slippageBips', | ||
| _buildAssertInvalidFn( | ||
| validator, | ||
| { | ||
| ...BASE_DOCUMENT, | ||
| metadata: { quote: { slippageBips: -1 } }, | ||
| }, | ||
| [ | ||
| { | ||
| instancePath: '/metadata/quote/slippageBips', | ||
| keyword: 'minimum', | ||
| message: 'must be >= 0', | ||
| params: { | ||
| comparison: '>=', | ||
| limit: 0, | ||
| }, | ||
| schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/minimum', | ||
| }, | ||
| ] | ||
| ) | ||
| ) |
There was a problem hiding this comment.
Fix copy-pasted test descriptions.
Several test descriptions incorrectly refer to "partner fee" when they're actually testing quote metadata:
- Line 825: "Invalid partner fee: unknown field"
- Line 846: "Invalid partner fee: missing slippageBips"
- Line 869: "Invalid partner fee: missing slippageBips"
These should be updated to accurately describe what's being tested.
- 'Invalid partner fee: unknown field',
+ 'Invalid quote: unknown field',- 'Invalid partner fee: missing slippageBips',
+ 'Invalid quote: missing slippageBips',- 'Invalid partner fee: missing slippageBips',
+ 'Invalid quote: slippageBips too low',📝 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.
| test( | |
| 'Invalid partner fee: missing slippageBips', | |
| _buildAssertInvalidFn( | |
| validator, | |
| { | |
| ...BASE_DOCUMENT, | |
| metadata: { quote: { slippageBips: -1 } }, | |
| }, | |
| [ | |
| { | |
| instancePath: '/metadata/quote/slippageBips', | |
| keyword: 'minimum', | |
| message: 'must be >= 0', | |
| params: { | |
| comparison: '>=', | |
| limit: 0, | |
| }, | |
| schemaPath: '#/properties/metadata/properties/partnerFee/properties/bps/minimum', | |
| }, | |
| ] | |
| ) | |
| ) | |
| --- a/packages/app-data/test/schema.spec.ts | |
| +++ b/packages/app-data/test/schema.spec.ts | |
| @@ -825,7 +825,7 @@ | |
| - 'Invalid partner fee: unknown field', | |
| + 'Invalid quote: unknown field', | |
| @@ -846,7 +846,7 @@ | |
| - 'Invalid partner fee: missing slippageBips', | |
| + 'Invalid quote: missing slippageBips', | |
| @@ -869,7 +869,7 @@ | |
| - 'Invalid partner fee: missing slippageBips', | |
| + 'Invalid quote: slippageBips too low', |
🤖 Prompt for AI Agents
In packages/app-data/test/schema.spec.ts around lines 845 to 866, the test
description incorrectly refers to "Invalid partner fee: missing slippageBips"
while the test is actually validating quote metadata. Update the test
description to accurately reflect that it is testing invalid quote metadata
related to slippageBips, not partner fee.
alfetopito
left a comment
alfetopito
left a comment
There was a problem hiding this comment.
Don't forget to sign the CLA please
| parser: tseslint.parser, | ||
| parserOptions: { | ||
| project: './packages/*/tsconfig.json', | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify TypeScript project references in monorepo.
The parser configuration references ./packages/*/tsconfig.json. Ensure all packages have their own tsconfig.json files.
🏁 Script executed:
#!/bin/bash
# Description: Verify that all packages have tsconfig.json files
# Expected: Each package directory should have a tsconfig.json
# Find all package directories
fd -t d . packages/ -d 1
# Check for tsconfig.json in each package
fd "tsconfig\.json" packages/Length of output: 538
Ensure ESLint parserOptions.project covers every tsconfig.json in the monorepo
Our fd check shows that ./packages/*/tsconfig.json currently matches only four folders (app-data, common, config, cow-sdk). It misses:
packages/typescript-config(no tsconfig.json present)- All adapter packages under
packages/providers/*/tsconfig.json(nested one level down)
To fix:
- Add a tsconfig.json to
packages/typescript-config(and topackages/providersitself if it’s meant to be a standalone package). - Update eslint.config.js so the glob picks up nested tsconfigs. For example:
parserOptions: {
- project: './packages/*/tsconfig.json',
+ project: [
+ './packages/*/tsconfig.json',
+ './packages/*/*/tsconfig.json'
+ ],
},Or simplify to a single recursive pattern:
parserOptions: {
project: './packages/**/tsconfig.json',
},🤖 Prompt for AI Agents
In eslint.config.js around lines 17 to 20, the parserOptions.project is set to
'./packages/*/tsconfig.json', which misses nested tsconfig.json files in
subdirectories like packages/providers/* and the packages/typescript-config
folder lacks a tsconfig.json. To fix this, add a tsconfig.json file to
packages/typescript-config and any other standalone package folders missing it,
then update the parserOptions.project glob pattern to
'./packages/**/tsconfig.json' to recursively include all tsconfig.json files in
nested package folders.
| export async function fetchDocFromAppDataHex( | ||
| appDataHex: string, | ||
| ipfsUri?: string | ||
| ): Promise<void | AnyAppDataDocVersion> { | ||
| return _fetchDocFromCidAux(appDataHexToCid, appDataHex, ipfsUri) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Replace void with undefined in union return type.
The static analysis correctly identifies that void in union types is confusing. Use undefined instead to clearly indicate the absence of a value.
-): Promise<void | AnyAppDataDocVersion> {
+): Promise<undefined | AnyAppDataDocVersion> {📝 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 fetchDocFromAppDataHex( | |
| appDataHex: string, | |
| ipfsUri?: string | |
| ): Promise<void | AnyAppDataDocVersion> { | |
| return _fetchDocFromCidAux(appDataHexToCid, appDataHex, ipfsUri) | |
| } | |
| export async function fetchDocFromAppDataHex( | |
| appDataHex: string, | |
| ipfsUri?: string | |
| ): Promise<undefined | AnyAppDataDocVersion> { | |
| return _fetchDocFromCidAux(appDataHexToCid, appDataHex, ipfsUri) | |
| } |
🧰 Tools
🪛 Biome (1.9.4)
[error] 19-19: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
🤖 Prompt for AI Agents
In packages/app-data/src/api/fetchDocFromAppData.ts between lines 16 and 21,
replace the union return type 'void | AnyAppDataDocVersion' with 'undefined |
AnyAppDataDocVersion' to avoid confusion caused by using 'void' in union types
and clearly indicate the absence of a value.
| export async function fetchDocFromAppDataHexLegacy( | ||
| appDataHex: string, | ||
| ipfsUri?: string | ||
| ): Promise<void | AnyAppDataDocVersion> { | ||
| return _fetchDocFromCidAux(appDataHexToCidLegacy, appDataHex, ipfsUri) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Replace void with undefined in union return type.
Same issue as the main function - use undefined instead of void for clearer semantics.
-): Promise<void | AnyAppDataDocVersion> {
+): Promise<undefined | AnyAppDataDocVersion> {📝 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 fetchDocFromAppDataHexLegacy( | |
| appDataHex: string, | |
| ipfsUri?: string | |
| ): Promise<void | AnyAppDataDocVersion> { | |
| return _fetchDocFromCidAux(appDataHexToCidLegacy, appDataHex, ipfsUri) | |
| } | |
| export async function fetchDocFromAppDataHexLegacy( | |
| appDataHex: string, | |
| ipfsUri?: string | |
| ): Promise<undefined | AnyAppDataDocVersion> { | |
| return _fetchDocFromCidAux(appDataHexToCidLegacy, appDataHex, ipfsUri) | |
| } |
🧰 Tools
🪛 Biome (1.9.4)
[error] 35-35: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
🤖 Prompt for AI Agents
In packages/app-data/src/api/fetchDocFromAppData.ts around lines 32 to 37, the
return type of the function fetchDocFromAppDataHexLegacy uses a union with void,
which should be replaced with undefined for clearer semantics. Update the
Promise return type from Promise<void | AnyAppDataDocVersion> to
Promise<undefined | AnyAppDataDocVersion> to reflect this change.
| export async function _fetchDocFromCidAux( | ||
| hexToCid: (appDataHex: string) => Promise<string>, | ||
| appDataHex: string, | ||
| ipfsUri?: string | ||
| ): Promise<void | AnyAppDataDocVersion> { | ||
| try { | ||
| const cid = await hexToCid(appDataHex) | ||
| if (!cid) throw new MetaDataError('Error getting serialized CID') | ||
| return fetchDocFromCid(cid, ipfsUri) | ||
| } catch (e) { | ||
| const error = e as MetaDataError | ||
| // console.error(`Error fetching the IPFS document: appDataHex=${appDataHex}`, error) | ||
| throw new MetaDataError(`Error decoding AppData: appDataHex=${appDataHex}, message=${error.message}`) | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Replace void with undefined in union return type and improve error handling.
The helper function has the same return type issue. Additionally, the error handling logic is sound, properly wrapping exceptions with context for debugging.
-): Promise<void | AnyAppDataDocVersion> {
+): Promise<undefined | AnyAppDataDocVersion> {📝 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 _fetchDocFromCidAux( | |
| hexToCid: (appDataHex: string) => Promise<string>, | |
| appDataHex: string, | |
| ipfsUri?: string | |
| ): Promise<void | AnyAppDataDocVersion> { | |
| try { | |
| const cid = await hexToCid(appDataHex) | |
| if (!cid) throw new MetaDataError('Error getting serialized CID') | |
| return fetchDocFromCid(cid, ipfsUri) | |
| } catch (e) { | |
| const error = e as MetaDataError | |
| // console.error(`Error fetching the IPFS document: appDataHex=${appDataHex}`, error) | |
| throw new MetaDataError(`Error decoding AppData: appDataHex=${appDataHex}, message=${error.message}`) | |
| } | |
| } | |
| export async function _fetchDocFromCidAux( | |
| hexToCid: (appDataHex: string) => Promise<string>, | |
| appDataHex: string, | |
| ipfsUri?: string | |
| ): Promise<undefined | AnyAppDataDocVersion> { | |
| try { | |
| const cid = await hexToCid(appDataHex) | |
| if (!cid) throw new MetaDataError('Error getting serialized CID') | |
| return fetchDocFromCid(cid, ipfsUri) | |
| } catch (e) { | |
| const error = e as MetaDataError | |
| // console.error(`Error fetching the IPFS document: appDataHex=${appDataHex}`, error) | |
| throw new MetaDataError(`Error decoding AppData: appDataHex=${appDataHex}, message=${error.message}`) | |
| } | |
| } |
🧰 Tools
🪛 Biome (1.9.4)
[error] 43-43: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
🤖 Prompt for AI Agents
In packages/app-data/src/api/fetchDocFromAppData.ts between lines 39 and 53,
replace the union return type void with undefined to correctly represent the
absence of a value. The error handling is appropriate, so keep the try-catch
block as is, ensuring exceptions are wrapped with context for better debugging.
| /** | ||
| * Uploads a appDocument to IPFS | ||
| * | ||
| * @deprecated Pinata IPFS automatically pins the uploaded document using some implicity encoding and hashing algorithm. This method is not used anymore to make it more explicit these parameters and therefore less depednent on the default impleemntation of Pinata | ||
| * | ||
| * @param appDataDoc Document to upload | ||
| * @param ipfsConfig keys to access the IPFS API | ||
| * | ||
| * @returns the IPFS CID v0 of the content | ||
| */ | ||
| export async function uploadMetadataDocToIpfsLegacy( | ||
| appDataDoc: AnyAppDataDocVersion, | ||
| ipfsConfig: Ipfs | ||
| ): Promise<IpfsUploadResult | void> { |
There was a problem hiding this comment.
Fix return type and deprecation comment typos.
The function has several issues:
- Static analysis correctly flagged the
| voidin return type as confusing - Multiple typos in the deprecation comment
Apply this diff to fix the issues:
/**
* Uploads a appDocument to IPFS
*
- * @deprecated Pinata IPFS automatically pins the uploaded document using some implicity encoding and hashing algorithm. This method is not used anymore to make it more explicit these parameters and therefore less depednent on the default impleemntation of Pinata
+ * @deprecated Pinata IPFS automatically pins the uploaded document using some implicit encoding and hashing algorithm. This method is not used anymore to make it more explicit these parameters and therefore less dependent on the default implementation of Pinata
*
* @param appDataDoc Document to upload
* @param ipfsConfig keys to access the IPFS API
*
* @returns the IPFS CID v0 of the content
*/
export async function uploadMetadataDocToIpfsLegacy(
appDataDoc: AnyAppDataDocVersion,
ipfsConfig: Ipfs
-): Promise<IpfsUploadResult | void> {
+): Promise<IpfsUploadResult | undefined> {🧰 Tools
🪛 Biome (1.9.4)
[error] 26-26: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
🤖 Prompt for AI Agents
In packages/app-data/src/api/uploadMetadataDocToIpfsLegacy.ts around lines 13 to
26, fix the return type by removing the confusing '| void' so it clearly
reflects the actual return type. Also, correct the typos in the deprecation
comment, such as "implicity" to "implicit," "depednent" to "dependent," and
"impleemntation" to "implementation," to improve clarity and professionalism.
| const generatedFiles = [typesIndexFile, latestIndexFile] | ||
| for (const file of generatedFiles) { | ||
| await file.write(`// generated file, do not edit manually\n\n`) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
File initialization could be improved.
The script creates multiple file handles but doesn't ensure they're closed if an error occurs during the initial setup phase.
Consider using a try-finally block or proper resource management:
const generatedFiles = [typesIndexFile, latestIndexFile]
+ try {
for (const file of generatedFiles) {
await file.write(`// generated file, do not edit manually\n\n`)
}
+ // ... rest of the compilation logic
+ } finally {
+ // Ensure files are always closed
+ for (const file of generatedFiles) {
+ await file.close().catch(() => {})
+ }
+ }📝 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 generatedFiles = [typesIndexFile, latestIndexFile] | |
| for (const file of generatedFiles) { | |
| await file.write(`// generated file, do not edit manually\n\n`) | |
| } | |
| const generatedFiles = [typesIndexFile, latestIndexFile] | |
| try { | |
| for (const file of generatedFiles) { | |
| await file.write(`// generated file, do not edit manually\n\n`) | |
| } | |
| // ... rest of the compilation logic | |
| } finally { | |
| // Ensure files are always closed | |
| for (const file of generatedFiles) { | |
| await file.close().catch(() => {}) | |
| } | |
| } |
🤖 Prompt for AI Agents
In packages/app-data/src/scripts/compile.ts around lines 46 to 49, the code
opens multiple file handles for writing but does not guarantee they are closed
if an error occurs during initialization. To fix this, wrap the file writing
operations in a try-finally block or use a resource management pattern to ensure
each file handle is properly closed even if an error is thrown, preventing
resource leaks.
| * @param appDataHex hex with tha appData hash | ||
| * @returns the IPFS CID v0 of the content |
There was a problem hiding this comment.
Fix incorrect comment about return type.
The comment states "returns the IPFS CID v0" but the implementation actually returns a CIDv1 encoded in base16.
- * @returns the IPFS CID v0 of the content
+ * @returns the IPFS CID v1 of the content📝 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.
| * @param appDataHex hex with tha appData hash | |
| * @returns the IPFS CID v0 of the content | |
| * @param appDataHex hex with tha appData hash | |
| - * @returns the IPFS CID v0 of the content | |
| + * @returns the IPFS CID v1 of the content |
🤖 Prompt for AI Agents
In packages/app-data/src/api/appDataHexToCid.ts around lines 40 to 41, the
comment incorrectly states that the function returns an IPFS CID v0, but the
actual implementation returns a CIDv1 encoded in base16. Update the comment to
accurately reflect that the return value is a CIDv1 encoded in base16 instead of
CID v0.
| } catch (e) { | ||
| const error = e as MetaDataError | ||
| console.error('Failed to calculate appDataHex', error) | ||
| throw new MetaDataError(`Failed to calculate appDataHex: ${error.message}`) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve error handling to avoid unsafe type casting.
The current implementation unsafely casts any error to MetaDataError, which could mask important error information.
} catch (e) {
- const error = e as MetaDataError
- console.error('Failed to calculate appDataHex', error)
- throw new MetaDataError(`Failed to calculate appDataHex: ${error.message}`)
+ const errorMessage = e instanceof Error ? e.message : String(e)
+ console.error('Failed to calculate appDataHex', e)
+ throw new MetaDataError(`Failed to calculate appDataHex: ${errorMessage}`)
}📝 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.
| } catch (e) { | |
| const error = e as MetaDataError | |
| console.error('Failed to calculate appDataHex', error) | |
| throw new MetaDataError(`Failed to calculate appDataHex: ${error.message}`) | |
| } catch (e) { | |
| const errorMessage = e instanceof Error ? e.message : String(e) | |
| console.error('Failed to calculate appDataHex', e) | |
| throw new MetaDataError(`Failed to calculate appDataHex: ${errorMessage}`) |
🤖 Prompt for AI Agents
In packages/app-data/src/api/getAppDataInfo.ts around lines 101 to 104, avoid
unsafe casting of the caught error to MetaDataError. Instead, handle the error
more safely by checking if the error is an instance of MetaDataError before
casting, or otherwise handle it as a generic error. Update the error logging and
throwing logic to preserve the original error information without assuming its
type.
| export async function getAppDataInfo(appData: AnyAppDataDocVersion): Promise<AppDataInfo> | ||
|
|
||
| /** | ||
| * Calculate the app-data information (cid, appDataHex, appDataContent). | ||
| * | ||
| * - appDataContent is the exact string with the pre-image that gets hashed using keccak to get the appDataHex | ||
| * - appDataHex is the hex used for the bytes32 struct field appData in the CoW order | ||
| * - cid is the IPFS identifier of the appDataHex. If the document is in IPFS it can be found using this identifier. | ||
| */ | ||
| export async function getAppDataInfo(fullAppData: string): Promise<AppDataInfo | undefined> |
There was a problem hiding this comment.
Fix inconsistent return types in function overloads.
The second overload returns Promise<AppDataInfo | undefined> while the implementation returns Promise<AppDataInfo>, creating a type mismatch that could lead to runtime errors.
export async function getAppDataInfo(appData: AnyAppDataDocVersion): Promise<AppDataInfo>
-export async function getAppDataInfo(fullAppData: string): Promise<AppDataInfo | undefined>
+export async function getAppDataInfo(fullAppData: string): Promise<AppDataInfo>📝 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 getAppDataInfo(appData: AnyAppDataDocVersion): Promise<AppDataInfo> | |
| /** | |
| * Calculate the app-data information (cid, appDataHex, appDataContent). | |
| * | |
| * - appDataContent is the exact string with the pre-image that gets hashed using keccak to get the appDataHex | |
| * - appDataHex is the hex used for the bytes32 struct field appData in the CoW order | |
| * - cid is the IPFS identifier of the appDataHex. If the document is in IPFS it can be found using this identifier. | |
| */ | |
| export async function getAppDataInfo(fullAppData: string): Promise<AppDataInfo | undefined> | |
| export async function getAppDataInfo(appData: AnyAppDataDocVersion): Promise<AppDataInfo> | |
| /** | |
| * Calculate the app-data information (cid, appDataHex, appDataContent). | |
| * | |
| * - appDataContent is the exact string with the pre-image that gets hashed using keccak to get the appDataHex | |
| * - appDataHex is the hex used for the bytes32 struct field appData in the CoW order | |
| * - cid is the IPFS identifier of the appDataHex. If the document is in IPFS it can be found using this identifier. | |
| */ | |
| -export async function getAppDataInfo(fullAppData: string): Promise<AppDataInfo | undefined> | |
| +export async function getAppDataInfo(fullAppData: string): Promise<AppDataInfo> |
🤖 Prompt for AI Agents
In packages/app-data/src/api/getAppDataInfo.ts around lines 17 to 26, the
function overloads for getAppDataInfo have inconsistent return types: one
returns Promise<AppDataInfo> and the other Promise<AppDataInfo | undefined>. To
fix this, ensure both overload signatures and the implementation have the same
return type, either by removing the undefined from the second overload or
adjusting the implementation to possibly return undefined, so the types align
correctly.
|
I have read the CLA Document and I hereby sign the CLA |
4 participants
This PR moves config files from original SDK to a new package sdk-config and refactor its structure
Key commits:
Summary by CodeRabbit
New Features
@cowprotocol/sdk-app-datapackage for managing and validating CoW Protocol order metadata, including schema definitions, document generation, validation, and IPFS integration.Bug Fixes
Documentation
Style
Chores