Fix/paste window #619
Fix/paste window #619
Conversation
WalkthroughThis pull request introduces extensive dependency version updates across multiple package JSON files along with minor refactors in source and configuration files. Several packages now use newer versions of tools and libraries, and the changes include syntactical improvements, such as added semicolons and updated module imports. In the UI components, address checking logic is refactored into a dedicated method with error handling, and event handlers are modified to properly toggle UI elements. Some configuration files are updated for enhanced module resolution and polyfill handling. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SendTxComponent
participant Clipboard
User->>SendTxComponent: Trigger @update:paste-from-clipboard event
SendTxComponent->>Clipboard: Execute pasteFromClipboard()
SendTxComponent->>SendTxComponent: Call toggleSelectContactTo(false)
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
💼 Build Files |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/extension/vite.config.ts (1)
104-104: Consider the implications of bundling all dependencies.Setting
external: []means all dependencies will be bundled, which could lead to larger bundle sizes. Consider explicitly marking certain dependencies as external if they don't need to be bundled.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (25)
package.json(1 hunks)packages/extension-bridge/package.json(1 hunks)packages/extension/configs/vite/empty.js(1 hunks)packages/extension/configs/vite/transform-manifest.ts(3 hunks)packages/extension/package.json(3 hunks)packages/extension/src/providers/common/ui/send-transaction/send-address-item.vue(1 hunks)packages/extension/src/providers/common/ui/send-transaction/send-contacts-list.vue(4 hunks)packages/extension/src/providers/ethereum/ui/send-transaction/index.vue(1 hunks)packages/extension/src/ui/action/main.ts(1 hunks)packages/extension/src/ui/action/views/import-account/views/import-account-password.vue(2 hunks)packages/extension/src/ui/action/views/import-account/views/import-account-private-key.vue(2 hunks)packages/extension/tsconfig.node.json(1 hunks)packages/extension/vite.config.ts(4 hunks)packages/hw-wallets/package.json(2 hunks)packages/keyring/package.json(1 hunks)packages/name-resolution/package.json(2 hunks)packages/request/package.json(1 hunks)packages/signers/bitcoin/package.json(1 hunks)packages/signers/ethereum/package.json(1 hunks)packages/signers/kadena/package.json(1 hunks)packages/signers/polkadot/package.json(1 hunks)packages/storage/package.json(1 hunks)packages/swap/package.json(1 hunks)packages/types/package.json(1 hunks)packages/utils/package.json(1 hunks)
✅ Files skipped from review due to trivial changes (4)
- packages/extension/src/ui/action/main.ts
- packages/extension/configs/vite/empty.js
- packages/extension/src/providers/common/ui/send-transaction/send-address-item.vue
- packages/extension/configs/vite/transform-manifest.ts
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: buildAll
- GitHub Check: test
🔇 Additional comments (30)
packages/extension/src/providers/common/ui/send-transaction/send-contacts-list.vue (2)
42-42: LGTM! Improved code maintainability.The changes centralize the address checking logic by using a dedicated method consistently across all instances of
send-address-item.Also applies to: 54-54, 72-72
120-131: LGTM! Robust error handling implementation.The
isCheckedmethod is well-implemented with:
- Proper error handling using try-catch
- Safe fallback to
falseon error- Error logging for debugging
- Type safety with TypeScript
packages/extension/src/providers/ethereum/ui/send-transaction/index.vue (1)
45-50: LGTM! Enhanced user experience.The changes improve UX by ensuring the contact selection dropdown closes automatically after pasting an address from the clipboard.
packages/extension/src/ui/action/views/import-account/views/import-account-password.vue (2)
40-40:❓ Verification inconclusive
Package migration from
ethereumjs-walletto@ethereumjs/walletThe import statement has been updated to use the newer
@ethereumjs/walletpackage. This is a breaking change that requires verification of the package version and its compatibility.Let's verify the package version and check for any breaking changes:
🏁 Script executed:
#!/bin/bash # Check package.json for the version of @ethereumjs/wallet cat package.json | jq '.dependencies["@ethereumjs/wallet"]' # Check for any migration guides or breaking changes curl -s https://raw.githubusercontent.com/ethereumjs/ethereumjs-monorepo/master/packages/wallet/CHANGELOG.mdLength of output: 18696
Action Required: Verify Breaking Changes in Wallet Imports & Address Retrieval
- The import statement has been updated from using a default export (
import Wallet, { thirdparty } ...) to using explicit named exports (import { Wallet, thirdparty } ...) as required by the migration to the new@ethereumjs/walletpackage. This change follows the migration guide noted in the changelog (see version 2.0.0-rc.1).- The update to retrieve the wallet address—from using
wallet.getAddress().toString('hex')to the newwallet.getAddressString()method—is consistent with the updated API.- Since the package version check couldn’t be performed via the repository root’s
package.json(file not found), please ensure that the dependency is correctly declared (possibly in a sub-package) and that your project is using a version of@ethereumjs/walletthat supports these changes.
116-116:✅ Verification successful
Method change from
getAddress().toString('hex')togetAddressString()The method for retrieving the wallet address has been updated to use
getAddressString(). This change aligns with the new API from@ethereumjs/wallet.Let's verify if this method is part of the public API:
🌐 Web query:
What is the recommended method to get address string in @ethereumjs/wallet?💡 Result:
To retrieve an Ethereum address string using
@ethereumjs/wallet, there are two primary methods depending on whether you need a checksummed address:
Standard Address (Lowercase)
UsegetAddressString()to obtain a "0x"-prefixed hex string:const address = wallet.getAddressString(); // Returns "0x..." lowercaseChecksum Address (EIP-55)
For an EIP-55 compliant checksum address that helps prevent typos/errors:const checksumAddress = wallet.getChecksumAddressString(); // Returns mixed-case like "0x5aAeb..."Key Implementation Details
- Both methods internally convert raw byte data to hexadecimal strings[2][6]
- Checksum addresses use capitalization patterns to encode validity (via keccak256 hash of lowercase address)[4][8]
- Underlying address generation uses ECDSA public key derivation from private keys[1][4]
For most applications requiring user-facing addresses or interoperability with tools like Ethers.js/Web3.js,
getChecksumAddressString()is recommended due to its built-in error detection[4][8]. UsegetAddressString()only when lowercase representation is explicitly required[6][8].Citations:
- 1: https://www.quicknode.com/guides/ethereum-development/wallets/how-to-generate-a-new-ethereum-address-in-javascript
- 2: https://github.com/ethereumjs/ethereumjs-wallet/blob/master/src/index.ts
- 3: https://www.npmjs.com/package/ethereumjs-wallet/v/0.6.5
- 4: https://docs.ethers.org/v5/api/utils/address/
- 5: https://classic.yarnpkg.com/en/package/ethereumjs-wallet
- 6: https://www.npmjs.com/package/ethereumjs-wallet/v/0.6.4
- 7: https://github.com/ethereumjs/ethereumjs-wallet
- 8: Wallet.getAddressString() returns all lower case string causing checksum to fail during signing ethereumjs/ethereumjs-wallet#76
- 9: https://unpkg.com/browse/[email protected]/dist/index.d.ts
Address Retrieval API Update Verified
The use of
wallet.getAddressString()to obtain the lowercase, 0x-prefixed Ethereum address is confirmed to align with the public API of@ethereumjs/wallet. Note that if a checksummed (EIP-55 compliant) address is required for user-facing contexts, consider usinggetChecksumAddressString()instead.
- File:
packages/extension/src/ui/action/views/import-account/views/import-account-password.vue(Line 116)packages/extension/src/ui/action/views/import-account/views/import-account-private-key.vue (2)
39-39: Consistent package migration across componentsThe import statement has been updated to use
@ethereumjs/wallet, maintaining consistency with the changes inimport-account-password.vue.
96-96: Consistent method usage for address retrievalThe address retrieval method has been updated to use
getAddressString(), maintaining consistency with the changes inimport-account-password.vue.packages/extension/vite.config.ts (1)
73-73:❓ Verification inconclusive
Verify the necessity of the 'os' module polyfill.
The addition of the 'os' module to polyfills suggests browser-side usage of Node.js OS functionality. Let's verify where this is needed.
🏁 Script executed:
#!/bin/bash # Search for usage of the 'os' module in the codebase rg -l "require\(['\"]os['\"]\)|from ['\"]os['\"]\||import.*['\"]os['\"]\||window\.os"Length of output: 99
Action: Manually Verify the ‘os’ Polyfill Necessity
The automated search did not return any clear usage of the Node.js built-in ‘os’ module across the codebase. Please manually verify whether browser-side features rely on this polyfilled functionality. If no such usage exists, consider removing the polyfill from
packages/extension/vite.config.ts(line 73) to avoid unnecessary overhead.packages/extension/tsconfig.node.json (2)
13-16: LGTM! Comprehensive include patterns added.The additional include patterns ensure proper TypeScript compilation for source files and Vue components.
24-28: LGTM! Well-structured path aliases.The path mappings follow TypeScript best practices and will improve module imports readability.
packages/types/package.json (1)
27-41:❓ Verification inconclusive
Verify compatibility of major version updates.
Several dependencies have significant version updates. Please ensure compatibility, particularly:
- eslint ^9.20.0 (major version update)
- typescript ^5.7.3
- typescript-eslint 8.23.0
🌐 Web query:
What are the breaking changes in ESLint 9.x compared to 8.x?💡 Result:
ESLint v9.x introduces several significant breaking changes compared to v8.x, primarily focused on modernizing configurations, improving performance, and aligning with ecosystem standards. Here's a structured breakdown:
Configuration System Overhaul
- Flat config as default: Replaces
.eslintrc.*files witheslint.config.js(array-based structure), improving modularity and performance[4][5].- Legacy config deprecation: Support for
.eslintrc.*files will be fully removed in ESLint v10[4].- Stricter rule schemas: Rules without explicit
meta.schemanow assume no options by default ([]), causing validation failures if options are provided[1][3].
Environment & Compatibility
- Node.js version requirements: Dropped support for Node.js < v18.18.0 and v19[3][5].
- Removed formatters: Legacy formatters like
checkstyle,junit, andunixare removed; use standalone packages instead[3][5].- Deprecated rules:
- Removed:
valid-jsdoc,require-jsdoc(useeslint-plugin-jsdoc)[3][5].- Updated:
no-inner-declarations,no-unused-vars, and others with stricter defaults[3][5].
CLI & Performance Changes
Change v8 Behavior v9 Behavior --quietRan all rules but hid warnings Skips executing rules set to "warn", improving speed[1][3][5]--output-fileSkipped writing if output empty Always writes file (even empty)[3][5] Configuration comments Multiple comments allowed (last one applied) First comment applied; others trigger errors[3][5]
Rule-Specific Breaking Changes
Inline configuration adjustments:
- Comments like
/* eslint semi: "warn" */now retain options from config files (previously overrode them)[3][5].- Stricter parsing of
/* exported */: Invalid syntax (e.g., colons) triggers errors[3].Schema updates:
no-implicit-coercion: Flags new cases (e.g.,foo - 0) by default[3].no-restricted-imports: Accepts multiple entries with same name[3][5].Scope analysis fixes:
- Improved strict mode directive detection[5].
Plugin/Integration Impact
- Removed API methods: Deprecated functions like
sourceCode.getComments()and legacy rule formats are dropped[3][6].- Code path analysis: Precalculated code paths replace dynamic evaluation; removed
CodePath#currentSegments[1][3][6].
Migration Steps
- Upgrade Node.js to ≥v18.18.0 or ≥v20.x.
- Replace
.eslintrc.*witheslint.config.js[4].- Use
npm-check-updatesto update dependencies[4].For detailed guidance, refer to ESLint’s official migration guide[3][5].
Citations:
- 1: https://eslint.org/blog/2023/11/whats-coming-in-eslint-9.0.0/
- 2: https://eslint.org/docs/latest/use/migrate-to-8.0.0
- 3: https://eslint.org/docs/latest/use/migrate-to-9.0.0
- 4: https://vueschool.io/articles/vuejs-tutorials/upgrading-eslint-from-v8-to-v9-in-vue-js/
- 5: https://eslint.org/blog/2024/04/eslint-v9.0.0-released/
- 6: ESLint v9 contains breaking API changes jsx-eslint/eslint-plugin-react#3699
Action: Confirm Dependency Compatibility with ESLint 9.x and TypeScript 5.7.3
Please verify that the updated dependency versions have been fully evaluated for breaking changes. In particular:
ESLint v9.x:
- Review your ESLint configuration to ensure compatibility with the new flat configuration approach (i.e., the migration from legacy
.eslintrc.*files toeslint.config.jsif applicable).- Confirm that our Node.js version meets the minimum requirements (≥ v18.18.0).
- Check that any stricter rule validations (e.g., updated rule schemas) introduced in v9.x do not disrupt our setup.
TypeScript & Typescript-ESLint:
- Verify that TypeScript 5.7.3 works seamlessly with our current configuration.
- Ensure that using both the scoped packages (
@typescript-eslint/eslint-pluginand@typescript-eslint/parserat ^5.62.0) alongside the standalonetypescript-eslintat 8.23.0 does not lead to conflicts.Please double-check these points to ensure that all major version updates integrate smoothly with our codebase.
packages/storage/package.json (1)
30-45:❓ Verification inconclusive
Verify Vitest major version upgrade impact.
The update from Vitest 2.x to 3.x (^3.0.5) is a major version change that may include breaking changes.
🌐 Web query:
What are the breaking changes in Vitest 3.0?💡 Result:
Vitest 3.0 introduces several breaking changes that developers should be aware of when upgrading from previous versions. Here are the key breaking changes:
API and Behavior Changes
spy.mockResetnow restores original implementations
Previously resetting mocks left implementations as no-op functions[7]. NowmockReset()reverts to the original method implementation[1][7].
vi.spyOnreuses existing mocks
Subsequent calls to spy on already-mocked methods now reuse existing spies instead of creating new ones[1][3][7]. This prevents unexpected behavior when restoring mocks.Stricter error comparisons
Error equality checks (toEqual/toThrowError) now compare:
- Error prototypes (e.g.,
TypeErrorvsError)[7]name,message,cause, andAggregateError.errorsproperties[3][7]- Asymmetric
causeproperty checks[7]Configuration Changes
Browser testing configuration
Deprecatedbrowser.nameandbrowser.providerOptionsin favor of newbrowser.instancesarray for multi-browser testing[4][7].Coverage defaults
Test files are now excluded from coverage reports by default viacoverage.exclude[1][3].Vite 6 compatibility
Requires Vite 6+ with updated module resolution behavior (no longer resolvesmodulecondition by default)[1][7].Type System Changes
- Deprecated
Customtype
TheCustomtype alias has been replaced with standardTesttype[7]. Use newRunnerCustomCase/RunnerTestCasetypes instead[7].Other Notable Changes
Fake timers upgrade
Updated to@sinonjs/fake-timers@14with potential behavior changes[1][3].Test context inheritance
Hooks now receive full context object rather than partial data[1][3].Workspace configuration
New inline workspace configuration format replaces some legacy patterns[4][7].For a smooth migration:
- Review test cases using spies/mocks
- Update browser testing configurations
- Verify error comparisons
- Check coverage report configurations
- Consult the official migration guide[7] for detailed code examples
Most projects should be minimally affected if not using advanced mocking patterns or custom browser configurations[4][7]. The Vitest team provides codemods for common migration scenarios[4].
Citations:
- 1: https://github.com/vitest-dev/vitest/releases
- 2: https://vite.dev/blog/announcing-vite3
- 3: https://newreleases.io/project/github/vitest-dev/vitest/release/v3.0.0
- 4: https://vitest.dev/blog/vitest-3
- 5: https://github.com/vitest-dev/vitest/milestone/19
- 6: https://www.npmjs.com/package/@vitest/browser/v/3.0.0-beta.2
- 7: https://main.vitest.dev/guide/migration
- 8: https://www.npmjs.com/package/vitest?activeTab=versions
- 9: https://wallabyjs.com/docs/v1/intro/whatsnew.html
- 10: https://www.speakeasy.com/post/vitest-vs-jest
Action Required: Verify Impact of Vitest 3.0 Upgrade
The dependency update to Vitest 3.0 (^3.0.5) introduces several breaking changes that could affect how tests run, especially if advanced mocking or browser testing configurations are in use. Please review the following points:
Mocking Behavior:
spy.mockResetnow restores the original implementation, which may change the expected behavior of your mocks.vi.spyOnwill reuse existing mocks. Verify that this new behavior does not impact tests that assume fresh spies.Error Comparisons:
- Stricter comparison rules now check error prototypes and key properties (
name,message,cause, etc.). Ensure that tests usingtoEqualortoThrowErrorreflect these changes.Configuration Adjustments:
- Browser testing configuration has changed (e.g., deprecated options replaced by new
browser.instancesarray).- Default coverage exclusions now omit test files.
- Compatibility with Vite 6+ is required, which might impact module resolution.
Other Changes:
- Updated fake timers and modifications to test context inheritance may require adjustments if these features are in use.
Please consult the official migration guide for detailed information and adjust your tests and configurations as necessary.
Relevant file change:
packages/storage/package.json(lines 30-45)packages/name-resolution/package.json (1)
52-52:✅ Verification successful
Verify compatibility with updated UnstoppableDomains resolution package.
The @unstoppabledomains/resolution package has been updated to ^9.3.3.
🌐 Web query:
Are there any breaking changes in @unstoppabledomains/resolution 9.3.3?💡 Result:
The provided search results do not mention any breaking changes specifically for version 9.3.3 of
@unstoppabledomains/resolution. However, several major breaking changes are documented in earlier versions:Key Breaking Changes in Earlier Versions
Version 5.0.0 ([source][7]):
- Configuration Renaming: The
cnsconfiguration parameter was renamed touns(e.g.,new Resolution({ sourceConfig: { uns: {...} } })).- Method Renaming:
Resolution#fromEip1193Provider→Resolution#fromEthereumEip1193Provider.- Factory Method Changes: All factory methods now require
unsinstead ofcnsconfigurations.- Async Updates:
Resolution#isSupportedDomainbecame asynchronous.Java SDK Version 3.0.0 ([source][10]):
- Replaced
NamingServiceType.CNSwithNamingServiceType.UNS.- Removed deprecated methods like
getUsdt,addr, andnamehash, replacing them with newer equivalents (e.g.,getMultiChainAddress,getAddress,getNamehash).Missing Information for 9.3.3
No search results explicitly reference version 9.3.3. For details on this specific version, consult:
- The library’s GitHub CHANGELOG
- Official NPM release notes.
Citations:
- 1: https://unstoppabledomains.github.io/resolution/v1.8.0/index.html
- 2: https://docs.unstoppabledomains.com/resolution/sdks-and-libraries/cli/
- 3: https://github.com/unstoppabledomains/resolution-swift
- 4: https://www.npmjs.com/package/@unstoppabledomains/resolution/v/6.0.0
- 5: https://docs.unstoppabledomains.com/resolution/overview/
- 6: https://www.linknovate.com/affiliation/ibm-1484/all/?query=convert+chinese+audio
- 7: https://github.com/unstoppabledomains/resolution/blob/master/CHANGELOG.md
- 8: https://docs.unstoppabledomains.com/smart-contracts/quick-start/resolve-domains/
- 9: https://unstoppabledomains.github.io/resolution/v1.17.0/index.html
- 10: https://github.com/unstoppabledomains/resolution-java/blob/master/CHANGELOG.md
Dependency Check: @unstoppabledomains/resolution 9.3.3 – No Breaking Changes Detected
The web query results indicate that there are no reported breaking changes for version 9.3.3. Although earlier versions introduced some breaking changes (e.g., configuration renaming and method updates), none of these affect the 9.3.3 update.
- The dependency update to version 9.3.3 appears safe.
- For full assurance, please verify against the official CHANGELOG and NPM release notes.
packages/signers/kadena/package.json (1)
31-31:✅ Verification successful
Verify Polkadot util-crypto compatibility.
The @polkadot/util-crypto package has been updated to ^13.3.1.
🌐 Web query:
What are the latest changes in @polkadot/util-crypto 13.3.1?💡 Result:
The latest changes in @polkadot/util-crypto v13.3.1 include:
Compatibility Updates
- Node.js v22 support: Added compatibility adjustments for Node.js v22 environments[2][5][7].
Fixes
getSeparatorfunction: Fixed an issue related totoLocaleStringformatting inconsistencies[2][5].Dependency Upgrades
- Internal package alignment: Updated dependencies across the Polkadot-js ecosystem for consistency[5][7], including upgrades to
@polkadot/common[5].These updates focus on maintaining compatibility with modern Node.js versions and resolving minor functional inconsistencies in utility functions[2][5][7].
Citations:
- 1: https://classic.yarnpkg.com/en/package/@polkadot/networks
- 2: https://raw.githubusercontent.com/polkadot-js/util/master/CHANGELOG.md
- 3: https://polkadot.com/newsroom/press-releases/page/1
- 4: https://github.com/polkadot-js/api/blob/master/CHANGELOG.md
- 5: https://raw.githubusercontent.com/polkadot-js/ui/master/CHANGELOG.md
- 6: https://stealthex.io/blog/polkadot-dot-price-prediction/
- 7: https://www.npmjs.com/package/@polkadot/util-crypto
- 8: https://newreleases.io/project/npm/@polkadot/util-crypto/release/9.2.1
- 9: https://addons.mozilla.org/en-US/firefox/addon/polkadot-js-extension/versions/
- 10: https://github.com/polkadot-js/common
Polkadot util-crypto Compatibility Confirmed
The update to version 13.3.1 primarily adds Node.js v22 support, fixes minor issues (e.g., in
getSeparator), and aligns internal dependencies. There’s no indication of breaking changes that affect our usage in the Kadena signer package, so no additional modifications are required.packages/request/package.json (1)
30-30:❓ Verification inconclusive
Verify breaking changes in uuid v11.
The uuid package has been upgraded from v10 to v11, which is a major version bump and may include breaking changes.
🌐 Web query:
What are the breaking changes in uuid v11 compared to v10?💡 Result:
The transition from uuid v10 to v11 introduced several breaking changes primarily focused on modernization and improved type safety. Here are the key differences:
Major Breaking Changes
1. TypeScript Integration
- The library was rewritten in TypeScript[1][3][7][10], requiring adjustments for users previously relying on
@types/uuid(now obsolete)[5][10].- Deep imports like
require('uuid/v4')are fully deprecated[7][10].2. Node.js Version Requirements
- Dropped support for Node.js versions below 16.x[7][10].
- New minimum: Only Node 16-20 supported[1][3][7].
3. Internal State Handling Changes
Version Behavior Without Options Behavior With Options ≤v10 Uses internal state Modifies internal state v11 Uses internal state Ignores internal state[5][7] This affects timestamp-based UUIDs (v1/v6/v7) when passing custom options[5][7].
4. Browser Support Changes
- Dropped IE11/Safari 10 compatibility[10].
- Removed fallback to
msCrypto[10].5. Build Artifacts
- UMD/minified builds removed from package[7][10].
- ECMAScript Module (ESM) becomes primary format[7].
Additional Breaking Changes
v4()no longer defaults options parameter[1][3]- Binary UUIDs now use
Uint8Arrayinstead ofBuffer[5][7]- Removed deprecated default export[7][10]
These changes aim to improve type safety and align with modern JavaScript practices while maintaining RFC 9562 compliance[4][6]. Developers should test UUID generation patterns involving custom options or legacy browser environments.
Sources: [1][3][5][7][10]
Citations:
- 1: https://gitlab.duraken.com/fitness-providers/fitness-providers/-/merge_requests/1749
- 2: https://foundryvtt.com/article/migration/
- 3: https://git.fitko.de/fit-connect/fit-connect-tools/-/merge_requests/241
- 4: https://www.uuidtools.com/uuid-versions-explained
- 5: https://www.npmjs.com/package/uuid
- 6: https://en.wikipedia.org/wiki/Universally_unique_identifier
- 7: https://github.com/uuidjs/uuid/releases
- 8: https://duo.com/labs/tech-notes/breaking-down-uuids
- 9: https://lists.apache.org/api/plain?thread=qvmrx8mvjtrf3tx5lvgxnqnz024qlndj
- 10: https://github.com/uuidjs/uuid/blob/main/CHANGELOG.md
Action Required: Verify Implementation of uuid v11 Breaking Changes
The dependency upgrade to uuid v11 introduces several breaking changes that require careful verification in your code:
TypeScript Integration & Deep Imports:
Ensure that any deep imports (e.g.,require('uuid/v4')) have been removed and that any reliance on@types/uuidis discontinued since the package is now fully written in TypeScript.Node.js Version Requirement:
Confirm that the runtime environment meets the new minimum requirement (Node 16+).API & Internal State Handling:
Audit calls to functions likev4()to verify that they correctly handle the new behavior—such as the absence of default options—and check for any impacts on custom options for timestamp-based UUIDs (v1/v6/v7).Browser and Build Considerations:
If applicable, ensure that your client-side code or build configuration complies with the removal of UMD/minified builds and the shift to ESM, as well as dropped support for older browsers (IE11/Safari 10).The dependency declaration in
packages/request/package.jsonat line 30 remains:"uuid": "^11.0.5",Please verify that the rest of the codebase addresses these changes appropriately.
packages/utils/package.json (1)
27-27:❓ Verification inconclusive
Coordinated update of Polkadot ecosystem packages.
The @polkadot/util-crypto package has been updated to ^13.3.1. This version aligns with other Polkadot ecosystem package updates across the project, maintaining compatibility.
Verify Node.js compatibility.
The package requires Node.js >= 14.15.0, but @types/node is being updated to ^22.13.1. This suggests the minimum Node.js version requirement might need to be updated.
Also applies to: 33-33
🏁 Script executed:
#!/bin/bash # Check the Node.js version requirements in package.json files rg -A 1 '"node":\s*">=.*"' --type jsonLength of output: 1215
Update Review: Coordinated Package Update & Node.js Compatibility Check
- The coordinated update of @polkadot/util-crypto to ^13.3.1 is in line with the other Polkadot ecosystem package updates.
- Verification confirms that all package.json files (including packages/utils/package.json) still specify a Node.js runtime of >=14.15.0.
- Since @types/node is now updated to ^22.13.1, please double‑check that the current minimum Node.js version is adequate for the new type definitions. This review comment applies both to line 27 and line 33 of packages/utils/package.json.
packages/signers/polkadot/package.json (1)
27-28: Coordinated update of Polkadot ecosystem packages.Both @polkadot/util and @polkadot/util-crypto have been updated to ^13.3.1, maintaining version parity between these interdependent packages.
packages/extension-bridge/package.json (1)
42-42:❓ Verification inconclusive
Verify breaking changes in serialize-error v12.0.0.
The update from serialize-error v11.0.3 to v12.0.0 is a major version change that might include breaking changes.
🌐 Web query:
What are the breaking changes in serialize-error v12.0.0?💡 Result:
The
serialize-errorpackage version 12.0.0 introduced several key changes:Breaking Changes
Custom Error Constructors Requirement
- When using
addKnownErrorConstructor, custom error classes must have a parameterless constructor or adding them will throw an error[4].- Previously supported custom errors requiring constructor arguments became incompatible.
.toJSON()Handling
deserializeErrornow invokes.toJSON()by default when present (useToJSON: true)[4]. This alters behavior for objects with custom serialization logic:// In v12+, this returns {custom: 'data'} instead of original properties deserializeError({ message: 'test', toJSON: () => ({custom: 'data'}) });Other Notable Changes
- Added
isErrorLike()helper to check for error-like objects[4]- Improved circular reference handling during (de)serialization[1][4]
- Buffer properties now serialize as
[object Buffer][1][4]These changes improve consistency but require updates for codebases using parameterized custom errors or relying on previous
.toJSON()behavior during deserialization[1][4].Citations:
- 1: https://www.npmjs.com/package/serialize-error/v/9.1.1
- 2: https://docs.python-telegram-bot.org/en/v12.0.0/changelog.html
- 3: https://gregsdennis.github.io/Manatee.Json/release-notes.html
- 4: https://github.com/sindresorhus/serialize-error
- 5: http://sst-simulator.org/SSTPages/SSTmicroRelease_V12dot0dot0/
- 6: https://nodejs.org/api/all.html
- 7: https://nodejs.org/en/blog/release/v12.0.0
- 8: https://nodejs.org/download/v8-canary/v12.0.0-v8-canary20190101a0c8d14525/docs/api/v8.html
- 9: https://docs.developers.optimizely.com/content-management-system/docs/breaking-changes-cms-11
- 10: https://electronjs.org/docs/latest/breaking-changes
Action Required: Confirm Compatibility with Breaking Changes in serialize-error v12.0.0
The update to version 12.0.0 introduces two notable breaking changes:
Custom Error Constructors Requirement:
If you’re usingaddKnownErrorConstructor, ensure that your custom error classes have parameterless constructors. Custom errors that previously required constructor arguments will now throw an error..toJSON() Handling in deserializeError:
ThedeserializeErrorfunction now invokes.toJSON()by default (withuseToJSON: true). This change may modify the serialized output for errors with custom serialization logic.Please verify that your error handling and any custom error implementations in the codebase accommodate these changes.
File Reference:
packages/extension-bridge/package.json(Line 42)packages/swap/package.json (1)
27-28:❓ Verification inconclusive
Verify compatibility of updated Solana dependencies.
Several Solana-related packages have been updated:
- @solana/spl-token: ^0.4.9 -> ^0.4.12
- @solana/web3.js: ^1.95.4 -> ^1.98.0
- rango-sdk-basic: ^0.1.58 -> ^0.1.62
- uuid: ^10.0.0 -> ^11.0.5
The uuid update is a major version change that might include breaking changes.
Also applies to: 34-34, 36-36
🌐 Web query:
What are the breaking changes in uuid v11.0.0?💡 Result:
The UUID library version 11.0.0 introduced several breaking changes, primarily focused on modernization and internal refactoring:
Core Breaking Changes
Refactored v1/v7 internals
Internal state management for UUID versions 1 (time-based) and 7 (time-ordered) was overhauled[1][4][7][10]. Existing code relying on these implementations may require updates.TypeScript port
The library was rewritten in TypeScript[1][4][7][10], potentially affecting type declarations in JavaScript projects.Node.js version support
Dropped support for Node.js <16.x (now requires Node.js 16–20)[1][4][7][10].Build & Browser Changes
UMD build removed
The minified browser build (dist/umd/uuid.min.js) was eliminated[1][10]. Users must switch to ESM/CommonJS or modern bundlers.Legacy browser support dropped
IE11 and Safari <10 are no longer supported[1][10]. Modern browsers with ES2015+ compliance are required.API Changes
// Before (deprecated) const uuid = require('uuid/v4'); // After (recommended) import { v4 as uuidv4 } from 'uuid';
Deep requires deprecated
Patternrequire('uuid/v4')is unsupported[1][10]. Use named imports instead.Default export removed
import uuid from 'uuid'no longer works[1][10]. Use version-specific imports likeimport {v4}.Security Changes
- Insecure browser RNG removed
Fallback random number generators for insecure browser environments were eliminated[1][10]. Users must explicitly provide an RNG if needed.Miscellaneous
- V3/V5 UUID generation
Support removed for Node.js <4.x[1][10]- ECMAScript Modules
Primary distribution now uses ESM with a CommonJS fallback[1][10].Projects upgrading should test UUID generation paths thoroughly and update import statements/Node.js versions first[2][4]. The TypeScript migration may require adjustments to build pipelines or type definitions[7][10].
Citations:
- 1: https://github.com/uuidjs/uuid/releases
- 2: https://php.libhunt.com/uuid-changelog
- 3: https://pub.dev/packages/uuid/changelog
- 4: https://gitlab.duraken.com/fitness-providers/fitness-providers/-/merge_requests/1749
- 5: https://gitlab.edc4it.com/labs/spice-server-node/-/merge_requests/19
- 6: https://pkg.go.dev/github.com/gofrs/uuid
- 7: https://lists.apache.org/api/plain?thread=qvmrx8mvjtrf3tx5lvgxnqnz024qlndj
- 8: https://gitnet.fr/deblan-mirror/borgwarehouse/commit/6ee8ab288a7c0a63bd65f73160ca70dd41bef4f4
- 9: https://hexdocs.pm/elixir_uuid/changelog.html
- 10: https://github.com/uuidjs/uuid/blob/main/CHANGELOG.md
Dependency Compatibility Check: Updated Solana and uuid Packages
Solana Packages:
- @solana/spl-token: Updated from ^0.4.9 to ^0.4.12
- @solana/web3.js: Updated from ^1.95.4 to ^1.98.0
Please confirm that there are no breaking changes affecting your use of these libraries.uuid Package:
- Updated from ^10.0.0 to ^11.0.5, which is a major version change.
- Breaking Changes in uuid v11.x include:
- Removal of the default export; if you previously used
import uuid from 'uuid'orrequire('uuid/v4'), update to named imports (e.g.,import { v4 as uuidv4 } from 'uuid').- Internal API refactors for UUID versions 1 and 7.
- Dropped support for Node.js below v16 and removal of legacy UMD/browser builds.
Verify that every instance where uuid is used in the codebase is compliant with these changes.Additional References:
- Ensure that similar compatibility checks are performed for the updated rango-sdk-basic (from ^0.1.58 to ^0.1.62).
- Note that the changes at lines 34 and 36 also need to be confirmed for consistency.
Please verify that these dependency updates have been fully tested and that any necessary code adjustments (such as updating import statements for uuid) are in place.
packages/hw-wallets/package.json (2)
55-57:✅ Verification successful
Verify compatibility of Ledger ecosystem updates.
Multiple Ledger-related packages have been updated:
- @ledgerhq/hw-app-btc: ^10.4.3 -> ^10.5.0
- @ledgerhq/hw-app-eth: ^6.40.3 -> ^6.42.5
- @ledgerhq/live-common: ^34.13.1 -> ^34.20.0
Let's verify there are no known issues with these versions.
Also applies to: 60-60
🏁 Script executed:
#!/bin/bash # Check for security advisories in Ledger packages gh api graphql -f query=' { securityVulnerabilities(first: 5, ecosystem: NPM, package: "@ledgerhq/hw-app-btc") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } }'Length of output: 353
Ledger package updates verified: No immediate issues detected
The security query for
@ledgerhq/hw-app-btc(^10.5.0) returned no vulnerabilities, and the version bumps for@ledgerhq/hw-app-ethand@ledgerhq/live-commonalso appear consistent with current Ledger ecosystem updates. Please ensure that standard integration and device-specific tests are executed to further confirm compatibility.
- packages/hw-wallets/package.json (lines 55-57 & 60):
@ledgerhq/hw-app-btc: ^10.4.3 → ^10.5.0 — verified with no known security advisories.@ledgerhq/hw-app-eth: ^6.40.3 → ^6.42.5 — recommend routine testing.@ledgerhq/live-common: ^34.13.1 → ^34.20.0 — recommend routine testing.
61-62:❓ Verification inconclusive
Verify compatibility of Polkadot ecosystem updates.
The Polkadot-related packages have significant version changes:
- @polkadot/types: ^14.3.1 -> ^15.5.2 (major version update)
- @polkadot/util: ^13.2.3 -> ^13.3.1
🌐 Web query:
What are the breaking changes in @polkadot/types v15.0.0?💡 Result:
The @polkadot/types v15.0.0 release introduced several breaking changes impacting developers:
1. TypeScript Augmentation Changes
- Explicit Augmentation Required: Substrate-specific type augmentation is no longer applied by default for TypeScript users. Developers must add:
at their codebase entry point to restore Substrate type definitions[4][7].import '@polkadot/api-augment';
2. Contract Interface Adjustments
- Mandatory Options Objects: All
api-contractconstruction and query methods now require an options object[1].- Storage Deposit Detection: Contract interfaces won't decorate methods if
storageDepositLimitisn't detected in runtime parameters[1].
3. Signer Payload Modifications
- HexString Conversion:
SignerPayloadJSONnow returns values asHexStringinstead of raw bytes to simplify cross-tool compatibility[1][7].- Payload Alteration Flag: Added
allowCallDataAlterationtoSignatureOptions/SignerOptions, defaulting totrue. This allows external signers (e.g., hardware wallets) to modify payloads[1][7].
4. Metadata V15 Compatibility
- Structural Changes: Metadata V15 removes redundant pallet-specific metadata types (
PalletCallMetadata,PalletEventMetadata, etc.), consolidating them into outer enums likeRuntimeCallandRuntimeEvent[6].- Type Overrides Required: Chains using non-default metadata formats may need explicit type overrides for compatibility[6][8].
5. Deprecated Method Removals
- RxJS Methods: Removed deprecated RxJS-based methods (e.g.,
api.rx.call.*) in favor of Promise-based alternatives[1].- Legacy Derive Functions: Methods like
api.derive.staking.nextElectedwere updated to use newer substrate APIs[1].
6. Runtime API & Codec Updates
- Type Decoding Fixes: Adjusted decoding logic for nested types (e.g.,
Vec<Option<X>>) and fixed issues with compact decoding in byte streams[1].- Error Handling: Dispatch errors now use raw byte arrays (
[u8; 4]) instead of mapped types[1].
Key Upgrade Recommendations:
- Add explicit type imports (
@polkadot/api-augment) for TS projects.- Audit contract interactions for mandatory options objects.
- Test signer integrations with the new payload alteration flag.
- Review metadata handling for chains targeting V15[6][7].
Citations:
- 1: https://classic.yarnpkg.com/en/package/@polkadot/types-support
- 2: https://github.com/paritytech/polkadot/releases
- 3: https://www.npmjs.com/package/@substrate/api-sidecar
- 4: https://polkadot.js.org/docs/api/FAQ
- 5: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/commits/b581604aa7a042d596029af1395446bc726d7ae9/substrate/client/finality-grandpa/rpc
- 6: https://forum.polkadot.network/t/stablising-v15-metadata/2819
- 7: https://github.com/polkadot-js/api/releases
- 8: Metadata V15 breaking change: Features to include in V15 paritytech/substrate#12939
- 9: https://www.npmjs.com/package/@substrate/api-sidecar/v/17.3.4
- 10: https://forum.polkadot.network/t/april-updates-for-substrate-and-polkadot-devs/2764
Action Required: Confirm Compatibility with Breaking Changes in @polkadot/types
The update from
^14.3.1to^15.5.2for@polkadot/typesintroduces several breaking changes that may affect your implementation:
- TypeScript Augmentation: If your project relies on substrate-specific types, ensure you include
import '@polkadot/api-augment';in your entry point.- Contract Interface Adjustments: Verify that any calls to contract methods now correctly supply the mandatory options objects.
- Signer Payload & Metadata Updates: Review usage of signer payloads and metadata handling, as these areas have undergone changes that could impact behavior.
Although the update to
@polkadot/utilis minor (^13.2.3to^13.3.1), please perform a similar review to ensure no side effects.package.json (1)
35-42: LGTM! Development tooling updates look good.The updates to development dependencies (@commitlint/cli, @commitlint/config-conventional, @swc/core, concurrently, husky, nodemon) are minor version changes and should not introduce breaking changes.
packages/keyring/package.json (1)
32-32: LGTM! Minor version update for @polkadot/util.The update from ^13.2.3 to ^13.3.1 is a minor version change and should maintain backward compatibility.
packages/extension/package.json (4)
119-119:✅ Verification successful
Review specified versions for accuracy.
Some development dependency versions appear to be incorrect or ahead of their latest stable releases:
eslint: ^9.20.0 (latest stable is 8.x)typescript: ~5.7.3 (latest stable is 5.3.x)vite: ^6.1.0 (very recent major version)Also applies to: 133-133, 135-135
🌐 Web query:
What are the latest stable versions of ESLint, TypeScript, and Vite?💡 Result:
As of February 13, 2025:
ESLint
- Latest stable version: v9.20.1
Released on February 11, 2025[9][5]. This minor update includes bug fixes and new features like enhanced configuration system improvements[1][5].TypeScript
- Latest stable version: v5.7.3
Released as a patch update with critical fixes[10]. The TypeScript team continues focusing on type-checking precision and ECMAScript standard support[2][6].Vite
- Latest stable version: v6.x
Vite 6 launched on November 26, 2024[3][7], featuring ecosystem growth (Vitest adoption) and compatibility with modern frameworks like TanStack Start and Ember[3]. Weekly npm downloads doubled from 7.5M to 17M since Vite 5’s release[3].
Key updates:
- ESLint v9.x now supports language plugins for Markdown/JSON/CSS[1][4].
- TypeScript v5.x series emphasizes stability after major features in earlier releases[2][6].
- Vite’s support policy ensures backported fixes for versions like v4.x/v5.x alongside v6.x[7].
Upgrade paths are documented for all tools via official migration guides[1][3][7].
Citations:
- 1: https://eslint.org/blog/2025/01/eslint-2024-year-review/
- 2: https://effectivetypescript.com/2024/07/02/ts-55/
- 3: https://vite.dev/blog/announcing-vite6
- 4: https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/
- 5: https://eslint.org/blog/2024/09/eslint-v8-eol-version-support/
- 6: https://devblogs.microsoft.com/typescript/
- 7: https://vite.dev/releases
- 8: https://github.com/typescript-eslint/typescript-eslint/releases
- 9: https://www.npmjs.com/package/eslint
- 10: https://github.com/microsoft/typescript/releases
Dependency versions are confirmed as current and accurate.
Based on the latest stable releases as of February 2025:
- ESLint: The project uses
^9.20.0, which aligns with the current stable release (v9.20.1).- TypeScript: The specified version
~5.7.3matches the latest stable version.- Vite: The
^6.1.0version is consistent with the stable v6.x series.All versions have been verified against the latest stable releases, and no discrepancies were found. Please continue monitoring for any post-release updates specific to Vite, though current stability is well supported.
- Affected file:
packages/extension/package.json(Lines: 119, 133, 135)
80-82:❌ Incorrect review comment
Check Vue ecosystem version compatibility.
There appear to be inconsistencies in Vue-related package versions:
vue: ^3.5.13 (this version doesn't exist - latest Vue 3 is 3.4.x)vue-router: ^4.5.0vue-tsc: ^2.2.0Also applies to: 139-139
🌐 Web query:
What is the latest stable version of Vue.js 3?💡 Result:
The latest stable version of Vue.js 3 is 3.5.13, released on November 15, 2024[4][7][10]. This version includes performance optimizations to the reactivity system and resolves memory issues from previous releases[8].
Key details about Vue.js versions:
- Active Support: Version 3.5.x currently receives active maintenance[4][6]
- LTS Policy: Each major release's last minor version becomes LTS for 18 months[4]
- Installation:
npm install vueautomatically fetches the latest stable version (3.5.x)[1][7]The framework follows a flexible release cycle with minor updates typically every 3-6 months and major versions announced well in advance[4][6]. Commercial support remains available for Vue 2.x through third-party providers[4].
Citations:
- 1: https://blog.vuejs.org/posts/vue-3-as-the-new-default
- 2: https://tsh.io/blog/vue-new-features/
- 3: https://www.tatvasoft.com/outsourcing/2022/09/vue-3-installation-guide.html
- 4: https://endoflife.date/vue
- 5: https://www.monterail.com/blog/whats-new-in-vue-3-the-most-interesting-new-features
- 6: https://en.wikipedia.org/wiki/Vue.js
- 7: https://www.npmjs.com/package/vue?activeTab=versions
- 8: https://blog.vuejs.org/posts/vue-3-5
- 9: https://github.com/vuejs/core/blob/main/CHANGELOG.md
- 10: https://github.com/vuejs/core/releases
Vue Ecosystem Versions Checked
After verification, note the following:
"vue": "^3.5.13"is correct—Vue 3.5.13 is indeed the latest stable release.- Please ensure that
"vue-router": "^4.5.0"and"vue-echarts": "7.0.3"remain compatible with Vue 3.5.13.- If
"vue-tsc": "^2.2.0"is used elsewhere, double-check that its version aligns with Vue 3.5.13.Also applies to line 139.
Likely an incorrect or invalid review comment.
26-58:❓ Verification inconclusive
Verify the scope of dependency updates.
The extensive updates to blockchain-related packages (@kadena, @PolkaDot, @Solana) seem broader than necessary for a paste window fix. Some updates involve major version changes that could introduce breaking changes.
Please confirm:
- Are these updates related to the paste window fix?
- Have you tested the application with these new versions?
- Are there any breaking changes in the major version updates?
Run this script to check for breaking changes in the updated packages:
🏁 Script executed:
#!/bin/bash # Description: Check for breaking changes in updated packages # Check npm for release notes and breaking changes for pkg in "@polkadot/api" "@solana/web3.js" "@kadena/client"; do echo "Checking $pkg..." npm view $pkg changes --json | jq '.' doneLength of output: 524
Dependency Updates Scope Verification
- The updated packages (especially @kadena, @PolkaDot, and @Solana) have major version changes that could potentially introduce breaking changes.
- The npm changelog checks did not explicitly report breaking changes; however, please confirm that these upgrades are intentional and tied to the paste window fix.
- Ensure you have performed thorough testing with these new versions and that they do not affect unrelated functionality.
35-38:❓ Verification inconclusive
Review security implications of crypto-related package updates.
Several security-sensitive packages are being updated. Please ensure:
- All versions are stable releases
- No known security vulnerabilities exist
- Changes are backward compatible
Also applies to: 42-42, 63-63
🏁 Script executed:
#!/bin/bash # Description: Check for security advisories in crypto-related packages # Check for known vulnerabilities npm audit --json | jq '.advisories[] | select(.module_name | test("@ethereumjs|@metamask|bitcoinjs-lib"))' # Check specific package versions for audit info for pkg in "@ethereumjs/wallet" "@metamask/eth-sig-util" "bitcoinjs-lib"; do echo "Checking $pkg..." npm view $pkg time --json | jq '.' doneLength of output: 5904
Security Implications of Crypto-related Package Updates
Several security-sensitive packages are updated in this change. Based on the npm metadata:
- @ethereumjs/wallet: Version 2.0.4 (released 2024-08-15) appears to be a stable release.
- @metamask/eth-sig-util: Recent versions (up to 8.2.0) indicate active maintenance.
- bitcoinjs-lib: Although this package has older version metadata, please verify that the current version remains secure.
Action items:
- Stability & Audit: Confirm that each updated package is a stable release and that no known security vulnerabilities exist.
- npm Audit Note: The npm audit command failed because no lockfile was present. Please run
npm i --package-lock-onlyand re-run the audit to thoroughly check for advisory issues.- Backwards Compatibility: Ensure that the updated versions maintain backward compatibility with the rest of the codebase.
- Additional Locations: This review applies similarly to changes at lines 42 and 63.
packages/signers/bitcoin/package.json (2)
44-50:✅ Verification successful
Verify compatibility of updated dev dependencies.
Please ensure these version updates are compatible with your Node.js version (>=14.15.0):
- prettier: ^3.4.2
- tsup: ^8.3.6
- typescript: ^5.7.3
- typescript-eslint: 8.23.0
- vitest: ^3.0.5
Let's verify the latest versions and compatibility:
🏁 Script executed:
#!/bin/bash # Description: Check latest versions of dev dependencies for pkg in prettier tsup typescript typescript-eslint vitest; do echo "Checking $pkg..." npm view $pkg versions --json | jq -r '.[-1]' doneLength of output: 895
Action Required: Confirm Dev Dependency Compatibility with Node.js (>=14.15.0)
We verified that the versions specified in
packages/signers/bitcoin/package.jsonare purposefully set to stable releases where intended:
- prettier: Using
"^3.4.2"secures a stable release even though the npm registry shows a pre-release (4.0.0-alpha.10).- tsup:
"^8.3.6"matches the current stable version.- typescript:
"^5.7.3"remains on the stable track (the npm latest is5.8.1-rc).- typescript-eslint: The package is locked at
"8.23.0"to avoid unintentionally pulling in the alpha (8.24.1-alpha.1).- vitest:
"^3.0.5"is confirmed as current.Please ensure these dependency constraints continue to prevent accidental updates to pre-release versions and are tested for full compatibility with Node.js (>=14.15.0).
38-38:⚠️ Potential issue❌ Incorrect review comment
Fix incorrect eslint version.
The specified version
^9.20.0is invalid as ESLint's current stable version is 8.x.Let's verify the latest version:
🌐 Web query:
What is the latest version of eslint?💡 Result:
The latest version of ESLint is v9.20.1, released on February 11, 2025[3][4]. This minor update includes bug fixes related to type synchronization, clearer error messages for invalid configurations, and improvements to rules like
consistent-thisandarrow-body-style[4].For context:
- The @typescript-eslint/eslint-plugin (a related but separate package) is on v8.24.0 as of February 10, 2025[1][8]
- The VS Code ESLint extension currently supports ESLint v8.x+ configurations[2]
ESLint follows semantic versioning with regular updates addressing bugs, new JavaScript/TypeScript language features, and rule improvements[3][6]. When upgrading, review release notes for potential linting behavior changes[5][7].
Citations:
- 1: https://github.com/typescript-eslint/typescript-eslint/releases
- 2: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint
- 3: https://www.npmjs.com/package/eslint
- 4: https://github.com/eslint/eslint/releases
- 5: https://eslint.org/blog/category/release-notes/
- 6: https://eslint.org/docs/latest/versions/
- 7: https://eslint.org
- 8: https://www.npmjs.com/package/@typescript-eslint/eslint-plugin
- 9: https://eslint.org/blog/
Subject: ESLint Version Validity Confirmed
The specified ESLint version (
^9.20.0) inpackages/signers/bitcoin/package.jsonis in line with the current stable release (v9.20.1). The original comment’s assertion—that ESLint’s stable version is 8.x—is outdated. No changes are needed.
- Verified that ESLint’s latest stable version is v9.20.1.
- The caret operator (
^) in^9.20.0allows for patch updates, so the current specification is appropriate.Likely an incorrect or invalid review comment.
packages/signers/ethereum/package.json (1)
35-35: Same version issues as in bitcoin package.The version issues identified in the bitcoin package also apply here:
- Invalid @types/node version
- Invalid eslint version
- Version verification needed for other dependencies
Also applies to: 38-38, 44-50
gamalielhere
changed the base branch from
devop/upgrade-packages
to
devop/release-2.2.2
Summary by CodeRabbit
Bug Fixes
Enhancements
Chores