Skip to content

build(deps): bump tronweb from 6.2.2 to 6.5.1 - #77

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/tronweb-6.5.1
Open

dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/tronweb-6.5.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 24, 2026

Copy link
Copy Markdown

Bumps tronweb from 6.2.2 to 6.5.1.

Release notes

Sourced from tronweb's releases.

v6.5.1

Improvements

  • Inputs are validated and processed from a plain-data snapshot

    Several APIs now take a plain-data snapshot of their inputs at entry and use that snapshot consistently for validation and processing. Previously they read the caller's object several times, so a Proxy or a getter could show the validation one value and hand a different one to the signing or the request. An operation is now always carried out against the same input state it was validated against.

    Affected: sign, multiSign, signTypedData (incl. _signTypedData, utils.typedData.signTypedData), ecRecover, newTxID (incl. extendExpiration, addUpdateData), ABI loading in Contract (constructor, loadAbi, at), and triggerSmartContract / triggerConstantContract / triggerConfirmedConstantContract / estimateEnergy (both the options and the parameters argument). Contract method .call() / .send() and the read / write namespaces inherit the same behavior.

  • Caller-provided objects are no longer modified

    • sign no longer appends to the transaction's signature array, and multiSign no longer writes Permission_id. Code that kept using the object it passed in must switch to the returned transaction.
    • triggerConstantContract / triggerConfirmedConstantContract / estimateEnergy no longer write internal flags into the options object, so a reused options object no longer carries them into later calls.
    • Contract no longer lowercases type / stateMutability in the caller's ABI, and contract.abi is now an internal copy. Edits made to the original ABI after loading no longer affect the contract instance.
  • Input requirements

    Snapshotting preserves bigint, and Uint8Array where it was already supported (typed-data byte values such as salt, bytes arguments in parameters / parametersV2). Plain objects and arrays from another realm (an iframe, a vm context) are accepted like local ones.

    Inputs that are not plain data are now rejected: class instances, Date, functions, typed arrays outside the two cases above, circular references, and nesting deeper than 64 levels. A snapshot rejection is reported as Invalid transaction provided, Invalid typed data, Invalid options provided, Invalid parameters provided or Invalid ABI provided, followed by the reason and the path to the offending value (for example Invalid options provided: unsupported Date at options.feeLimit). The reason-and-path suffix is specific to the snapshot check. Other errors keep their existing messages: the transaction checks in sign / multiSign still throw a bare Invalid transaction provided, and ABI encoding, parameter validation and node-side errors are unchanged.

    For signTypedData / verifyTypedData (and hashTypedData) these requirements apply to domain and types only. The value argument is not restricted by type: it is walked along the type definitions, each field declared in types is read once and handed to the EIP-712 encoder as it is (a Uint8Array is copied), and only the encoder's own per-type checks apply to the leaves. Fields that types does not declare are ignored as before, whatever they hold — a Date, a class instance or a function there is not rejected.

v6.5.0

