Conversation
WalkthroughAdds two exported config constants and runtime RWA-based token filtering: on init the swap module queries an IP compliance URL, and if restrictions apply fetches an RWA filter list and removes listed token addresses from tokenList views. Duplicate constant declarations present in configs. Changes
Sequence Diagram(s)sequenceDiagram
participant Init as Initialization
participant IP as IP_Compliance_Service
participant RWA as RWA_Filter_Service
participant State as Token_List_State
Init->>IP: GET IP_COMPLY_URL
activate IP
IP-->>Init: compliance status
deactivate IP
alt Restrictions apply
Init->>RWA: GET RWA_FILTER_LIST
activate RWA
RWA-->>Init: restricted addresses list
deactivate RWA
rect rgba(220,240,220,0.5)
Note over Init,State: Filter token lists
Init->>State: filter tokenList.all
Init->>State: filter tokenList.top
Init->>State: filter tokenList.trending
end
else No restrictions
Note over Init,State: Keep token lists unfiltered
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
💼 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: 1
🤖 Fix all issues with AI Agents
In @packages/swap/src/index.ts:
- Around line 121-133: The code assigns this.rwaFilterList from a fetch chain
that can return undefined when IP_COMPLY_URL responds non-OK (or a network
error), causing TypeError when tokenList.* filters call .includes; fix by
wrapping the logic in a try/catch, await both fetches, check res.ok for
IP_COMPLY_URL and for RWA_FILTER_LIST before calling res.json(), and default
this.rwaFilterList = [] on any non-ok response or exceptions; then safely apply
filtering on this.tokenList.all, this.tokenList.top, and this.tokenList.trending
using that guaranteed array.
🧹 Nitpick comments (1)
packages/swap/src/configs.ts (1)
165-166: Minor style inconsistency: missing semicolons.The rest of the file consistently uses semicolons. Consider adding them here for consistency.
🔎 Proposed fix
-const RWA_FILTER_LIST = "https://raw.githubusercontent.com/enkryptcom/dynamic-data/refs/heads/main/configs/filtered-rwa-addresses.json" -const IP_COMPLY_URL = "https://partners.mewapi.io/o/ipcomply" +const RWA_FILTER_LIST = "https://raw.githubusercontent.com/enkryptcom/dynamic-data/refs/heads/main/configs/filtered-rwa-addresses.json"; +const IP_COMPLY_URL = "https://partners.mewapi.io/o/ipcomply";
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/swap/src/configs.tspackages/swap/src/index.ts
🧰 Additional context used
🧬 Code graph analysis (1)
packages/swap/src/index.ts (1)
packages/swap/src/configs.ts (2)
IP_COMPLY_URL(204-204)RWA_FILTER_LIST(203-203)
⏰ 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). (2)
- GitHub Check: buildAll
- GitHub Check: test
🔇 Additional comments (2)
packages/swap/src/index.ts (2)
5-5: LGTM!Import correctly updated to include the new config constants.
76-77: LGTM!Property declaration and initialization are correct.
Also applies to: 106-106
packages/swap/src/index.ts
Outdated
| this.rwaFilterList = await fetch(IP_COMPLY_URL).then(async res => { | ||
| if (res.ok) { | ||
| const json = await res.json(); | ||
| if (json.isRWARestricted) { | ||
| return fetch(RWA_FILTER_LIST).then(res => res.json()) | ||
| } else { | ||
| return [] | ||
| } | ||
| } | ||
| }) | ||
| this.tokenList.all = this.tokenList.all.filter(t => !this.rwaFilterList.includes(t.address)) | ||
| this.tokenList.top = this.tokenList.top.filter(t => !this.rwaFilterList.includes(t.address)) | ||
| this.tokenList.trending = this.tokenList.trending.filter(t => !this.rwaFilterList.includes(t.address)) |
There was a problem hiding this comment.
Critical: rwaFilterList can be undefined, causing TypeError on filter operations.
If IP_COMPLY_URL returns a non-OK response (4xx/5xx), the callback implicitly returns undefined. This causes this.rwaFilterList to be undefined, and lines 131-133 will throw TypeError: Cannot read property 'includes' of undefined.
Additionally:
- No error handling for network failures on either fetch
- Inner fetch for
RWA_FILTER_LISTdoesn't validateres.ok
🔎 Proposed fix with proper error handling
- this.rwaFilterList = await fetch(IP_COMPLY_URL).then(async res => {
- if (res.ok) {
- const json = await res.json();
- if (json.isRWARestricted) {
- return fetch(RWA_FILTER_LIST).then(res => res.json())
- } else {
- return []
- }
- }
- })
+ try {
+ const ipComplyRes = await fetch(IP_COMPLY_URL);
+ if (ipComplyRes.ok) {
+ const json = await ipComplyRes.json();
+ if (json.isRWARestricted) {
+ const rwaRes = await fetch(RWA_FILTER_LIST);
+ if (rwaRes.ok) {
+ this.rwaFilterList = await rwaRes.json();
+ }
+ }
+ }
+ } catch {
+ // Silently fail - rwaFilterList remains empty, no tokens filtered
+ }Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In @packages/swap/src/index.ts around lines 121 - 133, The code assigns
this.rwaFilterList from a fetch chain that can return undefined when
IP_COMPLY_URL responds non-OK (or a network error), causing TypeError when
tokenList.* filters call .includes; fix by wrapping the logic in a try/catch,
await both fetches, check res.ok for IP_COMPLY_URL and for RWA_FILTER_LIST
before calling res.json(), and default this.rwaFilterList = [] on any non-ok
response or exceptions; then safely apply filtering on this.tokenList.all,
this.tokenList.top, and this.tokenList.trending using that guaranteed array.
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@packages/extension/package.json`:
- Line 140: The dependency bump of "vite-tsconfig-paths" in package.json may
change rooted alias resolution; verify and fix any import breakage by checking
your tsconfig.json/jsconfig.json path mappings and vite config (vite.config.ts /
vite.config.js) where vite-tsconfig-paths is used (plugin invocation), ensuring
root-style aliases (like "/*") are correctly mapped or adjusted; run a full dev
build and production build to catch altered resolution, update path mappings or
import statements to explicit aliases if needed, and, if you relied on prior
debug behavior, adjust any logging usage to the new logFile option in the plugin
configuration.
In `@packages/hw-wallets/package.json`:
- Line 25: The `@types/node` version in packages/hw-wallets/package.json is
inconsistent with the rest of the monorepo; change the dependency entry
"@types/node": "^24.10.9" to the project's agreed version (e.g., "^22.19.7") so
type defs match across packages, then update the lockfile / run your package
manager (install) to propagate the change; look for the "@types/node" field in
that package.json to make the edit.
In `@packages/signers/bitcoin/package.json`:
- Around line 35-38: The `@types/node` dependency in package.json is pinned to
^24.10.9 which mismatches the workspace baseline and may expose Node 24-only
typings; update the package.json entry for "@types/node" from ^24.10.9 to
^22.19.7 to align with the rest of the workspace, or alternatively bump the
engines.node field to a Node 24+ range (e.g., ">=24.0.0") if you intend to
target Node 24; ensure the change is applied consistently for this package
(signers/bitcoin) and the other packages referenced (ethereum, kadena, polkadot,
hw-wallets) so the workspace typings/engines remain consistent.
In `@packages/signers/ethereum/package.json`:
- Around line 35-50: package.json declares "@types/node": "^24.10.9" which
requires Node 18+, but engines.node is ">=14.15.0", causing a mismatch; fix by
either pinning the dependency to the repo-consistent version "@types/node":
"^22.19.7" in dependencies/devDependencies to match other packages, or by
updating the engines.node entry to ">=18.0.0" to reflect the newer types
requirement—edit the package.json accordingly (change the "@types/node" version
string or the "engines.node" value) and run install to verify type resolution.
In `@packages/signers/kadena/package.json`:
- Around line 33-48: The package declares `@types/node` at ^24.10.9 which requires
Node 20+, but the package.json engines.node still allows >=14.15.0; update
engines.node to a minimum that matches `@types/node` (e.g., ">=20.0.0" or at least
">=18.0.0" if you prefer broader support) so the declared runtime matches the
TypeScript types, or alternatively downgrade the `@types/node` dependency to a
version compatible with older Node if you must keep engines.node as >=14.15.0;
adjust the package.json engines.node field accordingly and ensure CI/test matrix
aligns with the chosen Node baseline.
packages/extension/package.json
Outdated
| "vue-tsc": "^3.1.8", | ||
| "vite": "^7.3.1", | ||
| "vite-plugin-node-polyfills": "0.25.0", | ||
| "vite-tsconfig-paths": "^6.0.4", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
vite-tsconfig-paths v6 breaking changes release notes
💡 Result:
vite-tsconfig-paths v6 — breaking / behavior-changing notes (from release notes)
- Module-resolution tracing moved out of
DEBUG: In v6+,DEBUG=vite-tsconfig-pathsstill works for debug logs, but detailed per-import resolution tracing is now only written via the newlogFileoption (e.g.logFile: truecreatesvite-tsconfig-paths.log). This can affect workflows that previously relied onDEBUGoutput for resolution traces. [1] - New project discovery mode can change when configs are found: v6 adds
projectDiscovery, including"lazy"on-demand tsconfig discovery (eager remains default). If you opt into"lazy", tsconfig discovery timing/coverage changes compared to prior versions. [2] - Rooted
/*path aliases now resolve: v6 adds support for/*(“rooted”) path aliases (and similar absolute-style patterns). This can change how certain imports resolve compared to v5 (where these patterns may not have worked). [3][4] - tsconfig/jsconfig are now watched and reloaded (including during
vite build --watch): This changes behavior vs v5 and below (which required restarting Vite after tsconfig changes). [1][4]
Primary release notes: GitHub “Releases” entries for v6.0.0-beta.1–beta.4 (features landed there before stable v6). [1][2][3]
Sources:
[1] vite-tsconfig-paths v6.0.0-beta.2 release notes (GitHub Releases)
[2] vite-tsconfig-paths v6.0.0-beta.1 release notes (GitHub Releases)
[3] vite-tsconfig-paths v6.0.0-beta.3 release notes (GitHub Releases)
[4] v6.0.0 highlights/upgrade notes summary (NewReleases.io)
🌐 Web query:
vite-tsconfig-paths v6 compatibility with vite 7
💡 Result:
vite-tsconfig-paths v6 is compatible with Vite 7—it declares vite as a wildcard peer dependency ("*"), so it’s intended to work across Vite majors (including 7.x). [1]
Practical gotchas when moving to Vite 7:
- Node requirement: Vite 7 requires Node 20.19+ or 22.12+. [2]
- ESM config expectations: The plugin is ESM and its setup notes recommend using
"type": "module"or avite.config.mjs/vite.config.mtsconfig file. [3]
Sources: [1] [2] [3]
Major version bump for vite-tsconfig-paths (5.1.4 → 6.0.4) is compatible with Vite 7.
Key behavior changes in v6:
- Rooted path aliases (e.g.,
/*) now resolve (may affect import resolution if codebase relies on previous non-resolution) - tsconfig/jsconfig files are now watched and reloaded (no need to restart Vite after config changes)
- Debug output moved from
DEBUGenv var tologFileoption
Verify that rooted path alias resolution doesn't unintentionally change how imports resolve in the build.
🤖 Prompt for AI Agents
In `@packages/extension/package.json` at line 140, The dependency bump of
"vite-tsconfig-paths" in package.json may change rooted alias resolution; verify
and fix any import breakage by checking your tsconfig.json/jsconfig.json path
mappings and vite config (vite.config.ts / vite.config.js) where
vite-tsconfig-paths is used (plugin invocation), ensuring root-style aliases
(like "/*") are correctly mapped or adjusted; run a full dev build and
production build to catch altered resolution, update path mappings or import
statements to explicit aliases if needed, and, if you relied on prior debug
behavior, adjust any logging usage to the new logFile option in the plugin
configuration.
packages/hw-wallets/package.json
Outdated
| "@typescript-eslint/eslint-plugin": "^8.49.0", | ||
| "@typescript-eslint/parser": "^8.49.0", | ||
| "eslint": "^9.39.1", | ||
| "@types/node": "^24.10.9", |
There was a problem hiding this comment.
Inconsistent @types/node version across packages.
This package uses @types/node: ^24.10.9 while all other packages in this PR use ^22.19.7. This version mismatch could cause type definition inconsistencies across the monorepo. Consider aligning to the same version used elsewhere.
Suggested fix
- "@types/node": "^24.10.9",
+ "@types/node": "^22.19.7",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@types/node": "^24.10.9", | |
| "@types/node": "^22.19.7", |
🤖 Prompt for AI Agents
In `@packages/hw-wallets/package.json` at line 25, The `@types/node` version in
packages/hw-wallets/package.json is inconsistent with the rest of the monorepo;
change the dependency entry "@types/node": "^24.10.9" to the project's agreed
version (e.g., "^22.19.7") so type defs match across packages, then update the
lockfile / run your package manager (install) to propagate the change; look for
the "@types/node" field in that package.json to make the edit.
| "@types/node": "^24.10.9", | ||
| "@typescript-eslint/eslint-plugin": "^8.53.1", | ||
| "@typescript-eslint/parser": "^8.53.1", | ||
| "eslint": "^9.39.2", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, read the specific file to see the actual content at the mentioned lines
cat -n packages/signers/bitcoin/package.json | head -60Repository: enkryptcom/enKrypt
Length of output: 2049
🏁 Script executed:
# Check engines.node field in bitcoin/package.json
rg 'engines' packages/signers/bitcoin/package.json -A 5Repository: enkryptcom/enKrypt
Length of output: 198
🏁 Script executed:
# Search for `@types/node` versions across all workspace packages
rg '@types/node' packages/ -A 0 | grep -v node_modulesRepository: enkryptcom/enKrypt
Length of output: 1030
Align @types/node with supported runtime or update engine range.
Using @types/node ^24.10.9 while engines.node is >=14.15.0 can allow types for APIs not available in the minimum supported Node version. Most workspace packages use @types/node ^22.19.7; this package and a few others (ethereum, kadena, polkadot, hw-wallets) use ^24.10.9. Align to ^22.19.7 or bump the engines range to target Node 24+.
🔧 Suggested alignment (if Node 22 is the intended baseline)
- "@types/node": "^24.10.9",
+ "@types/node": "^22.19.7",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@types/node": "^24.10.9", | |
| "@typescript-eslint/eslint-plugin": "^8.53.1", | |
| "@typescript-eslint/parser": "^8.53.1", | |
| "eslint": "^9.39.2", | |
| "@types/node": "^22.19.7", | |
| "@typescript-eslint/eslint-plugin": "^8.53.1", | |
| "@typescript-eslint/parser": "^8.53.1", | |
| "eslint": "^9.39.2", |
🤖 Prompt for AI Agents
In `@packages/signers/bitcoin/package.json` around lines 35 - 38, The `@types/node`
dependency in package.json is pinned to ^24.10.9 which mismatches the workspace
baseline and may expose Node 24-only typings; update the package.json entry for
"@types/node" from ^24.10.9 to ^22.19.7 to align with the rest of the workspace,
or alternatively bump the engines.node field to a Node 24+ range (e.g.,
">=24.0.0") if you intend to target Node 24; ensure the change is applied
consistently for this package (signers/bitcoin) and the other packages
referenced (ethereum, kadena, polkadot, hw-wallets) so the workspace
typings/engines remain consistent.
packages/signers/kadena/package.json
Outdated
| "@types/node": "^24.10.9", | ||
| "@typescript-eslint/eslint-plugin": "^8.53.1", | ||
| "@typescript-eslint/parser": "^8.53.1", | ||
| "eslint": "^9.39.2", | ||
| "eslint-config-airbnb-base": "^15.0.0", | ||
| "eslint-config-prettier": "^10.1.8", | ||
| "eslint-import-resolver-alias": "^1.1.2", | ||
| "eslint-plugin-import": "^2.32.0", | ||
| "eslint-plugin-module-resolver": "^1.5.0", | ||
| "prettier": "^3.7.4", | ||
| "prettier": "^3.8.1", | ||
| "ts-node": "^10.9.2", | ||
| "tsconfig-paths": "^4.2.0", | ||
| "tsup": "^8.5.1", | ||
| "typescript": "^5.9.3", | ||
| "typescript-eslint": "8.49.0", | ||
| "vitest": "^4.0.15" | ||
| "typescript-eslint": "8.53.1", | ||
| "vitest": "^4.0.18" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat packages/signers/kadena/package.jsonRepository: enkryptcom/enKrypt
Length of output: 1586
🏁 Script executed:
#!/bin/bash
# Find all Node engine declarations and CI Node version specifications
echo "=== Engines declarations in package.json files ==="
rg -n 'engines' -A 3 packages/signers/kadena/package.json
echo "=== CI Node version specifications ==="
find .github -type f \( -name "*.yml" -o -name "*.yaml" \) -exec grep -l "node-version\|setup-node\|NODE_VERSION" {} \;Repository: enkryptcom/enKrypt
Length of output: 352
🏁 Script executed:
#!/bin/bash
# Check Node versions specified in CI workflows
for file in .github/workflows/build-all.yml .github/workflows/release.yml .github/workflows/test-all.yml; do
if [ -f "$file" ]; then
echo "=== $file ==="
grep -A 2 -B 2 "node-version\|setup-node" "$file" | head -20
echo ""
fi
doneRepository: enkryptcom/enKrypt
Length of output: 594
Align Node version declaration with TypeScript dependencies.
@types/node at ^24.10.9 requires Node.js 20+, but engines.node declares >=14.15.0. CI tests with Node 22.18.0, indicating Node 14 support is not realistic. Update engines.node to >=18.0.0 or >=20.0.0 to reflect actual support, or downgrade @types/node if legacy Node versions must be supported.
🤖 Prompt for AI Agents
In `@packages/signers/kadena/package.json` around lines 33 - 48, The package
declares `@types/node` at ^24.10.9 which requires Node 20+, but the package.json
engines.node still allows >=14.15.0; update engines.node to a minimum that
matches `@types/node` (e.g., ">=20.0.0" or at least ">=18.0.0" if you prefer
broader support) so the declared runtime matches the TypeScript types, or
alternatively downgrade the `@types/node` dependency to a version compatible with
older Node if you must keep engines.node as >=14.15.0; adjust the package.json
engines.node field accordingly and ensure CI/test matrix aligns with the chosen
Node baseline.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/name-resolution/package.json (1)
21-41: Raiseengines.nodeto at least>=18.18.0to match toolchain requirements.The upgraded devDependencies are incompatible with the declared
engines.node: ">=14.15.0":
- ESLint 9.x requires Node >= 18.18.0
@typescript-eslint8.x requires Node >= 18.18.0- Vitest 4.x requires Node >= 20.0.0
- Viem 2.45.x requires Node >= 18
@types/node22.x should align with the actual Node version being targeted (currently misaligned with Node 14)Contributors on Node 14 will encounter install failures and cannot run the toolchain. Either (a) bump
engines.nodeto at least>=18.18.0(preferably>=20.19.0for Vitest 4) and update@types/nodeaccordingly, or (b) downgrade the toolchain versions to releases supporting Node 14.packages/signers/massa/package.json (1)
21-23: Align@types/nodewith declared runtime support across all packages.
@types/node@^22.19.7exposes APIs not available on Node >=14.15.0, risking type-checking passes but runtime failures. This pattern affects multiple packages in the monorepo (8 packages use@22.19.7, 5 use@25.0.10, but all declare engines.node >=14.15.0). Either raise theengines.nodefloor to match the types version or unify@types/nodeto a version compatible with Node 14.15.0 across all packages.
🤖 Fix all issues with AI agents
In `@packages/hw-wallets/package.json`:
- Line 56: The code currently uses a deep import from
"@ledgerhq/hw-app-eth/lib/services/ledger" which is blocked by v7.x package
exports; open packages/hw-wallets/src/ledger/ethereum/index.ts, locate the
import statement that references "@ledgerhq/hw-app-eth/lib/services/ledger" (and
any usages of the exported symbol from that path, e.g., LedgerService,
createLedger*, or similar), and replace it with the public API from
"@ledgerhq/hw-app-eth" (use the exported Eth class and public transport helpers
from "@ledgerhq/hw-transport" or the documented public exports). Update any code
that constructs or types the ledger service (e.g., functions or classes named
like LedgerEthereum, createLedgerEthereumService, or getLedgerEthereumTransport)
to instantiate/use the Eth class and public transport types instead of the
deep-imported symbol so runtime import resolution uses the package's public
exports.
- Line 72: The package.json currently pins "ledger-bitcoin" to an unavailable
version "^0.3.0"; update the dependency entry for "ledger-bitcoin" in
package.json to a published version (e.g., "^0.2.3") or replace it with the
intended valid version, then run npm install to verify resolution and update any
lockfile if present; target the "ledger-bitcoin" dependency string when making
this change.
| "@ledgerhq/hw-transport": "^6.31.13", | ||
| "@ledgerhq/hw-transport-webusb": "^6.29.13", | ||
| "@ledgerhq/hw-app-btc": "^10.17.0", | ||
| "@ledgerhq/hw-app-eth": "^7.3.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@ledgerhq/hw-app-eth v7 breaking changes API migration guide
💡 Result:
I couldn’t find any official “v7 breaking changes / migration guide” specifically for @ledgerhq/hw-app-eth—only evidence that v7.x exists and is published (e.g., jsDelivr shows the package is at v7.x and marked esm, and NewReleases lists @ledgerhq/hw-app-eth@7.0.0) [1][2]. Snyk also reports a latest major around 7.0.0 for this package [3].
Practical way to build your own v6 → v7 migration checklist (works even without a guide)
-
Inspect the v7 package metadata (especially
package.json):- Check for an
"exports"map (often the source of breaking changes by disallowing “deep imports” like.../lib/...). - Confirm module format (ESM vs CJS) and required Node version.
- You can do this quickly via CDN package views (jsDelivr/unpkg) starting from the package page [1].
- Check for an
-
Search your codebase for deep imports and be ready to replace them:
- Example pattern (seen in Ledger tutorials for v6):
@ledgerhq/hw-app-eth/lib/services/ledger(deep path). - If v7 adds strict
"exports", these typically must become public entrypoints (whatever v7 exposes) rather thanlib/*.
- Example pattern (seen in Ledger tutorials for v6):
-
Diff the public API surface between v6 and v7
- Generate TypeScript types / API reports for both versions (or use
tsc --traceResolution) and compare. - Update any changed method signatures/return shapes accordingly.
- Generate TypeScript types / API reports for both versions (or use
If you paste:
- your current imports from
@ledgerhq/hw-app-eth, - your current version (6.x exact),
- and the errors you see after bumping to 7.x,
I can turn that into an exact, line-by-line migration patch.
Sources: [1] [2] [3]
🏁 Script executed:
# Find all files that import or use `@ledgerhq/hw-app-eth`
rg "@ledgerhq/hw-app-eth" --type json --type js --type ts -B 2 -A 2Repository: enkryptcom/enKrypt
Length of output: 1208
🏁 Script executed:
# Check if there are any version-specific comments or compatibility notes in the codebase
rg "hw-app-eth|ledgerhq.*eth" -A 3 -B 3Repository: enkryptcom/enKrypt
Length of output: 3454
🌐 Web query:
@ledgerhq/hw-app-eth 7.3.1 package.json exports lib/services/ledger
💡 Result:
In @ledgerhq/hw-app-eth@7.3.1, you should not deep-import lib/services/ledger (e.g. @ledgerhq/hw-app-eth/lib/services/ledger), because the package is meant to be consumed via its public entrypoints (and deep imports commonly fail under Node’s exports restrictions with ERR_PACKAGE_PATH_NOT_EXPORTED). The package documents ledgerService as a named export from the package root. [1][2]
Use:
import Eth, { ledgerService } from "@ledgerhq/hw-app-eth";Sources: jsDelivr shows the package version 7.3.1 [3], and the README examples show ledgerService imported from the root entry. [1][2]
References:
[1] (npm.io)
[2] (tessl.io)
[3] (jsdelivr.com)
Citations:
- 1: https://npm.io/package/%40ledgerhq/hw-app-eth?utm_source=openai
- 2: https://tessl.io/registry/tessl/npm-ledgerhq--hw-app-eth/6.45.0/files/docs/index.md?utm_source=openai
- 3: https://www.jsdelivr.com/package/npm/%40ledgerhq/hw-app-eth
🏁 Script executed:
# Check the actual structure and exports of the installed package
# Look for any TypeScript errors or build warnings
rg "lib/services/ledger" --type ts --type js -B 3 -A 3Repository: enkryptcom/enKrypt
Length of output: 716
🏁 Script executed:
# Search for any error messages, issues, or discussions about this import in commits/PRs
git log --all --oneline | head -20Repository: enkryptcom/enKrypt
Length of output: 196
🏁 Script executed:
# Check if there's a tsconfig or build configuration that might indicate issues
find . -name "tsconfig.json" -o -name ".eslintrc*" -o -name "vite.config*" | head -5Repository: enkryptcom/enKrypt
Length of output: 254
🏁 Script executed:
# Check for any build or test output that might reveal errors with the hw-app-eth import
rg "hw-app-eth|ledgerService" --type log --type txt 2>/dev/null | head -20Repository: enkryptcom/enKrypt
Length of output: 44
The deep import path is incompatible with v7.x and will fail at runtime.
Version 7.3.1 enforces strict package exports that disallow the current deep import: @ledgerhq/hw-app-eth/lib/services/ledger. This will throw ERR_PACKAGE_PATH_NOT_EXPORTED.
Fix: Update packages/hw-wallets/src/ledger/ethereum/index.ts to use the public API:
Import change required
- import ledgerService from "@ledgerhq/hw-app-eth/lib/services/ledger";
- import EthApp from "@ledgerhq/hw-app-eth";
+ import EthApp, { ledgerService } from "@ledgerhq/hw-app-eth";🤖 Prompt for AI Agents
In `@packages/hw-wallets/package.json` at line 56, The code currently uses a deep
import from "@ledgerhq/hw-app-eth/lib/services/ledger" which is blocked by v7.x
package exports; open packages/hw-wallets/src/ledger/ethereum/index.ts, locate
the import statement that references "@ledgerhq/hw-app-eth/lib/services/ledger"
(and any usages of the exported symbol from that path, e.g., LedgerService,
createLedger*, or similar), and replace it with the public API from
"@ledgerhq/hw-app-eth" (use the exported Eth class and public transport helpers
from "@ledgerhq/hw-transport" or the documented public exports). Update any code
that constructs or types the ledger service (e.g., functions or classes named
like LedgerEthereum, createLedgerEthereumService, or getLedgerEthereumTransport)
to instantiate/use the Eth class and public transport types instead of the
deep-imported symbol so runtime import resolution uses the package's public
exports.
| "bs58": "^6.0.0", | ||
| "hdkey": "^2.1.0", | ||
| "ledger-bitcoin": "^0.2.3", | ||
| "ledger-bitcoin": "^0.3.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
ledger-bitcoin 0.3.0 changelog release notes breaking changes
💡 Result:
I couldn’t find any official 0.3.0 changelog / release notes / “breaking changes” for the ledger-bitcoin Python package published on PyPI—PyPI lists the release, but doesn’t include release notes, and the linked upstream repo doesn’t surface a ledger-bitcoin-specific 0.3.0 changelog in an easily accessible public page.
What is publicly confirmed:
ledger-bitcoin0.3.0 was released on February 15, 2024 (PyPI). [1]
If you need to identify breaking changes for an upgrade, the practical approach is to diff the upstream source corresponding to that release (often tagged in the upstream repo) against the previous version and scan API changes; however, I wasn’t able to retrieve a public “0.3.0 release notes” page directly from the available sources during this lookup.
Sources
[1] (pypi.org)
Citations:
🌐 Web query:
ledger-bitcoin GitHub repository source code
💡 Result:
The “ledger-bitcoin” Python package (ledger_bitcoin, published on PyPI) points to Ledger’s main GitHub repository for the Bitcoin client + app source code: LedgerHQ/app-bitcoin-new. (pypi.org)
Relevant source folders inside that repo include:
bitcoin_client(Python client library source)bitcoin_client_js(JavaScript client)bitcoin_client_rs(Rust client)src(the Ledger Bitcoin app itself) (github.com)
Repo (source code):
https://github.com/LedgerHQ/app-bitcoin-new
Legacy (older) Bitcoin app source code repo:
https://github.com/LedgerHQ/app-bitcoin
``` ([github.com](https://github.com/LedgerHQ/app-bitcoin?utm_source=openai))
Citations:
- 1: https://pypi.org/project/ledger-bitcoin/?utm_source=openai
- 2: https://github.com/LedgerHQ/app-bitcoin-new
- 3: https://github.com/LedgerHQ/app-bitcoin?utm_source=openai
---
🌐 Web query:
`site:github.com LedgerHQ app-bitcoin-new ledger-bitcoin 0.3.0 release`
💡 Result:
- In `LedgerHQ/app-bitcoin-new`, there is a **Git tag `jsclient-0.3.0`**, dated **Jan 13, 2026**. [1]
- The Python package **`ledger-bitcoin` v0.3.0** (PyPI) was released on **Feb 15, 2024**. [2]
- The npm package **`ledger-bitcoin`** currently shows **version 0.2.3** (last published ~2 years ago) and points back to `LedgerHQ/app-bitcoin-new` as its repository. [3]
**Sources:** [1] [2] [3]
---
🌐 Web query:
`npm ledger-bitcoin package versions available`
💡 Result:
Versions available for the **`ledger-bitcoin`** package on npm (per Socket’s npm mirror) are: **0.2.0, 0.2.1, 0.2.2, 0.2.3 (latest)**. [1]
npm’s package page also shows the current published version as **0.2.3**. [2]
(Separately, jsDelivr’s npm index shows **0.3.0**, which may indicate an additional tag/version in the CDN index.) [3]
**Sources:** [1] [2] [3]
---
🌐 Web query:
`"ledger-bitcoin" "0.3.0" npm published versions history`
💡 Result:
For the **npm** package **`ledger-bitcoin`**:
- The published versions visible from npm ecosystem mirrors are: **0.2.0, 0.2.1, 0.2.2, 0.2.3 (latest)**. [2]
- The npm package page also shows **current version 0.2.3** (published “2 years ago” at the time it was crawled). [1]
- I **do not see an npm release `0.3.0`** for `ledger-bitcoin` in these npm sources; `0.3.0` appears to be associated with the **Python (PyPI)** project `ledger-bitcoin` (released **Feb 15, 2024**). [4]
Note: jsDelivr’s npm page for `ledger-bitcoin` shows **“Version 0.3.0”**, which conflicts with npm/Socket’s version list. [3]
**Sources:** npm package page [1], Socket version list [2], jsDelivr package page [3], PyPI release history [4].
---
</details>
**Update `ledger-bitcoin` version—0.3.0 is not published on npm.**
The npm registry only contains versions 0.2.0 through 0.2.3. Specifying `^0.3.0` will fail during `npm install`. Use `^0.2.3` (the latest available version) or confirm the intended version.
<details>
<summary>🤖 Prompt for AI Agents</summary>
In @packages/hw-wallets/package.json at line 72, The package.json currently pins
"ledger-bitcoin" to an unavailable version "^0.3.0"; update the dependency entry
for "ledger-bitcoin" in package.json to a published version (e.g., "^0.2.3") or
replace it with the intended valid version, then run npm install to verify
resolution and update any lockfile if present; target the "ledger-bitcoin"
dependency string when making this change.
</details>
<!-- fingerprinting:phantom:poseidon:ocelot -->
<!-- This is an auto-generated comment by CodeRabbit -->
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/signers/massa/package.json (1)
21-23: Align@types/nodewith supported runtime.
@types/nodeis v22.19.7 whileengines.nodeallows Node 14.15.0+. This mismatch can let Node 22-only APIs type-check and slip into runtime on Node 14. Either downgrade@types/nodeto match Node 14 support or raiseengines.nodeto Node 18+.Example fix options
Option A — keep Node 14 support (downgrade types):
- "@types/node": "^22.19.7", + "@types/node": "^14.18.63",Option B — raise minimum Node version:
- "engines": { - "node": ">=14.15.0" - }, + "engines": { + "node": ">=18.18.0" + },
🤖 Fix all issues with AI agents
In `@packages/signers/massa/package.json`:
- Around line 39-53: The package.json currently declares an engines constraint
of ">=14.15.0" which is too low for the declared devDependency vitest@4.0.18;
update the "engines" field in package.json to reflect the minimum Node.js
version required by Vitest (at least "^20.19.0") so installs on older Node
versions are prevented; locate the "engines" property in packages/signers/massa
package.json and change its value to "^20.19.0" (or a compatible range such as
"^20.19.0 || >=22.12.0") and ensure this change is committed alongside the
dependency list update.
| "@typescript-eslint/eslint-plugin": "^8.54.0", | ||
| "@typescript-eslint/parser": "^8.54.0", | ||
| "eslint": "^9.39.2", | ||
| "eslint-config-airbnb-base": "^15.0.0", | ||
| "eslint-config-prettier": "^10.1.8", | ||
| "eslint-import-resolver-alias": "^1.1.2", | ||
| "eslint-plugin-import": "^2.32.0", | ||
| "eslint-plugin-module-resolver": "^1.5.0", | ||
| "prettier": "^3.7.4", | ||
| "prettier": "^3.8.1", | ||
| "ts-node": "^10.9.2", | ||
| "tsconfig-paths": "^4.2.0", | ||
| "tsup": "^8.5.1", | ||
| "typescript": "^5.9.3", | ||
| "typescript-eslint": "8.49.0", | ||
| "vitest": "^4.0.15" | ||
| "typescript-eslint": "8.54.0", | ||
| "vitest": "^4.0.18" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
ESLint v9.39.2 Node.js version requirements
💡 Result:
ESLint v9.39.2 (a v9.x patch release) requires Node.js:
- ^18.18.0 (i.e., 18.18.0+ within Node 18)
- ^20.9.0 (i.e., 20.9.0+ within Node 20)
- >=21.1.0 (Node 21.1.0 or newer)
This Node support range was introduced for ESLint v9.0.0 and is reflected in ESLint’s documented prerequisites for v9.x. [1][2][3]
Sources: [1] [2] [3]
🌐 Web query:
@typescript-eslint v8.54.0 Node.js requirements compatibility ESLint v9
💡 Result:
For the typescript-eslint v8.x line (including @typescript-eslint v8.54.0):
- Node.js supported:
^18.18.0 || ^20.9.0 || >=21.1.0(typescript-eslint.io) - ESLint supported / compatible:
^8.57.0 || ^9.0.0(so ESLint v9.x is supported) (typescript-eslint.io) - typescript-eslint v8 ships with full support for ESLint v9 (typescript-eslint.io)
Citations:
- 1: https://typescript-eslint.io/users/dependency-versions?utm_source=openai
- 2: https://typescript-eslint.io/users/dependency-versions?utm_source=openai
- 3: https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/?utm_source=openai
🌐 Web query:
Vitest v4.0.18 Node.js version requirements
💡 Result:
Vitest v4.0.18 effectively requires a Node.js version compatible with its Vite dependency:
- Node.js
^20.19.0 || >=22.12.0(i.e., Node 20.19+ or Node 22.12+). (fossies.org)
Citations:
🏁 Script executed:
# Check if there's an engines field in the package.json file
cat packages/signers/massa/package.json | grep -A 5 '"engines"'Repository: enkryptcom/enKrypt
Length of output: 205
🏁 Script executed:
# Search for root package.json to see if there's a Node version specified there
find . -maxdepth 2 -name "package.json" -type f -exec grep -l '"engines"' {} \;Repository: enkryptcom/enKrypt
Length of output: 44
🏁 Script executed:
# Check root package.json for engines
cat package.json | grep -A 5 '"engines"'Repository: enkryptcom/enKrypt
Length of output: 44
🏁 Script executed:
# Look for CI configuration
find . -maxdepth 3 -type f \( -name "*.yml" -o -name "*.yaml" \) | grep -i "github\|ci\|workflow" | head -10Repository: enkryptcom/enKrypt
Length of output: 212
🏁 Script executed:
# Check for Node version specification files
find . -maxdepth 2 -type f \( -name ".nvmrc" -o -name ".node-version" -o -name ".npmrc" \)Repository: enkryptcom/enKrypt
Length of output: 70
🏁 Script executed:
# Get the structure around packages/signers/massa to understand if this is a workspace
cat package.json | grep -E '"workspaces"|"name"' | head -10Repository: enkryptcom/enKrypt
Length of output: 100
🏁 Script executed:
cat .nvmrcRepository: enkryptcom/enKrypt
Length of output: 70
🏁 Script executed:
cat .github/workflows/test-all.ymlRepository: enkryptcom/enKrypt
Length of output: 371
Update the engines field to match actual minimum Node.js requirement.
The engines field in this package specifies >=14.15.0, but Vitest v4.0.18 requires ^20.19.0 || >=22.12.0. Update the engines field to at least ^20.19.0 to prevent installation on incompatible Node versions.
Note: @typescript-eslint v8.54.0 and ESLint v9.39.2 are fully compatible with each other and both support the same Node range (^18.18.0 || ^20.9.0 || >=21.1.0). CI is already correctly configured with Node v22.18.0.
🤖 Prompt for AI Agents
In `@packages/signers/massa/package.json` around lines 39 - 53, The package.json
currently declares an engines constraint of ">=14.15.0" which is too low for the
declared devDependency vitest@4.0.18; update the "engines" field in package.json
to reflect the minimum Node.js version required by Vitest (at least "^20.19.0")
so installs on older Node versions are prevented; locate the "engines" property
in packages/signers/massa package.json and change its value to "^20.19.0" (or a
compatible range such as "^20.19.0 || >=22.12.0") and ensure this change is
committed alongside the dependency list update.
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@packages/hw-wallets/package.json`:
- Line 25: The package.json dependency "@types/node" is pinned to "^25.0.10"
which is inconsistent with the majority of monorepo packages using "^22.19.7";
update the "@types/node" entry in packages/hw-wallets's package.json to match
the monorepo majority (e.g., "^22.19.7") or, if intentional, add a clear comment
in the package README explaining why this package requires "^25.x" and document
the divergence; ensure the change is applied to the "@types/node" key so
TypeScript type resolution across modules remains consistent.
In `@packages/hw-wallets/src/trezor/trezorConnect.ts`:
- Line 24: Update the manifest's appUrl value to point to Enkrypt instead of
MyEtherWallet: locate the appUrl entry in trezorConnect.ts (the manifest object
where appUrl is defined) and change the string from
"http://www.myetherwallet.com" to "https://www.enkrypt.com" to match the
webextension path and ensure correct attribution and consistency.
- Around line 17-27: The code risks calling init on an undefined initFunc
(computed as TrezorConnect.init ? TrezorConnect : TrezorConnect.default) and
uses an incorrect hardcoded appUrl; update the loader to defensive-check that
initFunc is defined and has an init method (TrezorConnect / initFunc) before
calling init and throw or return a clear error if not, and change the
manifest.appUrl to the correct Enkrypt domain used elsewhere (use the same URL
string as the webextension branch) so TrezorConnect.init is only invoked on a
valid object and the appUrl is consistent.
| "@typescript-eslint/eslint-plugin": "^8.49.0", | ||
| "@typescript-eslint/parser": "^8.49.0", | ||
| "eslint": "^9.39.1", | ||
| "@types/node": "^25.0.10", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check `@types/node` versions across all package.json files in the monorepo
fd package.json --type f --exec grep -l "@types/node" {} \; | xargs -I {} sh -c 'echo "=== {} ===" && grep "@types/node" {}'Repository: enkryptcom/enKrypt
Length of output: 1180
Inconsistent @types/node version across packages.
This package uses @types/node: ^25.0.10, but most other packages in the monorepo use ^22.19.7 (name-resolution, keyring, types, storage, utils, signers/massa, swap, extension-bridge, request, extension). Only five packages share the ^25.0.10 version (hw-wallets, signers/bitcoin, signers/polkadot, signers/ethereum, signers/kadena). This major version mismatch should be reconciled to prevent type definition inconsistencies and potential build issues. Consider aligning with the majority version or document the reason for the divergence.
🤖 Prompt for AI Agents
In `@packages/hw-wallets/package.json` at line 25, The package.json dependency
"@types/node" is pinned to "^25.0.10" which is inconsistent with the majority of
monorepo packages using "^22.19.7"; update the "@types/node" entry in
packages/hw-wallets's package.json to match the monorepo majority (e.g.,
"^22.19.7") or, if intentional, add a clear comment in the package README
explaining why this package requires "^25.x" and document the divergence; ensure
the change is applied to the "@types/node" key so TypeScript type resolution
across modules remains consistent.
| const TrezorConnect = ((await import("@trezor/connect-web")) as any) | ||
| .default; | ||
| await TrezorConnect.default.init({ | ||
| const initFunc = TrezorConnect.init ? TrezorConnect : TrezorConnect.default; | ||
| await initFunc.init({ | ||
| lazyLoad: true, | ||
| manifest: { | ||
| email: "info@enkrypt.com", | ||
| appUrl: "http://www.myetherwallet.com", | ||
| }, | ||
| }); | ||
| return TrezorConnect.default as TrezorConnectType; | ||
| return initFunc as TrezorConnectType; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the complete trezorConnect.ts file to understand full context
find . -name "trezorConnect.ts" -type f | head -5Repository: enkryptcom/enKrypt
Length of output: 111
🏁 Script executed:
# Search for TrezorConnect usage patterns in the codebase
rg -n "TrezorConnect" --type ts -A 3 -B 3 -g '!node_modules' | head -100Repository: enkryptcom/enKrypt
Length of output: 7851
🏁 Script executed:
# Check package.json for `@trezor/connect-web` version
rg '"@trezor/connect-web"' --type jsonRepository: enkryptcom/enKrypt
Length of output: 131
🏁 Script executed:
# Look at imports and usage of the trezorConnect module itself
rg -n "from.*trezorConnect\|import.*trezorConnect" --type ts -A 3 -B 3Repository: enkryptcom/enKrypt
Length of output: 44
🏁 Script executed:
# Read the complete trezorConnect.ts file
cat -n packages/hw-wallets/src/trezor/trezorConnect.tsRepository: enkryptcom/enKrypt
Length of output: 1323
🏁 Script executed:
# Check for TrezorConnectType definition and imports in the file
rg -n "TrezorConnectType|import" packages/hw-wallets/src/trezor/trezorConnect.tsRepository: enkryptcom/enKrypt
Length of output: 395
🏁 Script executed:
# Check if there are any tests for trezorConnect.ts
find . -name "*trezor*test*" -o -name "*test*trezor*" -type f | grep -v node_modules | head -20Repository: enkryptcom/enKrypt
Length of output: 44
🏁 Script executed:
# Search for `@trezor/connect-web` documentation or type definitions if available locally
find . -path "*/node_modules/@trezor/connect-web*" -name "*.d.ts" -o -name "package.json" 2>/dev/null | grep -v ".map" | head -5Repository: enkryptcom/enKrypt
Length of output: 218
🏁 Script executed:
# Check if there's any documentation or comments about the module structure in the codebase
rg -n "trezor.*init|@trezor/connect" packages/ -A 2 -B 2 --type ts --type js | grep -E "(init|connect|default)" | head -30Repository: enkryptcom/enKrypt
Length of output: 2130
🏁 Script executed:
# Check the webextension branch to see how it handles the same scenario
rg -n "@trezor/connect-webextension" packages/hw-wallets/src/trezor/ -A 10 -B 2Repository: enkryptcom/enKrypt
Length of output: 1252
🌐 Web query:
@trezor/connect-web 9.7.1 module exports ESM CJS interop
💡 Result:
In @trezor/connect-web 9.7.1, the published package is CJS-first:
- No
exportsmap and no"type": "module"; entrypoint ismain: "lib/index.js"(so Node treats it as CommonJS). [1] - The typings declare a default export (
export default TrezorConnect) and alsoexport * from '@trezor/connect/lib/exports', but that “re-export surface” is type-level and may not be reliably available as true ESM named exports at runtime in Node (because the package itself is CJS). [2]
Practical interop guidance
CJS (require):
const TrezorConnect = require('@trezor/connect-web');ESM (Node / bundlers): prefer default import or namespace import
import TrezorConnect from '@trezor/connect-web';
// or
import * as TrezorConnect from '@trezor/connect-web';If you need named exports, import them from the source package that actually defines them:
import { UI_EVENT } from '@trezor/connect/lib/exports';Sources: [1] [2]
🏁 Script executed:
# Check if there are any actual error logs or issues related to this code path
rg -n "initFunc|TrezorConnect.*default" packages/hw-wallets/ --type ts -B 3 -A 3Repository: enkryptcom/enKrypt
Length of output: 2248
🏁 Script executed:
# Look at how the function is called and if there's any error handling around it
rg -n "getTrezorConnect\(\)" packages/hw-wallets/ --type ts -B 5 -A 5Repository: enkryptcom/enKrypt
Length of output: 2584
Add defensive check for undefined initFunc and fix inconsistent appUrl.
Line 19's fallback logic (TrezorConnect.init ? TrezorConnect : TrezorConnect.default) could result in undefined if both properties are falsy, causing a runtime error on line 20. Additionally, the appUrl on line 24 is hardcoded to a third-party URL instead of the Enkrypt domain used in the webextension branch (line 9).
Suggested improvements
const TrezorConnect = ((await import("@trezor/connect-web")) as any)
.default;
const initFunc = TrezorConnect.init ? TrezorConnect : TrezorConnect.default;
+ if (!initFunc?.init) {
+ throw new Error("Failed to resolve TrezorConnect init function");
+ }
await initFunc.init({
lazyLoad: true,
manifest: {
email: "info@enkrypt.com",
- appUrl: "http://www.myetherwallet.com",
+ appUrl: "https://www.enkrypt.com",
},
});🤖 Prompt for AI Agents
In `@packages/hw-wallets/src/trezor/trezorConnect.ts` around lines 17 - 27, The
code risks calling init on an undefined initFunc (computed as TrezorConnect.init
? TrezorConnect : TrezorConnect.default) and uses an incorrect hardcoded appUrl;
update the loader to defensive-check that initFunc is defined and has an init
method (TrezorConnect / initFunc) before calling init and throw or return a
clear error if not, and change the manifest.appUrl to the correct Enkrypt domain
used elsewhere (use the same URL string as the webextension branch) so
TrezorConnect.init is only invoked on a valid object and the appUrl is
consistent.
| lazyLoad: true, | ||
| manifest: { | ||
| email: "info@enkrypt.com", | ||
| appUrl: "http://www.myetherwallet.com", |
There was a problem hiding this comment.
Manifest appUrl references MyEtherWallet instead of Enkrypt.
The appUrl is set to "http://www.myetherwallet.com" while line 9 (webextension path) correctly uses "https://www.enkrypt.com". This appears to be a copy-paste inconsistency that predates this PR, but worth addressing for consistency and proper attribution.
Suggested fix
manifest: {
email: "info@enkrypt.com",
- appUrl: "http://www.myetherwallet.com",
+ appUrl: "https://www.enkrypt.com",
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| appUrl: "http://www.myetherwallet.com", | |
| appUrl: "https://www.enkrypt.com", |
🤖 Prompt for AI Agents
In `@packages/hw-wallets/src/trezor/trezorConnect.ts` at line 24, Update the
manifest's appUrl value to point to Enkrypt instead of MyEtherWallet: locate the
appUrl entry in trezorConnect.ts (the manifest object where appUrl is defined)
and change the string from "http://www.myetherwallet.com" to
"https://www.enkrypt.com" to match the webextension path and ensure correct
attribution and consistency.
1 participant
Summary by CodeRabbit
New Features
Bug Fixes / Improvements
Chores
✏️ Tip: You can customize this high-level summary in your review settings.