Conversation
📝 WalkthroughWalkthroughIntroduces dual ESM/CJS builds across multiple packages via new tsconfig.esm.json/tsconfig.cjs.json and exports maps; updates package.json entries and clean scripts; adjusts root tsconfigs and removes tsconfig.web.json; adds Vite define for process.env; updates a few imports and env access in contracts; removes one token color entry; adds a small re-export. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant App as Consumer App
participant Resolver as Module Resolver
participant Pkg as @shapeshiftoss/* package
Note over App,Resolver: Import package entry
App->>Resolver: import "@shapeshiftoss/pkg"
alt ESM environment
Resolver->>Pkg: Read exports["."].import
Pkg-->>App: dist/esm/index.js (types: dist/esm/index.d.ts)
else CJS environment
Resolver->>Pkg: Read exports["."].require
Pkg-->>App: dist/cjs/index.js
end
Note over App,Pkg: Dual outputs via tsconfig.esm.json / tsconfig.cjs.json
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
✨ Finishing Touches
🧪 Generate unit tests
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. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
NeOMakinG
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 43
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (10)
src/state/migrations/index.ts (1)
42-211: Optional DRY: generate the monotonous 0…167 map programmatically and centralize the versionThe hand-maintained list is error-prone (every bump risks missing a number). Consider a single source of truth for the version and programmatically building the manifest. Keeps future bumps to a 1-line change.
Apply this refactor to replace the explicit entries with a generated map:
-export const clearAssetsMigrations = { - 0: clearAssets, - 1: clearAssets, - 2: clearAssets, - 3: clearAssets, - 4: clearAssets, - 5: clearAssets, - 6: clearAssets, - 7: clearAssets, - 8: clearAssets, - 9: clearAssets, - 10: clearAssets, - 11: clearAssets, - 12: clearAssets, - 13: clearAssets, - 14: clearAssets, - 15: clearAssets, - 16: clearAssets, - 17: clearAssets, - 18: clearAssets, - 19: clearAssets, - 20: clearAssets, - 21: clearAssets, - 22: clearAssets, - 23: clearAssets, - 24: clearAssets, - 25: clearAssets, - 26: clearAssets, - 27: clearAssets, - 28: clearAssets, - 29: clearAssets, - 30: clearAssets, - 31: clearAssets, - 32: clearAssets, - 33: clearAssets, - 34: clearAssets, - 35: clearAssets, - 36: clearAssets, - 37: clearAssets, - 38: clearAssets, - 39: clearAssets, - 40: clearAssets, - 41: clearAssets, - 42: clearAssets, - 43: clearAssets, - 44: clearAssets, - 45: clearAssets, - 46: clearAssets, - 47: clearAssets, - 48: clearAssets, - 49: clearAssets, - 50: clearAssets, - 51: clearAssets, - 52: clearAssets, - 53: clearAssets, - 54: clearAssets, - 55: clearAssets, - 56: clearAssets, - 57: clearAssets, - 58: clearAssets, - 59: clearAssets, - 60: clearAssets, - 61: clearAssets, - 62: clearAssets, - 63: clearAssets, - 64: clearAssets, - 65: clearAssets, - 66: clearAssets, - 67: clearAssets, - 68: clearAssets, - 69: clearAssets, - 70: clearAssets, - 71: clearAssets, - 72: clearAssets, - 73: clearAssets, - 74: clearAssets, - 75: clearAssets, - 76: clearAssets, - 77: clearAssets, - 78: clearAssets, - 79: clearAssets, - 80: clearAssets, - 81: clearAssets, - 82: clearAssets, - 83: clearAssets, - 84: clearAssets, - 85: clearAssets, - 86: clearAssets, - 87: clearAssets, - 88: clearAssets, - 89: clearAssets, - 90: clearAssets, - 91: clearAssets, - 92: clearAssets, - 93: clearAssets, - 94: clearAssets, - 95: clearAssets, - 96: clearAssets, - 97: clearAssets, - 98: clearAssets, - 99: clearAssets, - 100: clearAssets, - 101: clearAssets, - 102: clearAssets, - 103: clearAssets, - 104: clearAssets, - 105: clearAssets, - 106: clearAssets, - 107: clearAssets, - 108: clearAssets, - 109: clearAssets, - 110: clearAssets, - 111: clearAssets, - 112: clearAssets, - 113: clearAssets, - 114: clearAssets, - 115: clearAssets, - 116: clearAssets, - 117: clearAssets, - 118: clearAssets, - 119: clearAssets, - 120: clearAssets, - 121: clearAssets, - 122: clearAssets, - 123: clearAssets, - 124: clearAssets, - 125: clearAssets, - 126: clearAssets, - 127: clearAssets, - 128: clearAssets, - 129: clearAssets, - 130: clearAssets, - 131: clearAssets, - 132: clearAssets, - 133: clearAssets, - 134: clearAssets, - 135: clearAssets, - 136: clearAssets, - 137: clearAssets, - 138: clearAssets, - 139: clearAssets, - 140: clearAssets, - 141: clearAssets, - 142: clearAssets, - 143: clearAssets, - 144: clearAssets, - 145: clearAssets, - 146: clearAssets, - 147: clearAssets, - 148: clearAssets, - 149: clearAssets, - 150: clearAssets, - 151: clearAssets, - 152: clearAssets, - 153: clearAssets, - 154: clearAssets, - 155: clearAssets, - 156: clearAssets, - 157: clearAssets, - 158: clearAssets, - 159: clearAssets, - 160: clearAssets, - 161: clearAssets, - 162: clearAssets, - 163: clearAssets, - 164: clearAssets, - 165: clearAssets, - 166: clearAssets, - 167: clearAssets, -} as unknown as Omit<MigrationManifest, '_persist'> +export const ASSETS_MIGRATION_VERSION = 167 as const + +export const clearAssetsMigrations = Object.fromEntries( + Array.from({ length: ASSETS_MIGRATION_VERSION + 1 }, (_, i) => [i, clearAssets]) +) as unknown as Omit<MigrationManifest, '_persist'>Notes:
- ASSETS_MIGRATION_VERSION follows the UPPER_SNAKE_CASE constant guideline.
- Keep the cast pattern for parity with existing code and redux-persist’s Manifest typing. If your TS config supports it and the types line up, you could trial satisfies Omit<...> instead of as unknown as in a separate pass for all manifests to maintain consistency.
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx (5)
1687-1696: Bug: Wrong loading flag used for Rune fee estimation; should use isEstimatedRuneFeesDataLoading.The second clause checks runeTxFeeCryptoBaseUnit but gates on isEstimatedPoolAssetFeesDataLoading, which can hide the correct loading state or show a spinner at the wrong time.
Apply this diff:
isApprovalTxPending || (isSweepNeeded === undefined && isSweepNeededLoading && !isApprovalRequired) || - (runeTxFeeCryptoBaseUnit === undefined && isEstimatedPoolAssetFeesDataLoading) || + (runeTxFeeCryptoBaseUnit === undefined && isEstimatedRuneFeesDataLoading) || isThorchainMimirTimesLoading
1169-1176: Do not set state during render; move resets/population into effects.Calling handleAddLiquidityInputChange inside render (within map) can trigger state updates during render, causing warnings or render loops.
Apply this diff to remove render-time state updates:
- // Reset inputs on asset change - if (assetId !== previousAssetId) { - handleAddLiquidityInputChange('', false) - } - - // Set amount required for completion of the incomplete sym position - if (position?.status.incomplete?.asset.assetId === asset.assetId) { - handleAddLiquidityInputChange(position.status.incomplete.amountCryptoPrecision, false) - }Then add these effects elsewhere in the component to preserve intent:
// Reset both sides on pool asset change useEffect(() => { if (!assetId || assetId === previousOpportunityId?.split(':')[0]) return setVirtualAssetDepositAmountCryptoPrecision('0') setVirtualAssetDepositAmountFiatUserCurrency('0') setVirtualRuneDepositAmountCryptoPrecision('0') setVirtualRuneDepositAmountFiatUserCurrency('0') }, [assetId, previousOpportunityId]) // Pre-populate incomplete side amount useEffect(() => { const incomplete = position?.status.incomplete if (!incomplete) return const isRune = incomplete.asset.assetId === thorchainAssetId const marketData = isRune ? runeMarketData : poolAssetMarketData const onChange = createHandleAddLiquidityInputChange(marketData, isRune) onChange(incomplete.amountCryptoPrecision, false) // eslint-disable-next-line react-hooks/exhaustive-deps }, [position?.status.incomplete, createHandleAddLiquidityInputChange, runeMarketData, poolAssetMarketData])
487-492: onToggleIsFiat ignores the requested state; align local state to the caller’s value.The handler receives the desired isFiat but always toggles, which can desync state if the caller sets a specific value.
Apply this diff (toggle only when needed):
- const handleToggleIsFiat = useCallback( - (_isFiat: boolean) => { - toggleIsFiat() - }, - [toggleIsFiat], - ) + const handleToggleIsFiat = useCallback( + (_isFiat: boolean) => { + // Only toggle if the desired state differs from current + if (_isFiat !== isFiat) toggleIsFiat() + }, + [isFiat, toggleIsFiat], + )
423-425: Nit: Fix “Markt” typo in variable name for clarity and consistency.Rename poolAssetFeeAssetMarktData → poolAssetFeeAssetMarketData.
Apply these diffs:
- const poolAssetFeeAssetMarktData = useAppSelector(state => + const poolAssetFeeAssetMarketData = useAppSelector(state => selectMarketDataByAssetIdUserCurrency(state, poolAssetFeeAsset?.assetId ?? ''), )- () => - bnOrZero(poolAssetTxFeeCryptoPrecision).times(bnOrZero(poolAssetFeeAssetMarktData?.price)), - [poolAssetFeeAssetMarktData?.price, poolAssetTxFeeCryptoPrecision], + () => + bnOrZero(poolAssetTxFeeCryptoPrecision).times(bnOrZero(poolAssetFeeAssetMarketData?.price)), + [poolAssetFeeAssetMarketData?.price, poolAssetTxFeeCryptoPrecision],Also applies to: 903-906
195-201: Typos in comments (“symetrically”, “sym.”) — minor readability nit.Consider correcting to “symmetrically” and “asymmetrically”; expand “sym.” to “symmetric”.
packages/contracts/src/ethersProviderSingleton.ts (3)
36-41: Use structured errors from @shapeshiftoss/errors (optional now, aligns with guidelines)Throwing plain Error loses error codes and context for i18n/logging. Prefer a custom error class with an explicit code (e.g., RPC_URL_NOT_CONFIGURED) and structured details like { chainId }.
54-61: Minor: simplify control flow and remove informal commentPrefer early return over else, and remove the "mang..." comment.
Apply:
if (!ethersProviders.has(chainId)) { const provider = new JsonRpcProvider(rpcUrlByChainId(chainId), undefined, { staticNetwork: true, }) ethersProviders.set(chainId, provider) - return provider - } else { - // This really should be defined but I guess enough safety never hurts mang... - const provider = ethersProviders.get(chainId) - if (!provider) { - throw new Error(`No provider found for chainId ${chainId}`) - } - - return provider - } + return provider + } + const provider = ethersProviders.get(chainId) + if (!provider) throw new Error(`No provider found for chainId ${chainId}`) + return providerif (!ethersV5Providers.has(chainId)) { const provider = new ethersV5.providers.StaticJsonRpcProvider(rpcUrlByChainId(chainId)) ethersV5Providers.set(chainId, provider) - return provider - } else { - // This really should be defined but I guess enough safety never hurts mang... - const provider = ethersV5Providers.get(chainId) - if (!provider) { - throw new Error(`No provider found for chainId ${chainId}`) - } - return provider - } + return provider + } + const provider = ethersV5Providers.get(chainId) + if (!provider) throw new Error(`No provider found for chainId ${chainId}`) + return providerAlso applies to: 72-79
1-81: File naming styleRepository guidelines prefer kebab-case. Consider renaming ethersProviderSingleton.ts to ethers-provider-singleton.ts in a follow-up to maintain consistency.
packages/contracts/src/viemClient.ts (1)
1-116: File naming styleConsider renaming viemClient.ts to viem-client.ts for consistency with kebab-case file naming.
♻️ Duplicate comments (2)
packages/contracts/src/env.esm.ts (1)
1-12: Duplicate ESM mapping and missing routing guarantees to CJS counterpart.This file mirrors env.ts (also ESM). Without proper routing, CJS consumers may still import an ESM-only env module. See the critical note on env.ts for the required export routing (conditional subpath exports and/or TS paths). Also consider adding explicit typing for ENV for clarity.
Add a shared type and type the constant:
-// ESM environment file - uses import.meta.env for Vite/browser environments -export const ENV = { +// ESM environment file - uses import.meta.env for Vite/browser environments +export interface EnvConfig { + VITE_AVALANCHE_NODE_URL?: string + VITE_OPTIMISM_NODE_URL?: string + VITE_BNBSMARTCHAIN_NODE_URL?: string + VITE_POLYGON_NODE_URL?: string + VITE_GNOSIS_NODE_URL?: string + VITE_ETHEREUM_NODE_URL?: string + VITE_ARBITRUM_NODE_URL?: string + VITE_ARBITRUM_NOVA_NODE_URL?: string + VITE_BASE_NODE_URL?: string +} +export const ENV: Readonly<EnvConfig> = { VITE_AVALANCHE_NODE_URL: import.meta.env.VITE_AVALANCHE_NODE_URL, VITE_OPTIMISM_NODE_URL: import.meta.env.VITE_OPTIMISM_NODE_URL, VITE_BNBSMARTCHAIN_NODE_URL: import.meta.env.VITE_BNBSMARTCHAIN_NODE_URL, VITE_POLYGON_NODE_URL: import.meta.env.VITE_POLYGON_NODE_URL, VITE_GNOSIS_NODE_URL: import.meta.env.VITE_GNOSIS_NODE_URL, VITE_ETHEREUM_NODE_URL: import.meta.env.VITE_ETHEREUM_NODE_URL, VITE_ARBITRUM_NODE_URL: import.meta.env.VITE_ARBITRUM_NODE_URL, VITE_ARBITRUM_NOVA_NODE_URL: import.meta.env.VITE_ARBITRUM_NOVA_NODE_URL, VITE_BASE_NODE_URL: import.meta.env.VITE_BASE_NODE_URL, }See env.ts comment for routing details.
packages/contracts/src/viemClient.ts (1)
18-18: Same ENV module selection risk as in ethersProviderSingleton.tsThe './env' import needs the same path remap or conditional subpath export to bind env.esm.ts (ESM) vs env.cjs.ts (CJS).
See the remediation steps proposed for packages/contracts/src/ethersProviderSingleton.ts (Line 8).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (8)
packages/caip/src/adapters/coincap/generated/eip155_1/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_1/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_10/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_42161/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_43114/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_56/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/eip155_8453/adapter.jsonis excluded by!**/generated/**packages/caip/src/adapters/coingecko/generated/solana_5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/adapter.jsonis excluded by!**/generated/**
📒 Files selected for processing (36)
.gitignore(1 hunks)package.json(1 hunks)packages/caip/package.json(1 hunks)packages/caip/tsconfig.cjs.json(1 hunks)packages/caip/tsconfig.json(1 hunks)packages/chain-adapters/package.json(1 hunks)packages/chain-adapters/tsconfig.cjs.json(1 hunks)packages/chain-adapters/tsconfig.json(1 hunks)packages/contracts/package.json(1 hunks)packages/contracts/src/env.cjs.ts(1 hunks)packages/contracts/src/env.esm.ts(1 hunks)packages/contracts/src/env.ts(1 hunks)packages/contracts/src/ethersProviderSingleton.ts(1 hunks)packages/contracts/src/viemClient.ts(1 hunks)packages/contracts/tsconfig.cjs.json(1 hunks)packages/contracts/tsconfig.json(1 hunks)packages/errors/package.json(1 hunks)packages/errors/tsconfig.cjs.json(1 hunks)packages/errors/tsconfig.json(1 hunks)packages/swapper/package.json(1 hunks)packages/swapper/tsconfig.cjs.json(1 hunks)packages/swapper/tsconfig.json(1 hunks)packages/types/package.json(1 hunks)packages/types/tsconfig.cjs.json(1 hunks)packages/types/tsconfig.json(1 hunks)packages/unchained-client/package.json(1 hunks)packages/unchained-client/tsconfig.cjs.json(1 hunks)packages/unchained-client/tsconfig.json(1 hunks)packages/utils/package.json(1 hunks)packages/utils/tsconfig.cjs.json(1 hunks)packages/utils/tsconfig.json(1 hunks)scripts/generateAssetData/color-map.json(25 hunks)src/lib/asset-service/service/encodedRelatedAssetIndex.json(1 hunks)src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx(1 hunks)src/state/migrations/index.ts(1 hunks)tsconfig.packages.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*
📄 CodeRabbit inference engine (.cursor/rules/naming-conventions.mdc)
**/*: ALWAYS use appropriate file extensions
Flag files without kebab-case
Files:
packages/types/tsconfig.cjs.jsonpackages/errors/tsconfig.cjs.jsonpackages/errors/tsconfig.jsonpackages/utils/tsconfig.jsonpackages/swapper/tsconfig.jsonpackages/caip/tsconfig.jsonpackages/chain-adapters/tsconfig.cjs.jsonpackages/contracts/tsconfig.cjs.jsonpackages/chain-adapters/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/unchained-client/tsconfig.cjs.jsonpackages/contracts/src/env.cjs.tspackages/contracts/src/env.tspackage.jsontsconfig.packages.jsonpackages/contracts/src/viemClient.tspackages/contracts/src/ethersProviderSingleton.tspackages/caip/tsconfig.cjs.jsonsrc/state/migrations/index.tspackages/contracts/src/env.esm.tspackages/contracts/tsconfig.jsonpackages/utils/package.jsonpackages/errors/package.jsonpackages/utils/tsconfig.cjs.jsonpackages/swapper/package.jsonpackages/types/tsconfig.jsonpackages/types/package.jsonpackages/chain-adapters/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsxpackages/caip/package.jsonpackages/unchained-client/tsconfig.jsonpackages/unchained-client/package.jsonpackages/contracts/package.jsonsrc/lib/asset-service/service/encodedRelatedAssetIndex.jsonscripts/generateAssetData/color-map.json
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)
**/*.{ts,tsx}: ALWAYS use Result<T, E> pattern for error handling in swappers and APIs
ALWAYS use Ok() and Err() from @sniptt/monads for monadic error handling
ALWAYS use custom error classes from @shapeshiftoss/errors
ALWAYS provide meaningful error codes for internationalization
ALWAYS include relevant details in error objects
ALWAYS wrap async operations in try-catch blocks
ALWAYS use AsyncResultOf utility for converting promises to Results
ALWAYS provide fallback error handling
ALWAYS use timeoutMonadic for API calls
ALWAYS provide appropriate timeout values for API calls
ALWAYS handle timeout errors gracefully
ALWAYS validate inputs before processing
ALWAYS provide clear validation error messages
ALWAYS use early returns for validation failures
ALWAYS log errors for debugging
ALWAYS use structured logging for errors
ALWAYS include relevant context in error logs
Throwing errors instead of using monadic patterns is an anti-pattern
Missing try-catch blocks for async operations is an anti-pattern
Generic error messages without context are an anti-pattern
Not handling specific error types is an anti-pattern
Missing timeout handling is an anti-pattern
No input validation is an anti-pattern
Poor error logging is an anti-pattern
Using any for error types is an anti-pattern
Missing error codes for internationalization is an anti-pattern
No fallback error handling is an anti-pattern
Console.error without structured logging is an anti-pattern
**/*.{ts,tsx}: ALWAYS use camelCase for variables, functions, and methods
ALWAYS use descriptive names that explain the purpose for variables and functions
ALWAYS use verb prefixes for functions that perform actions
ALWAYS use PascalCase for types, interfaces, and enums
ALWAYS use descriptive names that indicate the structure for types, interfaces, and enums
ALWAYS use suffixes like Props, State, Config, Type when appropriate for types and interfaces
ALWAYS use UPPER_SNAKE_CASE for constants and configuration values
ALWAYS use d...
Files:
packages/contracts/src/env.cjs.tspackages/contracts/src/env.tspackages/contracts/src/viemClient.tspackages/contracts/src/ethersProviderSingleton.tssrc/state/migrations/index.tspackages/contracts/src/env.esm.tssrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)
USE Redux only for global state shared across multiple places
Files:
packages/contracts/src/env.cjs.tspackages/contracts/src/env.tspackages/contracts/src/viemClient.tspackages/contracts/src/ethersProviderSingleton.tssrc/state/migrations/index.tspackages/contracts/src/env.esm.tssrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)
**/*.tsx: ALWAYS wrap components in error boundaries
ALWAYS provide user-friendly fallback components in error boundaries
ALWAYS log errors for debugging in error boundaries
ALWAYS use useErrorToast hook for displaying errors
ALWAYS provide translated error messages in error toasts
ALWAYS handle different error types appropriately in error toasts
Missing error boundaries in React components is an anti-pattern
**/*.tsx: ALWAYS use PascalCase for React component names
ALWAYS use descriptive names that indicate the component's purpose
ALWAYS match the component name to the file name
Flag components without PascalCase
Flag default exports for components
Files:
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
**/*.{tsx,jsx}
📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)
**/*.{tsx,jsx}: ALWAYS useuseMemofor expensive computations, object/array creations, and filtered data
ALWAYS useuseMemofor derived values and computed properties
ALWAYS useuseMemofor conditional values and simple transformations
ALWAYS useuseCallbackfor event handlers and functions passed as props
ALWAYS useuseCallbackfor any function that could be passed as a prop or dependency
ALWAYS include all dependencies inuseEffect,useMemo,useCallbackdependency arrays
NEVER use// eslint-disable-next-line react-hooks/exhaustive-depsunless absolutely necessary
ALWAYS explain why dependencies are excluded if using eslint disable
ALWAYS use named exports for components
NEVER use default exports for components
KEEP component files under 200 lines when possible
BREAK DOWN large components into smaller, reusable pieces
EXTRACT complex logic into custom hooks
USE local state for component-level state
LIFT state up when needed across multiple components
USE Context for avoiding prop drilling
ALWAYS wrap components in error boundaries for production
ALWAYS handle async errors properly
ALWAYS provide user-friendly error messages
ALWAYS use virtualization for lists with 100+ items
ALWAYS implement proper key props for list items
ALWAYS lazy load heavy components
ALWAYS use React.lazy for code splitting
Components receiving props are wrapped withmemo
Files:
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
🧠 Learnings (21)
📚 Learning: 2025-08-03T22:09:37.542Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/error-handling.mdc:0-0
Timestamp: 2025-08-03T22:09:37.542Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS include relevant details in error objects
Applied to files:
packages/errors/tsconfig.cjs.json
📚 Learning: 2025-08-03T22:10:38.426Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/react-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:10:38.426Z
Learning: Applies to **/*.{ts,tsx} : Missing TypeScript types
Applied to files:
packages/errors/tsconfig.cjs.json
📚 Learning: 2025-08-03T22:10:11.424Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/naming-conventions.mdc:0-0
Timestamp: 2025-08-03T22:10:11.424Z
Learning: Applies to **/*.{ts,tsx} : Flag renamed imports without good reason
Applied to files:
packages/utils/tsconfig.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Avoid side effects in swap logic within swapper implementation files.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/{constants,types}.ts : Register new swappers in packages/swapper/src/constants.ts and add them to the SwapperName enum in packages/swapper/src/types.ts.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/**/*.ts : Use camelCase for variables and functions, PascalCase for types and interfaces, and kebab-case for filenames in swapper-related files.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/**/*.ts : Use TypeScript with explicit types (e.g., SupportedChainIds) in all swapper-related files.
Applied to files:
packages/swapper/tsconfig.jsonpackages/chain-adapters/tsconfig.cjs.jsonpackages/chain-adapters/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsxpackages/unchained-client/tsconfig.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/index.ts : Export unique functions/types from packages/swapper/src/index.ts if needed.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,utils/*.ts} : Each swapper must be implemented in its own directory under packages/swapper/src/swappers/<SwapperName>/ with the following files: <SwapperName>.ts, endpoints.ts, utils/constants.ts, utils/helpers.ts, types.ts.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Include comments explaining swap logic in swapper implementation files.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : All swappers must conform to the Swapper and SwapperApi interfaces defined in packages/swapper/src/types.ts.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.json
📚 Learning: 2025-08-03T22:09:37.542Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/error-handling.mdc:0-0
Timestamp: 2025-08-03T22:09:37.542Z
Learning: Applies to **/swapper/**/*.{ts,tsx} : ALWAYS provide detailed error information in swapper errors
Applied to files:
packages/swapper/tsconfig.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/**/*.@(test|spec).ts : Write unit tests for swapper methods and API endpoints.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.jsonpackages/swapper/package.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Leverage shared utilities (e.g., executeEvmTransaction, checkEvmSwapStatus) in swapper implementations when applicable.
Applied to files:
packages/swapper/tsconfig.cjs.jsonpackages/swapper/package.jsonsrc/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-08-08T20:16:12.898Z
Learnt from: gomesalexandre
PR: shapeshift/web#10222
File: package.json:202-202
Timestamp: 2025-08-08T20:16:12.898Z
Learning: In shapeshift/web, the semver package must be included in dependencies (not devDependencies) because hdwallet packages have transient dependencies that require semver but don't ship it themselves. This ensures semver is available at runtime for hdwallet functionality.
Applied to files:
packages/utils/package.jsonpackages/errors/package.jsonpackages/types/package.jsonpackages/contracts/package.json
📚 Learning: 2025-08-03T22:09:37.542Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/error-handling.mdc:0-0
Timestamp: 2025-08-03T22:09:37.542Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS use custom error classes from shapeshiftoss/errors
Applied to files:
packages/errors/package.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/constants.ts : Prevent unregistered swappers in the registry (i.e., all swappers must be registered in packages/swapper/src/constants.ts).
Applied to files:
packages/swapper/package.json
📚 Learning: 2025-08-08T20:27:02.203Z
Learnt from: gomesalexandre
PR: shapeshift/web#10222
File: package.json:202-202
Timestamp: 2025-08-08T20:27:02.203Z
Learning: In shapeshift/web, while gomesalexandre generally prefers pinned dependencies for security, semver with a caret range (^7.7.2) is acceptable as an exception since it's already a transient dependency of many packages and is being made explicit for hdwallet support.
Applied to files:
packages/types/package.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Verify chain ID filtering in filterAssetIdsBySellable and filterBuyAssetsBySellAssetId methods.
Applied to files:
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-08-14T17:54:32.563Z
Learnt from: gomesalexandre
PR: shapeshift/web#10276
File: src/pages/ThorChainLP/components/ReusableLpStatus/ReusableLpStatus.tsx:97-108
Timestamp: 2025-08-14T17:54:32.563Z
Learning: In ReusableLpStatus component (src/pages/ThorChainLP/components/ReusableLpStatus/ReusableLpStatus.tsx), the txAssets dependency is stable from first render because poolAsset, baseAsset, actionSide, and action are all defined first render, making the current txAssetsStatuses initialization pattern safe without needing useEffect synchronization.
Applied to files:
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
📚 Learning: 2025-08-05T23:36:13.214Z
Learnt from: premiumjibles
PR: shapeshift/web#10187
File: src/state/slices/preferencesSlice/selectors.ts:21-25
Timestamp: 2025-08-05T23:36:13.214Z
Learning: The AssetId type from 'shapeshiftoss/caip' package is a string type alias, so it can be used directly as a return type for cache key resolvers in re-reselect selectors without needing explicit string conversion.
Applied to files:
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx
🧬 Code graph analysis (6)
packages/contracts/src/env.cjs.ts (2)
packages/contracts/src/env.esm.ts (1)
ENV(2-12)packages/contracts/src/env.ts (1)
ENV(2-12)
packages/contracts/src/env.ts (2)
packages/contracts/src/env.cjs.ts (1)
ENV(2-12)packages/contracts/src/env.esm.ts (1)
ENV(2-12)
packages/contracts/src/viemClient.ts (3)
packages/contracts/src/env.cjs.ts (1)
ENV(2-12)packages/contracts/src/env.esm.ts (1)
ENV(2-12)packages/contracts/src/env.ts (1)
ENV(2-12)
packages/contracts/src/ethersProviderSingleton.ts (4)
packages/types/src/base.ts (1)
EvmChainId(36-45)packages/contracts/src/env.cjs.ts (1)
ENV(2-12)packages/contracts/src/env.esm.ts (1)
ENV(2-12)packages/contracts/src/env.ts (1)
ENV(2-12)
src/state/migrations/index.ts (1)
src/state/migrations/clearAssets.ts (1)
clearAssets(6-8)
packages/contracts/src/env.esm.ts (2)
packages/contracts/src/env.cjs.ts (1)
ENV(2-12)packages/contracts/src/env.ts (1)
ENV(2-12)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Install and Cache
🔇 Additional comments (68)
src/state/migrations/index.ts (1)
210-211: Assets migration configuration is correct; no manual bump neededVerified that:
clearAssetsMigrationsalready includes the167: clearAssetsentry.- In
src/state/reducer.ts,assetsPersistConfig.versionis set viaMath.max(...Object.keys(clearAssetsMigrations).map(Number)), which evaluates to 167.assetsPersistConfig.migrateis wired tocreateMigrate(clearAssetsMigrations, { debug: false }).As a result, the new migration will run automatically without requiring an explicit hardcoded bump. You can safely ignore the previous suggestion.
Likely an incorrect or invalid review comment.
src/pages/ThorChainLP/components/AddLiquidity/AddLiquidityInput.tsx (1)
30-33: Exports Verified: Top-Level Swapper API Is Correct
SwapperName
– Re-exported at the top level via
packages/swapper/src/index.ts →export * from './types'
(types.ts defines and exports SwapperName)assetIdToThorPoolAssetId & thorPoolAssetIdToAssetId
– Implementations live in
packages/swapper/src/swappers/ThorchainSwapper/utils/poolAssetHelpers/poolAssetHelpers.ts
– Re-exported by
packages/swapper/src/swappers/ThorchainSwapper/index.ts →export * from './utils/poolAssetHelpers/poolAssetHelpers'
– Bubbled up by
packages/swapper/src/index.ts →export * from './swappers/ThorchainSwapper'CJS / ESM Surface
– package.json “exports” map includes:".": { "import": "./dist/esm/index.js", "require": "./dist/cjs/index.js", "types": "./dist/esm/index.d.ts" }– Ensure your CI build step emits dist/esm and dist/cjs with an index.js in each.
All requested symbols are publicly available in both ESM and CJS entry points.
packages/chain-adapters/tsconfig.json (1)
5-7: ESM outDir and separate tsBuildInfo file look good; keep configs consistent across packages.This mirrors the pattern elsewhere and should avoid artifact collisions. Ensure the CJS config mirrors the ESM tsBuildInfo separation and disables declaration emission to prevent duplicated .d.ts in dist/cjs.
packages/errors/tsconfig.json (1)
3-9: Declaration Emit Confirmed
Thepackages/errors/tsconfig.jsonfile extendstsconfig.packages.json, which already has"declaration": trueset in itscompilerOptions. Therefore, declaration files will be emitted for this package as expected, and no changes are needed here.packages/errors/tsconfig.cjs.json (1)
11-12: Summary vs code mismatch: JSON files not included hereAI summary says this config includes
"src/**/*.json", but the actual include only lists"src/**/*". If JSON imports are used and your TS settings require explicit pattern, consider adding it; otherwise update the summary.If needed:
- "include": ["src/**/*"], + "include": ["src/**/*", "src/**/*.json"],packages/unchained-client/tsconfig.json (1)
26-29: References and declaration settings are correctly inherited and build order aligns—no changes needed
- Both packages/caip and packages/contracts tsconfig.json files extend tsconfig.packages.json, which has
declaration: true, so they emit declaration files as required.- The composite build pipeline (
build:packages:sequential) builds @shapeshiftoss/caip and @shapeshiftoss/contracts before @shapeshiftoss/unchained-client, matching the project reference order.- No explicit
declarationfields are needed in each package’s tsconfig because they inherit from the root config, and the current setup satisfies TypeScript’s project reference requirements.packages/unchained-client/tsconfig.cjs.json (1)
12-18: References look good; confirm they match ESM configReferences mirror the ESM config and will ensure correct build ordering under
tsc -b. LGTM.packages/errors/package.json (1)
23-26: Build/clean scripts align with dual-output strategy.build runs both tsconfig.json and tsconfig.cjs.json, build:cjs is available for targeted calls, and clean avoids deleting tsbuildinfo artifacts now stored under dist. This is consistent with the repo-wide approach.
packages/unchained-client/package.json (3)
16-18: Publishing artifacts: ensure new auxiliary files are included.If you adopt the nested
dist/esm/package.jsonapproach (Option A above),"files": ["dist"]will include it—good. If you later emit.mapfiles or sidecar metadata (e.g.,*.mjs,*.cjs), keep"files"as["dist"]to avoid publishing generator sources.
3-3: Version bump looks fine; confirm semver intent.Changing entry points and adding an
exportsmap can be observable by consumers. If any breaking deep imports are removed, consider a minor vs. patch bump per your semver policy. As written, this is a patch bump to 10.14.4.
9-15: No deep imports detected – exports map is safe to mergeI searched all TypeScript and JavaScript files (excluding dist, build, and node_modules) for any imports of the form
@shapeshiftoss/unchained-client/<subpath>and found none. This confirms that no consumers within the repo rely on private subpaths, so adding the"exports"field will not break existing imports.scripts/generateAssetData/color-map.json (25)
633-633: New mapping looks consistent.Address/network format and 6-digit hex color are correct. Covered by the global validation script above.
1265-1265: New mapping looks consistent.No issues spotted; formatting aligns with existing entries.
1347-1347: New mapping looks consistent.Entry conforms to eip155:1/erc20 key and #RRGGBB value.
2915-2915: New mapping looks consistent.No concerns; value uses a valid hex color.
4777-4777: New mapping looks consistent.Lowercase address, correct chain prefix, and valid color.
5217-5217: New mapping looks consistent.Formatting and value shape are OK.
5671-5671: New mapping looks consistent.Hex color and key pattern look correct.
7599-7599: Cross-network reuse noted; verify no accidental duplicate keys within same network block.This address appears in Arbitrum (42161). Cross-network reuse is fine. Please rely on the validation script to ensure there are no exact duplicate keys within the same chain/spec elsewhere in the file.
7629-7629: New mapping looks consistent.All formats check out.
7799-7799: New mapping looks consistent.Conforms to conventions.
7923-7923: New mapping looks consistent.No issues spotted.
7935-7935: New mapping looks consistent.Formatting/value shape are OK.
7950-7950: New mapping looks consistent.Correct key/value formats.
10245-10245: New mapping looks consistent.BEP20 entry follows the same schema.
11695-11695: New mapping looks consistent.No deviations from established format.
12092-12092: New mapping looks consistent.Correct hex color; no issues.
12514-12514: Potential duplication risk in Base (8453) block — please confirm uniqueness.AI summary alluded to duplicates in 8453; ensure this key doesn’t exist elsewhere in the 8453/erc20 section with a different color. Run the validator script to surface exact duplicates.
12959-12959: New mapping looks consistent.No issues spotted.
13020-13020: New mapping looks consistent.Formatting/value OK.
13047-13047: Potential duplication risk in Base (8453) block — please confirm uniqueness.See earlier note for Base network; validate there’s no second occurrence of this exact key.
13339-13339: Potential duplication risk in Base (8453) block — please confirm uniqueness.Run the validator to ensure no exact duplicate key exists elsewhere in 8453 for this address.
13393-13393: New mapping looks consistent.Key/value conform to schema.
13799-13799: New mapping looks consistent.Formatting/value shape OK.
13904-13904: New mapping looks consistent.No issues spotted.
537-537: Update validation script to support chain‐level entries & enforce uppercase hexThe data changes themselves look good, but running the validator surfaced two issues:
- Key‐format mismatches – our current regex only allows ERC20/BEP20 token keys (
eip155:<chain>/erc20|bep20:0x…), yetcolor-map.jsonalso contains chain-level entries (slip44, bip122, cosmos).- Lowercase hex digits – a couple of color values use lowercase letters, which we flag as style nits.
Please make the following updates and re-run the validator to confirm a clean pass:
• Revise the
key_fullregex to match both token and chain entries. For example:- key_full = re.compile(r'^eip155:\d+/(?:erc20|bep20):0x[0-9a-f]{40}$') + key_full = re.compile( + r'^(?:' + r'(?:eip155:\d+/(?:erc20|bep20):0x[0-9a-f]{40})|' # token keys + r'(?:[^:]+:[^/]+/slip44:\d+)' # chain entries (slip44, bip122, cosmos) + r')$' + )• Normalize the two lowercase hex values to uppercase:
- eip155:100/slip44:60: change
#33765c→#33765C- eip155:137/slip44:60: change
#8f00ff→#8F00FFOnce these patches are applied, rerun the provided script to verify there are no remaining format errors or style nits.
⛔ Skipped due to learnings
Learnt from: 0xApotheosis PR: shapeshift/web#10290 File: scripts/generateAssetData/color-map.json:41-47 Timestamp: 2025-08-17T21:53:03.806Z Learning: In the ShapeShift web codebase, native assets (using CAIP-19 slip44 namespace like eip155:1/slip44:60, bip122:.../slip44:..., cosmos:.../slip44:...) are manually hardcoded and not generated via the automated asset generation script. Only ERC20/BEP20 tokens go through the asset generation process. The validation scripts should only validate generated assets, not manually added native assets.packages/utils/tsconfig.json (1)
5-6: ESM outDir and separate tsbuildinfo look goodMoving ESM output to dist/esm and isolating the incremental build file reduces crosstalk with the CJS build. No issues spotted.
packages/contracts/src/ethersProviderSingleton.ts (1)
8-9: I’d like to confirm whetherenv.tsactually uses ESM-only APIs (e.g.import.meta.env) before finalizing recommendations.Please run:
#!/bin/bash set -euo pipefail echo "🔍 Check for import.meta.env in env.ts" grep -n "import\\.meta\\.env" packages/contracts/src/env.ts || true echo echo "📋 Show top of env.ts" sed -n '1,200p' packages/contracts/src/env.tsThis will verify if CJS builds will indeed break at runtime.
packages/contracts/src/viemClient.ts (1)
23-24: No action needed—chain-default RPC URLs already included in all fallback transportsI’ve verified that every
transport: fallbackcall inpackages/contracts/src/viemClient.tsnow prepends the chain’s.rpcUrls.default.http, so there are no empty-fallback sites remaining. The proposed changes have already been applied.packages/utils/tsconfig.cjs.json (2)
1-17: CJS tsconfig is consistent and scoped to dist/cjsModule, resolution, outDir, and separate tsbuildinfo are set correctly for CJS builds. References to caip and types look right.
4-6: moduleResolution override is consistentThe root
tsconfig.json(line 19) and the extendedtsconfig.packages.jsonboth specify"moduleResolution": "node"so the override in
packages/utils/tsconfig.cjs.json(lines 4–6) is in line with the base configuration.If your project targets modern Node ESM semantics (Node 18/20), you may instead want to:
- Update the base
tsconfig.jsontoor"moduleResolution": "node16""moduleResolution": "nodenext"- Remove or adjust the local override in
packages/utils/tsconfig.cjs.jsonOtherwise, no changes are needed here.
packages/swapper/tsconfig.json (2)
5-6: ESM dist/esm and separate tsbuildinfo are aligned with dual-build strategyChange is consistent with the repo-wide CJS/ESM split.
5-7: ✅ Verified Swapper package.json exports and publish configurationThe
packages/swapper/package.jsonhas been confirmed to correctly point to the newdist/esmanddist/cjsoutputs:
main→dist/cjs/index.jsmodule→dist/esm/index.jstypes→dist/esm/index.d.tsexportsmappings for both.and./constantsalign with these directoriesThe
filesarray only includes"dist", and no*.tsbuildinfofiles are present, ensuring build info files are excluded from the published package. No further changes are required.packages/swapper/tsconfig.cjs.json (2)
1-19: CJS config structure looks correct and consistent with dual-build strategy.Extends package tsconfig, targets CommonJS, separates outDir to dist/cjs, and adds project references. Good baseline.
11-12: resolveJsonModule is already enabled in your base configVerified that your root tsconfig.json explicitly sets
"compilerOptions": { "resolveJsonModule": true, … }and this setting is inherited by tsconfig.packages.json, packages/swapper/tsconfig.json, and packages/swapper/tsconfig.cjs.json. No further changes are needed.
packages/chain-adapters/tsconfig.cjs.json (1)
1-19: CJS tsconfig is aligned with the pattern; references look appropriate.Extends base config, dist/cjs outDir, and includes references to caip/types/unchained-client/utils. Looks coherent with composite builds.
packages/types/tsconfig.cjs.json (2)
1-16: Baseline CJS config looks fine; references to caip are correct.ESM/CJS split and composite reference to caip are consistent.
11-12: No JSON files or imports detected—include pattern is appropriateI ran searches for any “.json” references and JSON files under
packages/types/srcand found none. Since this package contains only TypeScript definitions, omitting JSON from the"include"glob is intentional and safe. Leave theinclude: ["src/**/*"]as is.packages/caip/tsconfig.cjs.json (2)
1-13: Good CJS setup for caip.Matches monorepo pattern with dist/cjs output and JSON inclusion.
3-10: Modernize resolution and avoid duplicate type emissionPlease apply the same optional refactor as in our other packages to your CommonJS build config and then verify that your ESM build is the sole source of declarations.
• File:
packages/caip/tsconfig.cjs.json"compilerOptions": { "module": "CommonJS", - "moduleResolution": "node", + "moduleResolution": "node16", "rootDir": "src", "outDir": "dist/cjs", - "tsBuildInfoFile": "dist/tsconfig.cjs.tsbuildinfo", - "noEmit": false + "tsBuildInfoFile": ".tsbuildinfo/tsconfig.cjs.tsbuildinfo", + "noEmit": false, + "declaration": false, + "emitDeclarationOnly": false },• Next steps:
I did not find anydeclaration,emitDeclarationOnly, ordeclarationDirsettings in your ESM config atpackages/caip/tsconfig.json. If the ESM build is intended to be the single source of type declarations, please verify (or add) the following in that file to prevent overlapping outputs:{ "compilerOptions": { // ... "declaration": true, "emitDeclarationOnly": true, "declarationDir": "dist/types" } }packages/contracts/tsconfig.cjs.json (3)
1-18: Overall CJS config looks good; env.esm.ts exclusion is a sensible guard.Excluding src/env.esm.ts for the CJS build avoids mixing ESM-only code paths. Nice catch.
12-12: Ensure a CJS-compatibleenventry is in place
tsconfig.cjs.jsonis excludingsrc/env.esm.ts, but I didn’t locate a corresponding CJS-safe file or an isomorphic fallback in the contracts package. Please verify that:
- A dedicated CJS env file (for example,
packages/contracts/src/env.cjs.tsor a universalenv.ts) exists alongside the ESM version.- Your package’s
exports(inpackage.json) uses conditional exports so that “import” consumers getenv.esm.tsand “require” consumers get the CJS variant.- All import paths within
packages/contractsunder the CJS build resolve to the CJS-safe entry (not the excludedenv.esm.ts).If no CJS env file is present, either add one or add a conditional export mapping in
package.jsonto ensurerequire("contracts/env")resolves correctly.
13-17: Current project references correctly cover all internal dependenciesA scan of packages/contracts/src reveals imports only from:
- @shapeshiftoss/caip
- @shapeshiftoss/types
- @shapeshiftoss/utils
and packages/contracts/tsconfig.cjs.json references exactly those three projects. There are no imports from @shapeshiftoss/unchained-client, so no additional reference is needed.
Likely an incorrect or invalid review comment.
packages/caip/package.json (2)
7-16: LGTM! Proper dual ESM/CJS build configuration.The dual build setup correctly configures both CommonJS and ESModule outputs with proper entry points and exports mapping. The configuration follows Node.js package.json conventions for dual packaging.
24-26: Build script correctly implements dual TypeScript compilation.The build process properly sequences the TypeScript compilations for both ESM and CJS targets. The separate
build:cjsscript provides flexibility for CJS-only builds when needed.packages/types/package.json (2)
7-16: Consistent dual build configuration applied correctly.The package.json changes mirror the same dual ESM/CJS pattern implemented across other packages in this PR, maintaining consistency in the monorepo's build strategy.
24-26: Build pipeline properly configured for dual compilation.The build scripts correctly implement the dual TypeScript compilation workflow, ensuring both ESM and CJS outputs are generated consistently.
packages/contracts/package.json (2)
7-16: Dual build configuration implemented consistently.The package exports and entry points are properly configured for both ESM and CJS consumption, following the established pattern across the monorepo.
24-24: Build script file copying verification blocked by Yarn errorIt appears the
yarn buildstep is failing with an internal error (fastqueue concurrency must be greater than 1), so we couldn’t confirm whether the sequence ofcp src/env.*.ts src/env.tscorrectly resetsenv.tsat each compile stage. Please:
- Fix the Yarn environment so that
yarn clean && yarn buildcompletes without internal errors (e.g., upgrade Yarn, adjustfastqueuesettings, or clear the cache).- Once the build succeeds, re-run a simplified verification script to ensure no intermediate state remains and that
env.tsreflects the intended module at each stage:#!/bin/bash echo "Initial env files:" ls packages/contracts/src/env*.ts cd packages/contracts yarn clean yarn build || { echo "Build failed"; exit 1; } echo "Final env.ts content:" head -n 10 src/env.ts- Consider refactoring to avoid in-place swapping with
cp. For example:
• Use separateoutDirsettings in your TypeScript configs (e.g.tsconfig.esm.json→outDir: dist/esm,tsconfig.cjs.json→outDir: dist/cjs) and copy only once from the final build output.
• Leverage TypeScript project references to orchestrate ESM/CJS builds, then run a single atomic copy of the correctenv.tsafter both builds finish.packages/chain-adapters/package.json (2)
6-15: Package entry points configured correctly for dual builds.The main, module, types, and exports fields are properly set up to support both CommonJS and ESModule consumers. The configuration follows Node.js best practices for dual packaging.
23-25: Build workflow properly implements dual TypeScript compilation.The build script correctly sequences both TypeScript configurations, ensuring proper ESM and CJS output generation. The separate build:cjs script provides useful flexibility.
packages/swapper/package.json (4)
10-15: Root export mapping looks correct for dual ESM/CJS + types.
import→ ESM,require→ CJS, andtypes→ ESM .d.ts is consistent and should satisfy both bundlers and Node CJS consumers. No issues here.
16-21: Confirm the constants entry actually builds to both targets.Ensure
packages/swapper/src/constants.tscompiles to:
- dist/esm/constants.js + dist/esm/constants.d.ts
- dist/cjs/constants.js
If not, add it to the build or re-export from
src/index.tsand expose only the root.
3-3: Confirm versioning strategy (manual vs. automated release tooling).Bumping to
"version": "1.0.0"here may conflict with repo release automation (e.g., Changesets). Ensure this aligns with the workspace’s publish flow.
7-21: Verify deep imports before finalizing the exports mapI ran a project-wide search for any imports of the form
@shapeshiftoss/swapper/<subpath>and found no matches insrc/,packages/, or other source folders. This means, within this repo, you won’t break any internal deep imports by declaring only.and./constants.However, external consumers (other repos, applications, etc.) might be using deep imports today. Please:
- Confirm with the team or audit any downstream projects that they don’t import internal modules via paths like
import foo from '@shapeshiftoss/swapper/some/subpath'- If you discover any such usage, explicitly enumerate those subpaths under
"exports".- As a temporary safeguard, you can add a wildcard export for all JS/TS artifacts:
"exports": { ".": { "import": "./dist/esm/index.js", "require": "./dist/cjs/index.js", "types": "./dist/esm/index.d.ts" }, "./constants": { "import": "./dist/esm/constants.js", "require": "./dist/cjs/constants.js", "types": "./dist/esm/constants.d.ts" }, + "./*": { + "import": "./dist/esm/*.js", + "require": "./dist/cjs/*.js", + "types": "./dist/esm/*.d.ts" + } },Let me know what you find so we can lock down only the truly public API surface.
packages/utils/package.json (3)
7-16: LGTM on dual-target entry points.
main,module,types, and root export mapping are consistent and align with the PR objective to support CJS consumers (e.g., Nest).
3-3: Version bump acknowledged; ensure it aligns with the monorepo release process.Confirm this new patch version is driven by your release tooling (e.g., Changesets) to avoid conflicts during publish.
7-16: Restricting exports to root is safe—no internal deep imports detectedI ran broad searches for any
@shapeshiftoss/utils/<subpath>imports or requires (ES imports, CommonJSrequire, and any bare references) across the repo and found none. With only the root export in place, all existing internal usages will continue to work as before.• If you have external consumers that might rely on deep imports, consider adding explicit subpath entries or a wildcard export (e.g.,
"./*": { ... }") in a follow-up release.
• Otherwise, no changes are required here—merging as-is is fine.
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
vite.config.mts (1)
95-103: Add explicitNODE_ENVdefine and fix uncovered non-VITE env usageBefore rolling out the broad
process.env→import.meta.envmapping, we need to:
- Explicitly define
process.env.NODE_ENVso esbuild’s longest-key match picks that up for third-party libs.- Audit and correct any non-VITE env references that would otherwise be rewritten into undefined
import.meta.envlookups.Issues found:
• packages/caip/src/adapters/coincap/index.ts:7
const apiKey = process.env.COINCAP_API_KEY || ''This use of
process.env.COINCAP_API_KEYdoesn’t start withVITE_and will break once you apply the mapping.Proposed changes:
define: { ...Object.fromEntries( Object.entries(publicFilesEnvVars).map(([key, value]) => [`import.meta.env.${key}`, value]), ), ...Object.fromEntries( Object.entries(publicFilesEnvVars).map(([key, value]) => [`process.env.${key}`, value]), ), + 'process.env.NODE_ENV': JSON.stringify(mode), 'process.env': 'import.meta.env', },--- a/packages/caip/src/adapters/coincap/index.ts +++ b/packages/caip/src/adapters/coincap/index.ts @@ -4,7 +4,7 @@ import type { Adapter, AssetId } from '@chain-registry/types' -const apiKey = process.env.COINCAP_API_KEY || '' +const apiKey = import.meta.env.VITE_COINCAP_API_KEY || '' export const coincap: Adapter = { id: 'coincap',• Ensure
VITE_COINCAP_API_KEYis defined in yourpublicFilesEnvVars(or other env-loading mechanism).Re-run this check after making updates:
#!/usr/bin/env bash # No non-VITE env refs should remain in client code rg -nP --ignore-case --no-ignore-vcs \ '(?<![A-Za-z0-9_])process\.env\.(?!VITE_)' \ -g '*.ts' -g '*.tsx' -g '*.js' -g '*.jsx' \ src packages | sed 's/^/non-VITE env ref: /'
♻️ Duplicate comments (12)
packages/errors/package.json (1)
9-15: Optionally expose package.json via a subpath export for tooling compatibilitySome tooling attempts to import the package metadata. Not mandatory, but harmless and sometimes useful.
"exports": { ".": { "import": "./dist/esm/index.js", "require": "./dist/cjs/index.js", "types": "./dist/esm/index.d.ts" - } + }, + "./package.json": "./package.json" },packages/utils/package.json (2)
25-26: Clean should remove root tsconfig tsbuildinfo (solution builder artifact)
When using a solution tsconfig that references sub-projects, tsc emits a root tsconfig.tsbuildinfo alongside the package root unless configured otherwise. Remove it during clean for deterministic rebuilds.- "clean": "rm -rf dist", + "clean": "rm -rf dist tsconfig*.tsbuildinfo",
26-26: Dev watch: ensure CJS artifacts stay fresh during local dev
Watching only the root solution is usually fine, but to mirror CI behavior and avoid stale CJS in some editors/runners, you can explicitly watch both configs.- "dev": "yarn run -T tsc --build --watch" + "dev": "yarn run -T tsc --build tsconfig.json tsconfig.cjs.json --watch"packages/unchained-client/package.json (2)
9-15: Put "types" first in the export conditions (TS compatibility)
Reorder the conditions for best TS compatibility."exports": { ".": { - "import": "./dist/esm/index.js", - "require": "./dist/cjs/index.js", - "types": "./dist/esm/index.d.ts" + "types": "./dist/esm/index.d.ts", + "import": "./dist/esm/index.js", + "require": "./dist/cjs/index.js" } },
22-27: Add postbuild step to mark ESM folder (Option A) and add quick sanity check
- Creates dist/esm/package.json with {"type":"module"} so Node parses ESM correctly.
- Adds a minimal postbuild check to fail fast if either entry is missing.
"scripts": { - "build": "yarn clean && yarn generate && yarn run -T tsc --build", + "build": "yarn clean && yarn generate && yarn run -T tsc --build", "clean": "rm -rf dist", "dev": "yarn run -T tsc --build --watch", "generate": "TS_POST_PROCESS_FILE=./generator/post_process.sh JAVA_OPTS='-Dlog.level=error' openapi-generator-cli generate" },Add these scripts:
"scripts": { + "postbuild": "node -e \"require('fs').mkdirSync('dist/esm',{recursive:true});require('fs').writeFileSync('dist/esm/package.json','{\\n \\\"type\\\": \\\"module\\\"\\n}\\n')\"", + "postbuild:verify": "node -e \"const fs=require('fs');const req=['dist/esm/index.js','dist/cjs/index.js'];process.exitCode=req.every(p=>fs.existsSync(p))?0:1\"" },packages/unchained-client/tsconfig.json (1)
2-2: ESM resolution mode note (tracked).Prior feedback about choosing Bundler vs NodeNext module resolution is already recorded; align repo-wide in the base config if you decide to change it.
packages/types/tsconfig.json (1)
3-7: Aggregator config is correct; keep declaration emission policy consistent.The solution-style config with dual references is good. Ensure only one of the ESM/CJS builds emits .d.ts and that the package "types" field points to the chosen location to avoid duplicate declaration trees.
#!/bin/bash set -euo pipefail pushd packages/types >/dev/null echo "Checking declaration emission settings across configs…" for p in tsconfig.esm.json tsconfig.cjs.json; do echo "== $p" jq -r '.compilerOptions | {declaration,emitDeclarationOnly,declarationDir,outDir,tsBuildInfoFile}' "$p" done popd >/dev/nullpackages/swapper/tsconfig.cjs.json (2)
3-8: Disable .d.ts emission in CJS to avoid duplicate/racy type outputsLet the ESM build own declaration output. Emitting from both ESM and CJS slows builds and can confuse editors during project references.
"compilerOptions": { "module": "commonjs", "rootDir": "src", "outDir": "dist/cjs", - "tsBuildInfoFile": "dist/cjs/.tsbuildinfo", + "tsBuildInfoFile": "dist/cjs/.tsbuildinfo", + "declaration": false, + "emitDeclarationOnly": false },
2-8: Override moduleResolution to Node16/Nodenext
The extended configs currently setmoduleResolution: "node"(inherited from the roottsconfig.json), which can mis-resolve conditional exports. To ensure correct module resolution for this package, explicitly specify a modern resolution algorithm here.• File requiring update:
- packages/swapper/tsconfig.cjs.json
• Apply the following change:
--- a/packages/swapper/tsconfig.cjs.json +++ b/packages/swapper/tsconfig.cjs.json @@ -2,6 +2,7 @@ "extends": "../../tsconfig.packages.json", "compilerOptions": { "module": "commonjs", + "moduleResolution": "node16", "rootDir": "src", "outDir": "dist/cjs", "tsBuildInfoFile": "dist/cjs/.tsbuildinfo",packages/unchained-client/tsconfig.cjs.json (1)
3-8: Turn off declarations in CJS buildAvoid duplicate type emission with the ESM build.
"compilerOptions": { "module": "commonjs", "rootDir": "src", "outDir": "dist/cjs", - "tsBuildInfoFile": "dist/cjs/.tsbuildinfo", + "tsBuildInfoFile": "dist/cjs/.tsbuildinfo", + "declaration": false, + "emitDeclarationOnly": false },packages/utils/tsconfig.cjs.json (1)
9-9: JSON include is optional; current glob already covers it"src//*" matches JSON too. Mirroring an explicit "src//*.json" (as in ESM) is a readability choice, not a requirement. Fine to keep as-is.
packages/contracts/tsconfig.json (1)
3-7: Env split and type ownership sanity checks
- Ensure tsconfig.esm.json excludes env.cjs.ts and tsconfig.cjs.json excludes env.esm.ts.
- Ensure only one of ESM/CJS emits declarations.
- Verify package.json exports route import/require to the correct builds.
#!/bin/bash # Verify env exclusions and declaration ownership in contracts rg -n -C2 -g 'packages/contracts/tsconfig.*.json' -e 'env\.cjs\.ts' -e 'env\.esm\.ts' -e '"declaration"\s*:' # Inspect package exports (import/require conditions) rg -n -C2 -g 'packages/contracts/package.json' -P '"exports"\s*:'
🧹 Nitpick comments (16)
packages/errors/package.json (1)
1-35: Nit: consider declaring sideEffects to improve tree-shakingErrors packages typically have no side effects. Declaring this can help bundlers. Optional and non-blocking.
{ "name": "@shapeshiftoss/errors", "version": "1.1.4", "description": "Common set of typed errors", "repository": "https://github.com/shapeshift/web", + "sideEffects": false, "main": "dist/cjs/index.js", "module": "dist/esm/index.js", "types": "dist/esm/index.d.ts",packages/types/package.json (1)
10-16: Optional: add a subpath export for package.json to aid certain toolingNot required, but consistent with ecosystem patterns and can help consumers that introspect metadata.
"exports": { ".": { "import": "./dist/esm/index.js", "require": "./dist/cjs/index.js", "types": "./dist/esm/index.d.ts" - } + }, + "./package.json": "./package.json" },packages/chain-adapters/package.json (1)
6-8: Minor consistency nit: normalize leading './' on entry paths across packagesSome packages use "main": "dist/cjs/index.js" while this one uses "./dist/cjs/index.js". Both work, but consistent style helps reduce churn.
- "main": "./dist/cjs/index.js", - "module": "./dist/esm/index.js", - "types": "./dist/esm/index.d.ts", + "main": "dist/cjs/index.js", + "module": "dist/esm/index.js", + "types": "dist/esm/index.d.ts",packages/utils/package.json (3)
10-16: Put "types" first in the export conditions (TS compatibility)
TypeScript expects the "types" condition to be listed first within an export entry for best compatibility across TS/moduleResolution variants.Apply:
"exports": { ".": { - "import": "./dist/esm/index.js", - "require": "./dist/cjs/index.js", - "types": "./dist/esm/index.d.ts" + "types": "./dist/esm/index.d.ts", + "import": "./dist/esm/index.js", + "require": "./dist/cjs/index.js" } },
16-22: Add typesVersions for older TS consumers
This improves .d.ts resolution for projects on older TypeScript or non-nodenext moduleResolution."exports": { ".": { "types": "./dist/esm/index.d.ts", "import": "./dist/esm/index.js", "require": "./dist/cjs/index.js" } }, + "typesVersions": { + "*": { + "*": ["dist/esm/*"] + } + }, "files": [
17-19: Exclude .tsbuildinfo from the published tarball
We keep tsBuildInfo inside dist on purpose (good for cleanup and rebuild speed), but we shouldn’t publish it."files": [ - "dist" + "dist", + "!dist/**/*.tsbuildinfo" ]packages/unchained-client/package.json (3)
16-18: Exclude .tsbuildinfo from the published tarball
Avoid publishing dist/**/.tsbuildinfo files."files": [ - "dist" + "dist", + "!dist/**/*.tsbuildinfo" ],
22-27: Optional: add typesVersions and a dedicated CJS watch
- typesVersions helps older TS/moduleResolution setups.
- A dedicated CJS watch can help when debugging Nest/SSR consumers.
"exports": { ".": { "types": "./dist/esm/index.d.ts", "import": "./dist/esm/index.js", "require": "./dist/cjs/index.js" } }, + "typesVersions": { + "*": { + "*": ["dist/esm/*"] + } + },"scripts": { - "dev": "yarn run -T tsc --build --watch", + "dev": "yarn run -T tsc --build --watch", + "dev:cjs": "yarn run -T tsc --build tsconfig.cjs.json --watch",
24-24: Consider cleaning root tsconfig tsbuildinfo as well
If the solution tsconfig emits a root tsconfig.tsbuildinfo, remove it during clean.- "clean": "rm -rf dist", + "clean": "rm -rf dist tsconfig*.tsbuildinfo",packages/utils/tsconfig.json (1)
3-7: Solution references are correct; optional: keep root tsbuildinfo under dist
Referencing both tsconfig.esm.json and tsconfig.cjs.json is the right shape. To avoid leaving a root tsconfig.tsbuildinfo in the package folder, you may pin it under dist as well:{ "extends": "../../tsconfig.packages.json", + "compilerOptions": { + "tsBuildInfoFile": "dist/tsconfig.root.tsbuildinfo" + }, "files": [], "references": [ { "path": "./tsconfig.esm.json" }, { "path": "./tsconfig.cjs.json" } ] }packages/swapper/src/swappers/PortalsSwapper/index.ts (1)
2-2: Use a Type-Only Star Re-Export (TS ≥ 5.0)Since your project’s TypeScript version is
^5.2.2(i.e. ≥ 5.0), you can use a type-only star re-export to avoid emitting a runtime export in CommonJS builds:• File:
packages/swapper/src/swappers/PortalsSwapper/index.ts
Line: 2Suggested change:
- export * from './types' + export type * from './types'If you’d rather list types explicitly (or need to support TS < 5.0), you can do:
export type { Foo, Bar /* etc */ } from './types'This is an optional refactor to clean up runtime output without affecting functionality.
packages/errors/tsconfig.esm.json (1)
9-10: Nit: consider aligning exclude pattern with other packagesSome packages use
["dist/**"]while this one uses["dist"]. Both work given your include, but standardizing helps consistency across the monorepo.- "exclude": ["dist"] + "exclude": ["dist/**"]packages/contracts/tsconfig.esm.json (1)
10-10: Nit: align exclude pattern with other packages for consistencyConsider using the same glob shape across packages.
- "exclude": ["dist/**"], + "exclude": ["dist/**"] // OK as-is; ensure other packages use the same patternpackages/utils/tsconfig.cjs.json (1)
3-8: Prevent duplicate type emission: CJS should not emit declarationsMirror the approach across packages so only ESM emits .d.ts.
"compilerOptions": { "module": "commonjs", "rootDir": "src", "outDir": "dist/cjs", - "tsBuildInfoFile": "dist/cjs/.tsbuildinfo", + "tsBuildInfoFile": "dist/cjs/.tsbuildinfo", + "declaration": false, + "emitDeclarationOnly": false },packages/chain-adapters/tsconfig.esm.json (2)
7-7: Align tsbuildinfo naming/location with team conventionPer the repo preference, tsBuildInfoFile lives under dist with a descriptive filename (e.g., dist/tsconfig.esm.tsbuildinfo). This file uses dist/esm/.tsbuildinfo which deviates and can fragment cleanup conventions.
Apply this diff for consistency:
- "tsBuildInfoFile": "dist/esm/.tsbuildinfo", + "tsBuildInfoFile": "dist/tsconfig.esm.tsbuildinfo",
9-10: Redundant include pattern (non-blocking)"src//*" already matches JSON files; the explicit "src//*.json" is redundant if resolveJsonModule is enabled upstream (as is typical in this repo). Keeping it is harmless—mentioning for tidiness only.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (41)
package.json(1 hunks)packages/caip/package.json(2 hunks)packages/caip/tsconfig.cjs.json(1 hunks)packages/caip/tsconfig.esm.json(1 hunks)packages/caip/tsconfig.json(1 hunks)packages/chain-adapters/package.json(2 hunks)packages/chain-adapters/tsconfig.cjs.json(1 hunks)packages/chain-adapters/tsconfig.esm.json(1 hunks)packages/chain-adapters/tsconfig.json(1 hunks)packages/contracts/package.json(2 hunks)packages/contracts/src/ethersProviderSingleton.ts(1 hunks)packages/contracts/src/viemClient.ts(1 hunks)packages/contracts/tsconfig.cjs.json(1 hunks)packages/contracts/tsconfig.esm.json(1 hunks)packages/contracts/tsconfig.json(1 hunks)packages/errors/package.json(2 hunks)packages/errors/tsconfig.cjs.json(1 hunks)packages/errors/tsconfig.esm.json(1 hunks)packages/errors/tsconfig.json(1 hunks)packages/swapper/package.json(2 hunks)packages/swapper/src/swappers/PortalsSwapper/index.ts(1 hunks)packages/swapper/tsconfig.cjs.json(1 hunks)packages/swapper/tsconfig.esm.json(1 hunks)packages/swapper/tsconfig.json(1 hunks)packages/types/package.json(2 hunks)packages/types/tsconfig.cjs.json(1 hunks)packages/types/tsconfig.esm.json(1 hunks)packages/types/tsconfig.json(1 hunks)packages/unchained-client/package.json(2 hunks)packages/unchained-client/tsconfig.cjs.json(1 hunks)packages/unchained-client/tsconfig.esm.json(1 hunks)packages/unchained-client/tsconfig.json(1 hunks)packages/utils/package.json(2 hunks)packages/utils/tsconfig.cjs.json(1 hunks)packages/utils/tsconfig.esm.json(1 hunks)packages/utils/tsconfig.json(1 hunks)src/pages/Markets/hooks/useRows.tsx(1 hunks)tsconfig.json(1 hunks)tsconfig.packages.json(1 hunks)tsconfig.web.json(0 hunks)vite.config.mts(1 hunks)
💤 Files with no reviewable changes (1)
- tsconfig.web.json
✅ Files skipped from review due to trivial changes (1)
- packages/swapper/tsconfig.esm.json
🚧 Files skipped from review as they are similar to previous changes (13)
- packages/caip/tsconfig.cjs.json
- packages/chain-adapters/tsconfig.cjs.json
- tsconfig.packages.json
- packages/caip/package.json
- packages/types/tsconfig.cjs.json
- package.json
- packages/contracts/tsconfig.cjs.json
- packages/caip/tsconfig.json
- packages/contracts/package.json
- packages/contracts/src/ethersProviderSingleton.ts
- packages/errors/tsconfig.cjs.json
- packages/contracts/src/viemClient.ts
- packages/swapper/package.json
🧰 Additional context used
📓 Path-based instructions (11)
**/*
📄 CodeRabbit inference engine (.cursor/rules/naming-conventions.mdc)
**/*: ALWAYS use appropriate file extensions
Flag files without kebab-case
Files:
packages/types/tsconfig.esm.jsonpackages/utils/tsconfig.esm.jsonpackages/swapper/src/swappers/PortalsSwapper/index.tspackages/errors/tsconfig.esm.jsonpackages/chain-adapters/tsconfig.esm.jsonpackages/contracts/tsconfig.esm.jsonpackages/types/tsconfig.jsonpackages/caip/tsconfig.esm.jsonpackages/swapper/tsconfig.jsonpackages/utils/tsconfig.cjs.jsontsconfig.jsonsrc/pages/Markets/hooks/useRows.tsxpackages/unchained-client/tsconfig.esm.jsonpackages/utils/package.jsonpackages/errors/tsconfig.jsonpackages/types/package.jsonpackages/unchained-client/tsconfig.cjs.jsonvite.config.mtspackages/errors/package.jsonpackages/contracts/tsconfig.jsonpackages/utils/tsconfig.jsonpackages/unchained-client/tsconfig.jsonpackages/unchained-client/package.jsonpackages/chain-adapters/package.jsonpackages/chain-adapters/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
packages/swapper/src/swappers/*/{*.ts,endpoints.ts}
📄 CodeRabbit inference engine (.cursor/rules/swapper.mdc)
packages/swapper/src/swappers/*/{*.ts,endpoints.ts}: All swappers must conform to the Swapper and SwapperApi interfaces defined in packages/swapper/src/types.ts.
Leverage shared utilities (e.g., executeEvmTransaction, checkEvmSwapStatus) in swapper implementations when applicable.
Validate inputs and log errors for debugging in swapper implementations.
Avoid side effects in swap logic within swapper implementation files.
Include comments explaining swap logic in swapper implementation files.
Verify chain ID filtering in filterAssetIdsBySellable and filterBuyAssetsBySellAssetId methods.
Files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
packages/swapper/src/swappers/*/{*.ts,utils/*.ts}
📄 CodeRabbit inference engine (.cursor/rules/swapper.mdc)
Each swapper must be implemented in its own directory under packages/swapper/src/swappers// with the following files: .ts, endpoints.ts, utils/constants.ts, utils/helpers.ts, types.ts.
Files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
packages/swapper/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/swapper.mdc)
packages/swapper/**/*.ts: Use TypeScript with explicit types (e.g., SupportedChainIds) in all swapper-related files.
Use camelCase for variables and functions, PascalCase for types and interfaces, and kebab-case for filenames in swapper-related files.
Files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
packages/swapper/src/swappers/**/*
📄 CodeRabbit inference engine (.cursor/rules/swapper.mdc)
Avoid placing swapper files outside packages/swapper/src/swappers/.
Files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)
**/*.{ts,tsx}: ALWAYS use Result<T, E> pattern for error handling in swappers and APIs
ALWAYS use Ok() and Err() from @sniptt/monads for monadic error handling
ALWAYS use custom error classes from @shapeshiftoss/errors
ALWAYS provide meaningful error codes for internationalization
ALWAYS include relevant details in error objects
ALWAYS wrap async operations in try-catch blocks
ALWAYS use AsyncResultOf utility for converting promises to Results
ALWAYS provide fallback error handling
ALWAYS use timeoutMonadic for API calls
ALWAYS provide appropriate timeout values for API calls
ALWAYS handle timeout errors gracefully
ALWAYS validate inputs before processing
ALWAYS provide clear validation error messages
ALWAYS use early returns for validation failures
ALWAYS log errors for debugging
ALWAYS use structured logging for errors
ALWAYS include relevant context in error logs
Throwing errors instead of using monadic patterns is an anti-pattern
Missing try-catch blocks for async operations is an anti-pattern
Generic error messages without context are an anti-pattern
Not handling specific error types is an anti-pattern
Missing timeout handling is an anti-pattern
No input validation is an anti-pattern
Poor error logging is an anti-pattern
Using any for error types is an anti-pattern
Missing error codes for internationalization is an anti-pattern
No fallback error handling is an anti-pattern
Console.error without structured logging is an anti-pattern
**/*.{ts,tsx}: ALWAYS use camelCase for variables, functions, and methods
ALWAYS use descriptive names that explain the purpose for variables and functions
ALWAYS use verb prefixes for functions that perform actions
ALWAYS use PascalCase for types, interfaces, and enums
ALWAYS use descriptive names that indicate the structure for types, interfaces, and enums
ALWAYS use suffixes like Props, State, Config, Type when appropriate for types and interfaces
ALWAYS use UPPER_SNAKE_CASE for constants and configuration values
ALWAYS use d...
Files:
packages/swapper/src/swappers/PortalsSwapper/index.tssrc/pages/Markets/hooks/useRows.tsx
**/swapper/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)
**/swapper/**/*.{ts,tsx}: AVOID throwing within swapper API implementations; return Err() instead. UI layers may still throw (caught by React error boundaries).
ALWAYS use makeSwapErrorRight for swapper errors
ALWAYS use TradeQuoteError enum for error codes in swapper errors
ALWAYS provide detailed error information in swapper errors
Files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)
USE Redux only for global state shared across multiple places
Files:
packages/swapper/src/swappers/PortalsSwapper/index.tssrc/pages/Markets/hooks/useRows.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)
**/*.tsx: ALWAYS wrap components in error boundaries
ALWAYS provide user-friendly fallback components in error boundaries
ALWAYS log errors for debugging in error boundaries
ALWAYS use useErrorToast hook for displaying errors
ALWAYS provide translated error messages in error toasts
ALWAYS handle different error types appropriately in error toasts
Missing error boundaries in React components is an anti-pattern
**/*.tsx: ALWAYS use PascalCase for React component names
ALWAYS use descriptive names that indicate the component's purpose
ALWAYS match the component name to the file name
Flag components without PascalCase
Flag default exports for components
Files:
src/pages/Markets/hooks/useRows.tsx
**/use*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/naming-conventions.mdc)
**/use*.{ts,tsx}: ALWAYS use use prefix for custom hooks
ALWAYS use descriptive names that indicate the hook's purpose
ALWAYS use camelCase after the use prefix for custom hooks
Files:
src/pages/Markets/hooks/useRows.tsx
**/*.{tsx,jsx}
📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)
**/*.{tsx,jsx}: ALWAYS useuseMemofor expensive computations, object/array creations, and filtered data
ALWAYS useuseMemofor derived values and computed properties
ALWAYS useuseMemofor conditional values and simple transformations
ALWAYS useuseCallbackfor event handlers and functions passed as props
ALWAYS useuseCallbackfor any function that could be passed as a prop or dependency
ALWAYS include all dependencies inuseEffect,useMemo,useCallbackdependency arrays
NEVER use// eslint-disable-next-line react-hooks/exhaustive-depsunless absolutely necessary
ALWAYS explain why dependencies are excluded if using eslint disable
ALWAYS use named exports for components
NEVER use default exports for components
KEEP component files under 200 lines when possible
BREAK DOWN large components into smaller, reusable pieces
EXTRACT complex logic into custom hooks
USE local state for component-level state
LIFT state up when needed across multiple components
USE Context for avoiding prop drilling
ALWAYS wrap components in error boundaries for production
ALWAYS handle async errors properly
ALWAYS provide user-friendly error messages
ALWAYS use virtualization for lists with 100+ items
ALWAYS implement proper key props for list items
ALWAYS lazy load heavy components
ALWAYS use React.lazy for code splitting
Components receiving props are wrapped withmemo
Files:
src/pages/Markets/hooks/useRows.tsx
🧠 Learnings (32)
📓 Common learnings
Learnt from: NeOMakinG
PR: shapeshift/web#10231
File: src/components/MultiHopTrade/components/TradeInput/components/HighlightedTokens.tsx:14-14
Timestamp: 2025-08-08T15:00:22.321Z
Learning: In shapeshift/web reviews for NeOMakinG, avoid nitpicks to change deep-relative imports to '@/…' alias paths within feature/non-refactor PRs; defer such style-only changes to a dedicated follow-up refactor unless they fix an issue.
Learnt from: NeOMakinG
PR: shapeshift/web#10323
File: src/pages/RFOX/components/Stake/components/StakeSummary.tsx:112-114
Timestamp: 2025-08-22T13:00:44.813Z
Learning: NeOMakinG prefers to keep PR changes minimal and focused on the core objectives, avoiding cosmetic or defensive code improvements that aren't directly related to the PR scope, even when they would improve robustness.
📚 Learning: 2025-08-22T15:45:16.277Z
Learnt from: kaladinlight
PR: shapeshift/web#10257
File: packages/caip/tsconfig.json:5-7
Timestamp: 2025-08-22T15:45:16.277Z
Learning: In the ShapeShift web repository, tsBuildInfoFile is intentionally placed inside the dist directory (e.g., "dist/tsconfig.esm.tsbuildinfo") to enable easy cleanup and leverage tsbuildinfo for faster re-build/hotreload actions. The team prefers this approach over preserving build info outside dist for incremental builds.
Applied to files:
packages/types/tsconfig.esm.jsonpackages/utils/tsconfig.esm.jsonpackages/errors/tsconfig.esm.jsonpackages/chain-adapters/tsconfig.esm.jsonpackages/contracts/tsconfig.esm.jsonpackages/types/tsconfig.jsonpackages/caip/tsconfig.esm.jsontsconfig.jsonpackages/unchained-client/tsconfig.esm.jsonpackages/utils/package.jsonpackages/errors/tsconfig.jsonpackages/types/package.jsonpackages/unchained-client/tsconfig.cjs.jsonpackages/contracts/tsconfig.jsonpackages/utils/tsconfig.jsonpackages/unchained-client/tsconfig.jsonpackages/unchained-client/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-08-22T15:46:09.299Z
Learnt from: kaladinlight
PR: shapeshift/web#10257
File: packages/caip/tsconfig.json:8-9
Timestamp: 2025-08-22T15:46:09.299Z
Learning: In the ShapeShift web repository, when analyzing TypeScript configuration inheritance, always check the complete chain: individual package configs often extend tsconfig.packages.json, which in turn extends the root tsconfig.json that contains shared compiler options like resolveJsonModule.
Applied to files:
packages/types/tsconfig.esm.jsonpackages/utils/tsconfig.esm.jsonpackages/chain-adapters/tsconfig.esm.jsonpackages/contracts/tsconfig.esm.jsonpackages/types/tsconfig.jsonpackages/swapper/tsconfig.jsontsconfig.jsonpackages/unchained-client/tsconfig.esm.jsonpackages/errors/tsconfig.jsonpackages/unchained-client/tsconfig.cjs.jsonpackages/contracts/tsconfig.jsonpackages/utils/tsconfig.jsonpackages/unchained-client/tsconfig.jsonpackages/chain-adapters/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/index.ts : Export unique functions/types from packages/swapper/src/index.ts if needed.
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.tspackages/swapper/tsconfig.jsonsrc/pages/Markets/hooks/useRows.tsxpackages/utils/package.jsonpackages/unchained-client/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/{constants,types}.ts : Register new swappers in packages/swapper/src/constants.ts and add them to the SwapperName enum in packages/swapper/src/types.ts.
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.tspackages/swapper/tsconfig.jsonsrc/pages/Markets/hooks/useRows.tsxpackages/utils/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Avoid side effects in swap logic within swapper implementation files.
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.tspackages/swapper/tsconfig.jsonsrc/pages/Markets/hooks/useRows.tsxpackages/utils/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : All swappers must conform to the Swapper and SwapperApi interfaces defined in packages/swapper/src/types.ts.
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.tspackages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Include comments explaining swap logic in swapper implementation files.
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.tspackages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/**/*.ts : Use TypeScript with explicit types (e.g., SupportedChainIds) in all swapper-related files.
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.tspackages/chain-adapters/tsconfig.esm.jsonpackages/swapper/tsconfig.jsonsrc/pages/Markets/hooks/useRows.tsxpackages/utils/package.jsonpackages/unchained-client/tsconfig.jsonpackages/unchained-client/package.jsonpackages/chain-adapters/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/constants.ts : Prevent unregistered swappers in the registry (i.e., all swappers must be registered in packages/swapper/src/constants.ts).
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
📚 Learning: 2025-08-03T22:10:11.424Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/naming-conventions.mdc:0-0
Timestamp: 2025-08-03T22:10:11.424Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS group related constants together
Applied to files:
packages/swapper/src/swappers/PortalsSwapper/index.ts
📚 Learning: 2025-08-03T22:09:37.542Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/error-handling.mdc:0-0
Timestamp: 2025-08-03T22:09:37.542Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS include relevant details in error objects
Applied to files:
packages/errors/tsconfig.esm.jsonpackages/errors/tsconfig.json
📚 Learning: 2025-08-03T22:10:38.426Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/react-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:10:38.426Z
Learning: Applies to **/*.{ts,tsx} : Missing TypeScript types
Applied to files:
packages/errors/tsconfig.esm.jsonpackages/types/tsconfig.jsontsconfig.jsonpackages/utils/package.json
📚 Learning: 2025-08-03T22:10:11.424Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/naming-conventions.mdc:0-0
Timestamp: 2025-08-03T22:10:11.424Z
Learning: Applies to **/*.{ts,tsx} : Flag inconsistent naming patterns
Applied to files:
packages/types/tsconfig.jsonpackages/errors/tsconfig.jsonpackages/unchained-client/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/**/*.ts : Use camelCase for variables and functions, PascalCase for types and interfaces, and kebab-case for filenames in swapper-related files.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,utils/*.ts} : Each swapper must be implemented in its own directory under packages/swapper/src/swappers/<SwapperName>/ with the following files: <SwapperName>.ts, endpoints.ts, utils/constants.ts, utils/helpers.ts, types.ts.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/**/*.@(test|spec).ts : Write unit tests for swapper methods and API endpoints.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Leverage shared utilities (e.g., executeEvmTransaction, checkEvmSwapStatus) in swapper implementations when applicable.
Applied to files:
packages/swapper/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-08-03T22:10:11.424Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/naming-conventions.mdc:0-0
Timestamp: 2025-08-03T22:10:11.424Z
Learning: Applies to **/*.{ts,tsx} : Flag renamed imports without good reason
Applied to files:
tsconfig.jsonpackages/errors/tsconfig.jsonpackages/unchained-client/tsconfig.jsonpackages/unchained-client/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-07-24T09:43:11.699Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/swapper.mdc:0-0
Timestamp: 2025-07-24T09:43:11.699Z
Learning: Applies to packages/swapper/src/swappers/*/{*.ts,endpoints.ts} : Verify chain ID filtering in filterAssetIdsBySellable and filterBuyAssetsBySellAssetId methods.
Applied to files:
src/pages/Markets/hooks/useRows.tsx
📚 Learning: 2025-08-03T22:10:38.426Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/react-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:10:38.426Z
Learning: Applies to **/*.{ts,tsx} : TypeScript types are explicit and proper
Applied to files:
packages/utils/package.json
📚 Learning: 2025-08-03T22:11:30.833Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/typescript-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:11:30.833Z
Learning: Applies to **/*.{ts,tsx} : Missing explicit types
Applied to files:
packages/utils/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-08-03T22:11:30.833Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/typescript-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:11:30.833Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS use utility types for common transformations
Applied to files:
packages/utils/package.json
📚 Learning: 2025-08-03T22:11:30.833Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/typescript-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:11:30.833Z
Learning: Applies to **/*.{ts,tsx} : `any` type is avoided unless absolutely necessary
Applied to files:
packages/utils/package.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-08-03T22:11:30.833Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/typescript-best-practices.mdc:0-0
Timestamp: 2025-08-03T22:11:30.833Z
Learning: Applies to **/*.{ts,tsx} : Generic types are used appropriately
Applied to files:
packages/utils/package.json
📚 Learning: 2025-08-08T20:16:12.898Z
Learnt from: gomesalexandre
PR: shapeshift/web#10222
File: package.json:202-202
Timestamp: 2025-08-08T20:16:12.898Z
Learning: In shapeshift/web, the semver package must be included in dependencies (not devDependencies) because hdwallet packages have transient dependencies that require semver but don't ship it themselves. This ensures semver is available at runtime for hdwallet functionality.
Applied to files:
packages/utils/package.jsonpackages/errors/package.json
📚 Learning: 2025-08-03T22:10:11.424Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/naming-conventions.mdc:0-0
Timestamp: 2025-08-03T22:10:11.424Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS avoid renaming imports unless necessary
Applied to files:
packages/errors/tsconfig.jsonpackages/swapper/tsconfig.cjs.json
📚 Learning: 2025-08-08T15:00:22.321Z
Learnt from: NeOMakinG
PR: shapeshift/web#10231
File: src/components/MultiHopTrade/components/TradeInput/components/HighlightedTokens.tsx:14-14
Timestamp: 2025-08-08T15:00:22.321Z
Learning: In shapeshift/web reviews for NeOMakinG, avoid nitpicks to change deep-relative imports to '@/…' alias paths within feature/non-refactor PRs; defer such style-only changes to a dedicated follow-up refactor unless they fix an issue.
Applied to files:
packages/errors/tsconfig.jsonpackages/unchained-client/package.json
📚 Learning: 2025-08-03T22:09:37.542Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/error-handling.mdc:0-0
Timestamp: 2025-08-03T22:09:37.542Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS include relevant context in error logs
Applied to files:
packages/errors/tsconfig.json
📚 Learning: 2025-08-03T22:10:11.424Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/naming-conventions.mdc:0-0
Timestamp: 2025-08-03T22:10:11.424Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS use descriptive import names
Applied to files:
packages/errors/tsconfig.json
📚 Learning: 2025-08-03T22:09:37.542Z
Learnt from: CR
PR: shapeshift/web#0
File: .cursor/rules/error-handling.mdc:0-0
Timestamp: 2025-08-03T22:09:37.542Z
Learning: Applies to **/*.{ts,tsx} : ALWAYS use custom error classes from shapeshiftoss/errors
Applied to files:
packages/errors/package.json
📚 Learning: 2025-08-08T20:27:02.203Z
Learnt from: gomesalexandre
PR: shapeshift/web#10222
File: package.json:202-202
Timestamp: 2025-08-08T20:27:02.203Z
Learning: In shapeshift/web, while gomesalexandre generally prefers pinned dependencies for security, semver with a caret range (^7.7.2) is acceptable as an exception since it's already a transient dependency of many packages and is being made explicit for hdwallet support.
Applied to files:
packages/errors/package.json
🔇 Additional comments (30)
tsconfig.json (1)
21-23: Path mapping to workspace sources looks good and aligns with project refsThis enables importing monorepo packages from source during app type-checking/bundling and matches the repo’s project-reference strategy. No issues spotted.
packages/errors/package.json (1)
6-15: Exports map/main/module/types are correctly wired for dual ESM/CJS publishing
- main -> CJS, module -> ESM, and exports with import/require/types are consistent.
- types points to the ESM d.ts, which is fine given a single types build.
packages/types/package.json (1)
7-16: Dual ESM/CJS surface and types path look consistent across the monorepoConfiguration mirrors the other packages and should work fine with both import and require consumers.
packages/chain-adapters/package.json (1)
6-15: Exports map/main/module/types are properly set for dual-publishThis mirrors the pattern used elsewhere in the PR and should be consumable by both ESM and CJS environments.
src/pages/Markets/hooks/useRows.tsx (2)
2-2: LGTM: import now targets the top-level swapper export
Switching to '@shapeshiftoss/swapper' for PortalsSupportedChainIds simplifies dependencies and matches the re-export strategy. No logic changes.
2-2: PortalsSupportedChainIds properly exported and inferred as ChainId[]
- Declaration:
packages/swapper/src/swappers/PortalsSwapper/types.ts exports
export const PortalsSupportedChainIds = [ … ], which TS infers asKnownChainIds[](a subtype ofChainId[]).- Swapper-level re-export:
packages/swapper/src/swappers/PortalsSwapper/index.ts →export * from './types'.- Package-level re-export:
packages/swapper/src/index.ts →export * from './swappers/PortalsSwapper'.No further changes required—importing
PortalsSupportedChainIdsfrom@shapeshiftoss/swappergives you the correctly typed array.packages/caip/tsconfig.esm.json (1)
3-11: ESM build config looks correct and matches repo preferences
- module: esnext, outDir: dist/esm, and tsBuildInfoFile inside dist/esm align with the monorepo pattern for fast rebuilds and easy cleanup.
- include/exclude are sane.
No blocking issues from me here.
packages/utils/tsconfig.esm.json (1)
11-14: References look correct; tsbuildinfo location matches team preference.Project references to ../caip and ../types ESM configs match expected deps, and tsBuildInfoFile under dist/ aligns with team preference for easy cleanup and hot reloads.
packages/unchained-client/tsconfig.json (2)
3-7: Solution-style tsconfig with dual-build references looks good.Using "files": [] and referencing ./tsconfig.esm.json and ./tsconfig.cjs.json is the right structure for tsc -b builds from the package root.
2-7: Verify ESM & CJS build outputs via the workspace build scriptPlease run the Unchained Client package’s own build commands to ensure both module graphs compile cleanly and emit into their expected outDirs. This will catch any missing references or path‐alias regressions early.
• From the repo root, invoke the package’s build script (which picks up the root’s TypeScript version):
yarn workspace unchained-client buildThis runs
yarn cleanyarn generateyarn run -T tsc --build tsconfig.json• If you prefer to build each graph separately, you can also run:
# ESM build yarn workspace unchained-client run tsc --build packages/unchained-client/tsconfig.esm.json # CJS build yarn workspace unchained-client run tsc --build packages/unchained-client/tsconfig.cjs.json• After building, verify that the outputs land in the correct directories (e.g.
dist/esmanddist/cjs), and that there are no type errors or missing-reference warnings.This ensures your new
referencesin tsconfig.json are wired up correctly before merging.packages/types/tsconfig.json (1)
2-7: No TypeScript project reference cycles detected betweenpackages/typesandpackages/caipVerified that the only project‐reference edges are one‐way from
packages/types→packages/caip, and that none of thepackages/caipconfigs reference back topackages/types. No cycles present.•
packages/types/tsconfig.esm.json(line 11) →../caip/tsconfig.esm.json
•packages/types/tsconfig.cjs.json(line 11) →../caip/tsconfig.cjs.json
•packages/caip/tsconfig.esm.jsonandpackages/caip/tsconfig.cjs.jsoncontain noreferencesblocksSince all references are one‐way and no back‐references exist, the build will not break due to a cycle.
packages/swapper/tsconfig.json (2)
3-7: Good: convert to solution-style config referencing ESM/CJS builds.This aligns with the monorepo approach and keeps the root package tsconfig minimal.
3-7: Confirmed sibling package references in ESM and CJS configsBoth
packages/swapper/tsconfig.esm.jsonandpackages/swapper/tsconfig.cjs.jsoncorrectly reference all required sibling packages:
- packages/swapper/tsconfig.esm.json:
../caip/tsconfig.esm.json../chain-adapters/tsconfig.esm.json../types/tsconfig.esm.json../utils/tsconfig.esm.json- packages/swapper/tsconfig.cjs.json:
../caip/tsconfig.cjs.json../chain-adapters/tsconfig.cjs.json../types/tsconfig.cjs.json../utils/tsconfig.cjs.jsonNo further changes are needed here.
packages/types/tsconfig.esm.json (2)
11-13: Reference direction looks intentional; ensure no back-edges from caip.Referencing ../caip/tsconfig.esm.json from types is fine if types genuinely depends on caip types. Just ensure caip does not reference types back.
You can reuse the cycle-check script provided on packages/types/tsconfig.json.
2-8: tsbuildinfo under dist is OK per team practice.Placement under dist/esm is consistent with the repo’s preference for easy cleanups and fast hot reloads; no change requested.
packages/swapper/src/swappers/PortalsSwapper/index.ts (1)
2-2: LGTM: exposing PortalsSwapper types via the barrel is aligned with the PR goal and has no side effectsThis keeps the swapper’s public API coherent while remaining tree-shakeable. No runtime logic changed.
packages/errors/tsconfig.esm.json (1)
1-11: ESM project config looks correct and consistent with the repo pattern
- Extends the shared packages config.
- Outputs to dist/esm with tsBuildInfo inside dist (matches team preference for easy cleanup and faster rebundles).
- Includes src, excludes dist — all good.
packages/chain-adapters/tsconfig.json (2)
3-8: Solution-style root tsconfig with dual references is set up correctly
- Empty
"files": []plus references totsconfig.esm.jsonandtsconfig.cjs.jsonmatches the project-references pattern for dual ESM/CJS outputs.- No package-specific compiler options here (delegated to per-target configs) — good separation.
4-7: ✅ ESM/CJS tsconfig sanity check passedBoth
tsconfig.esm.jsonandtsconfig.cjs.jsonexist and correctly specify distinctoutDirandtsBuildInfoFilesettings, preventing any build collisions. No further changes required.•
packages/chain-adapters/tsconfig.esm.json
– module:"esnext"
– outDir:"dist/esm"
– tsBuildInfoFile:"dist/esm/.tsbuildinfo"•
packages/chain-adapters/tsconfig.cjs.json
– module:"commonjs"
– outDir:"dist/cjs"
– tsBuildInfoFile:"dist/cjs/.tsbuildinfo"packages/contracts/tsconfig.esm.json (2)
1-16: ESM config LGTM; references and build-info placement follow the repo’s approach
- Extends the package’s local tsconfig, emits to dist/esm, and stores tsbuildinfo under dist/esm — aligned with team practices.
- Includes JSON and .d.ts explicitly; safe and clear given resolveJsonModule likely comes from the base chain.
2-8: Confirmed base inheritance and compiler optionsThe
packages/contracts/tsconfig.esm.jsonextends its localtsconfig.json, which itself extends the sharedtsconfig.packages.json. That shared config sets"composite": true, and in turn extends the roottsconfig.jsonwhere"resolveJsonModule": trueis declared. Therefore,tsconfig.esm.jsoncorrectly inherits bothcompositeandresolveJsonModuleand aligns with the monorepo standard. No changes needed.packages/unchained-client/tsconfig.esm.json (2)
1-15: ESM project config is correct; references to caip and contracts look right
- Output to dist/esm with per-target tsbuildinfo aligns with the repo pattern.
- The project references will ensure correct build order.
11-14: No action needed—CJS references are correctly mirroredThe
referencesarray inpackages/unchained-client/tsconfig.cjs.jsonalready points to the corresponding CJS configs for both sibling packages, matching the intent of the original suggestion:
- packages/unchained-client/tsconfig.cjs.json
"references": [- { "path": "../caip/tsconfig.esm.json" },
- { "path": "../contracts/tsconfig.esm.json" }
- { "path": "../caip/tsconfig.cjs.json" },
- { "path": "../contracts/tsconfig.cjs.json" }
]Since the CJS build is set up to resolve dependencies identically to the ESM build, no further changes are required. </blockquote></details> <details> <summary>packages/swapper/tsconfig.cjs.json (1)</summary><blockquote> `7-7`: **tsBuildInfo inside dist matches repo preference** Keeping tsBuildInfoFile under dist is consistent with the team’s chosen cleanup/fast-rebuild workflow. No change requested. </blockquote></details> <details> <summary>packages/errors/tsconfig.json (1)</summary><blockquote> `4-10`: **Aggregator tsconfig looks correct for project references** composite + empty files array with references to esm/cjs configs is the right shape for solution-style builds. </blockquote></details> <details> <summary>packages/unchained-client/tsconfig.cjs.json (1)</summary><blockquote> `7-7`: **tsBuildInfo path is fine per repo conventions** Storing build info under dist is aligned with current repo practices. No action needed. </blockquote></details> <details> <summary>packages/contracts/tsconfig.json (1)</summary><blockquote> `3-7`: **Solution config + references LGTM** files: [] with references to esm/cjs projects is correct for composite builds. </blockquote></details> <details> <summary>packages/chain-adapters/tsconfig.esm.json (3)</summary><blockquote> `1-17`: **ESM config looks aligned with repo patterns** Extends the shared packages config, uses src as rootDir, outputs to dist/esm, excludes dist, and wires project references—good structure for dual-builds. --- `4-4`: **Confirm module + resolution strategy matches the repo’s Node/bundler target** "module": "esnext" is fine for ESM, but it should pair with the project-wide "moduleResolution" (often "bundler" or "node16"/"nodenext") from ../../tsconfig.packages.json. Please confirm the base config sets the intended resolution for ESM so path exports and type resolution behave as expected in Node and bundlers. --- `11-16`: **Project references verified and buildable; no changes needed** All referenced tsconfig.esm.json files exist under packages/caip, packages/types, packages/unchained-client, and packages/utils, each defining an appropriate outDir. The root tsconfig.packages.json enables `"composite": true` and `"declaration": true`. No circular references were detected across these configurations. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
kaladinlight
left a comment
kaladinlight
left a comment
There was a problem hiding this comment.
Looks good assuming the server build still works as intended! Not sure why the asset generation in this PR.
|
Yolo merging this now! Confirmed this works with the current server with the new micro service architecture 
Thanks for the help @kaladinlight , very much appreciated! We will need to publish those package to |
This reverts commit 6f89f1c.
This reverts commit 09ea3b1.
2 participants
Description
Issue (if applicable)
closes nothing as this is the result of the notification server spike
Risk
Testing
yarn build:packagesand notice we have CJS build foldersEngineering
Operations
Screenshots (if applicable)
And
Summary by CodeRabbit
New Features
Chores