New Features

  • Added trx.raw — chain reads without int64 precision loss

    Added a tronWeb.trx.raw namespace that mirrors the chain-reading methods of trx (getBalance, getAccount, getBlock, getTransaction, getTransactionInfo, getAccountResources, token / proposal / exchange queries, ...) but issues them as GET requests with int64_as_string=true (java-tron#6699). The node then serializes int64 / uint64 fields as JSON strings, so values above 2^53 - 1 (Number.MAX_SAFE_INTEGER) reach JavaScript without precision loss. Return types reflect this at compile time: int64 fields are typed (and arrive) as strings, via the new Types.Int64AsString / Types.Precise64 mapped types.

    • getCurrentBlock / getConfirmedCurrentBlock are rerouted in raw mode to the flag-honoring wallet/getblock?detail=true / walletsolidity/getblock?detail=true (getnowblock ignores the flag).
    • Reads that cannot take the flag keep returning numbers in both modes: getNodeInfo, listNodes, getBandwidthPrices, getEnergyPrices, getDelegatedResourceAccountIndexV2, getBrokerage / getUnconfirmedBrokerage, the deprecated getTransactionsToAddress / getTransactionsFromAddress / getTransactionsRelated, getSignWeight / getApprovedList, and getCurrentRefBlockParams (feeds local transaction building and must stay on the number path).
    • Requirements and caveats: the connected node must run a java-tron build that includes #6699 — older nodes ignore the flag and keep returning (possibly precision-lossy) numbers. Responses read via trx.raw must not be fed back into transaction-consuming endpoints (sendRawTransaction, getSignWeight, ...): the node rejects string-encoded int64 fields in request bodies.
    • The plugin system cannot override the raw sub-module.

Improvements

  • multiSign verifies the transaction returned by getSignWeight

    When multiSign is called with a permissionId on a transaction that does not carry one yet, it refreshes the transaction through getSignWeight and previously adopted the fullNode's response unchecked. It now verifies that the returned transaction matches the one submitted (including the injected Permission_id) before signing, and throws Invalid transaction provided otherwise — a compromised or malicious fullNode can no longer substitute a different transaction for signing.

  • Corrected Types.Proposal to match the node's JSON wire format

    Proposal.state is now typed as the enum-name string the node actually returns ('PENDING' | 'DISAPPROVED' | 'APPROVED' | 'CANCELED') instead of a numeric enum, and Proposal.parameters as the { key, value }[] array the node serializes instead of a key/value map. Runtime values are unchanged — the previous declarations did not match what getProposal / listProposals return; code type-checked against the old numeric state (e.g. state === 2) now fails to compile and should compare against the string form.

Changes

  • Migrated the test stack from mocha / karma / chai / nyc to Vitest 4 (node suite plus a headless-Playwright browser suite). Vitest runs the TypeScript test sources directly and provisions test accounts in its globalSetup, so the build:test / newaccount npm scripts are gone; test, test:watch, coverage and test:browser are the remaining test scripts.

v6.4.0

... (truncated)

Changelog

Sourced from tronweb's changelog.

Change Log

6.5.1

Improvements

  • Inputs are validated and processed from a plain-data snapshot

    Several APIs now take a plain-data snapshot of their inputs at entry and use that snapshot consistently for validation and processing. Previously they read the caller's object several times, so a Proxy or a getter could show the validation one value and hand a different one to the signing or the request. An operation is now always carried out against the same input state it was validated against.

    Affected: sign, multiSign, signTypedData (incl. _signTypedData, utils.typedData.signTypedData), ecRecover, newTxID (incl. extendExpiration, addUpdateData), ABI loading in Contract (constructor, loadAbi, at), and triggerSmartContract / triggerConstantContract / triggerConfirmedConstantContract / estimateEnergy (both the options and the parameters argument). Contract method .call() / .send() and the read / write namespaces inherit the same behavior.

  • Caller-provided objects are no longer modified

    • sign no longer appends to the transaction's signature array, and multiSign no longer writes Permission_id. Code that kept using the object it passed in must switch to the returned transaction.
    • triggerConstantContract / triggerConfirmedConstantContract / estimateEnergy no longer write internal flags into the options object, so a reused options object no longer carries them into later calls.
    • Contract no longer lowercases type / stateMutability in the caller's ABI, and contract.abi is now an internal copy. Edits made to the original ABI after loading no longer affect the contract instance.
  • Input requirements

    Snapshotting preserves bigint, and Uint8Array where it was already supported (typed-data byte values such as salt, bytes arguments in parameters / parametersV2). Plain objects and arrays from another realm (an iframe, a vm context) are accepted like local ones.

    Inputs that are not plain data are now rejected: class instances, Date, functions, typed arrays outside the two cases above, circular references, and nesting deeper than 64 levels. A snapshot rejection is reported as Invalid transaction provided, Invalid typed data, Invalid options provided, Invalid parameters provided or Invalid ABI provided, followed by the reason and the path to the offending value (for example Invalid options provided: unsupported Date at options.feeLimit). The reason-and-path suffix is specific to the snapshot check. Other errors keep their existing messages: the transaction checks in sign / multiSign still throw a bare Invalid transaction provided, and ABI encoding, parameter validation and node-side errors are unchanged.

    For signTypedData / verifyTypedData (and hashTypedData) these requirements apply to domain and types only. The value argument is not restricted by type: it is walked along the type definitions, each field declared in types is read once and handed to the EIP-712 encoder as it is (a Uint8Array is copied), and only the encoder's own per-type checks apply to the leaves. Fields that types does not declare are ignored as before, whatever they hold — a Date, a class instance or a function there is not rejected.

6.5.0

New Features

  • Added trx.raw — chain reads without int64 precision loss

    Added a tronWeb.trx.raw namespace that mirrors the chain-reading methods of trx (getBalance, getAccount, getBlock, getTransaction, getTransactionInfo, getAccountResources, token / proposal / exchange queries, ...) but issues them as GET requests with int64_as_string=true (java-tron#6699). The node then serializes int64 / uint64 fields as JSON strings, so values above 2^53 - 1 (Number.MAX_SAFE_INTEGER) reach JavaScript without precision loss. Return types reflect this at compile time: int64 fields are typed (and arrive) as strings, via the new Types.Int64AsString / Types.Precise64 mapped types.

    • getCurrentBlock / getConfirmedCurrentBlock are rerouted in raw mode to the flag-honoring wallet/getblock?detail=true / walletsolidity/getblock?detail=true (getnowblock ignores the flag).
    • Reads that cannot take the flag keep returning numbers in both modes: getNodeInfo, listNodes, getBandwidthPrices, getEnergyPrices, getDelegatedResourceAccountIndexV2, getBrokerage / getUnconfirmedBrokerage, the deprecated getTransactionsToAddress / getTransactionsFromAddress / getTransactionsRelated, getSignWeight / getApprovedList, and getCurrentRefBlockParams (feeds local transaction building and must stay on the number path).
    • Requirements and caveats: the connected node must run a java-tron build that includes #6699 — older nodes ignore the flag and keep returning (possibly precision-lossy) numbers. Responses read via trx.raw must not be fed back into transaction-consuming endpoints (sendRawTransaction, getSignWeight, ...): the node rejects string-encoded int64 fields in request bodies.
    • The plugin system cannot override the raw sub-module.

Improvements

  • multiSign verifies the transaction returned by getSignWeight

    When multiSign is called with a permissionId on a transaction that does not carry one yet, it refreshes the transaction through getSignWeight and previously adopted the fullNode's response unchecked. It now verifies that the returned transaction matches the one submitted (including the injected Permission_id) before signing, and throws Invalid transaction provided otherwise — a compromised or malicious fullNode can no longer substitute a different transaction for signing.

  • Corrected Types.Proposal to match the node's JSON wire format

    Proposal.state is now typed as the enum-name string the node actually returns ('PENDING' | 'DISAPPROVED' | 'APPROVED' | 'CANCELED') instead of a numeric enum, and Proposal.parameters as the { key, value }[] array the node serializes instead of a key/value map. Runtime values are unchanged — the previous declarations did not match what getProposal / listProposals return; code type-checked against the old numeric state (e.g. state === 2) now fails to compile and should compare against the string form.

... (truncated)

Commits
  • 974ea0b Merge pull request #723 from tronprotocol/release/v6.5.1
  • 90724ca Merge pull request #722 from Stan202310/release/v6.5.1
  • e56bf25 docs(typedData): describe what hashTypedData snapshots and what it only walks
  • c3d31bb docs(changelog): scope the reason-and-path error format to snapshot rejections
  • 11d17f0 docs(changelog): note that signTypedData does not restrict the type of value
  • 808a4fb fix(transactionBuilder): triggerSmartContract reads its parameters from a sna...
  • 099f808 fix(utils): clonePlainData keeps an own proto key as a data property of t...
  • 98fb1fc chore(deps): bump vitest toolchain to 4.1.11 to fix GHSA-82fw-gwwq-j7x9
  • bf545a7 Merge branch 'release/v6.5.1' of github-Stan202310:Stan202310/tronweb into re...
  • ebf5e44 test(utils): merge clonePlainData and cloneTransaction tests into clone.test.ts
  • Additional commits viewable in compare view
Install script changes

This version modifies prepare script that runs during installation. Review the package contents before updating.


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [tronweb](https://github.com/tronprotocol/tronweb) from 6.2.2 to 6.5.1.
- [Release notes](https://github.com/tronprotocol/tronweb/releases)
- [Changelog](https://github.com/tronprotocol/tronweb/blob/master/CHANGELOG.md)
- [Commits](tronprotocol/tronweb@v6.2.2...v6.5.1)

---
updated-dependencies:
- dependency-name: tronweb
  dependency-version: 6.5.1
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants