Add TRON support to Contracts Wizard#806
Conversation
Introduces a TRON variant of the Solidity Wizard, targeting the TRON Virtual Machine via @openzeppelin/hardhat-tron and the @openzeppelin/tron-contracts library. What's included: - New top-level "TRON" tab in the UI nav (wizard URL: /tron) - New core utility `rewriteForTron` that maps ERC20/721/1155/4626 to TRC*, rewrites @openzeppelin/contracts paths to @openzeppelin/tron-contracts, and caps pragma at the tron-solc maximum (^0.8.26). - New `zip-hardhat-tron` generator emitting an @openzeppelin/hardhat-tron project (TRE network, tron-solc 0.8.26 + cancun + viaIR, plain ethers deploy script). - New `zip-tronbox` generator emitting a TronBox project with migrations and a Mocha test, in place of the Foundry download for TRON. - "Open in Remix" enabled for TRON with an @openzeppelin/tron-contracts remappings override (TVM is EVM-compatible enough for Remix). - Account tab and superchain cross-chain bridging omitted on TRON (no EntryPoint deployment / OP-stack pattern). - Per-tab labels overridable via `tabLabels` (TRC20/TRC721/TRC1155 on TRON; ERC* unchanged elsewhere). Tests: 15 new ava tests (rewriteForTron unit + hardhat-tron snapshot + tronbox snapshot). svelte-check passes on the UI package. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThis PR adds complete TRON ecosystem support to the OpenZeppelin Contracts Wizard. It introduces Solidity source code transformation for TRON compatibility, specialized project generators for Hardhat and TronBox environments, an extensible overrides system for UI customization, a dedicated TRON app component, and navigation/AI integration across the platform. ChangesTRON Ecosystem and Wizard Integration
🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Caution Review the following alerts detected in dependencies. According to your organization's Security Policy, you must resolve all "Block" alerts before proceeding. It is recommended to resolve "Warn" alerts too. Learn more about Socket for GitHub.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/core/solidity/src/utils/transform-tron.test.ts`:
- Around line 67-84: The test block for rewriteForTron has Prettier formatting
violations in the pragma-cap assertions; update the assertions in
transform-tron.test.ts to conform to project Prettier rules (consistent commas,
spacing, and line breaks) by reformatting the t.is(...) calls for the cases
using 'pragma solidity ^0.8.27', 'pragma solidity ^0.8.30', '^0.8.26', and
'^0.8.20' so they match the repository's prettier style (ensure proper trailing
commas, indentation and newline placement) without changing the expected strings
or the rewriteForTron function behavior.
In `@packages/core/solidity/src/zip-hardhat-tron.ts`:
- Around line 119-123: The generated README includes a plain "## Installing
dependencies" block with just "npm install" which will fail because the
template's package.json depends on not-yet-published TRON packages; update the
README template in zip-hardhat-tron.ts (the section that currently uses
this.getReadmePrerequisitesSection() and emits the "## Installing dependencies"
/ "npm install" snippet) to note that the TRON packages are not yet published
and either (a) instruct users to skip running npm install until those packages
are published or (b) provide a local development alternative (e.g., linking the
local packages via npm link / pnpm workspace or installing from local paths) and
remove the misleading bare "npm install" command.
In `@packages/core/solidity/src/zip-tronbox.ts`:
- Around line 206-207: The generated tronbox-sample README (created by
packages/core/solidity/src/zip-tronbox.ts) instructs users to run "npm install"
but does not warn that the dependency "`@openzeppelin/tron-contracts`" (^0.1.0)
may not be published; update the README generation in zip-tronbox.ts to add a
pre-install warning in the "## Installing dependencies" section that explicitly
calls out "`@openzeppelin/tron-contracts`" and tells users to verify the package
exists (or to run an alternative install command) before running npm install so
they won't hit a 404 during install.
In `@packages/ui/public/tron.html`:
- Around line 8-14: The /tron page is missing OpenGraph meta tags and Google Tag
Manager/Analytics snippets present on other public pages; update
packages/ui/public/tron.html to add the same OG tags (e.g., meta
property="og:title", "og:description", "og:image", "og:type", "og:url")
alongside the existing Twitter card tags and insert the GTM/GA snippets (the GTM
<script> in the head and GTM <noscript> iframe in the body plus the gtag init
snippet if used) so the page has parity with other wizard pages; mirror the
exact tag names and placement used in the other public HTML files to ensure
consistent social previews and analytics.
In `@packages/ui/src/tron/App.svelte`:
- Line 31: The tabLabels mapping is missing the ERC4626 key so TRC4626 tabs
don't match the TRON naming; update the tabLabels object (the property currently
listing ERC20, ERC721, ERC1155) to include ERC4626: 'TRC4626' so components
referencing tabLabels.ERC4626 will render the correct TRON label.
- Around line 38-42: The overrideZipFoundry currently always returns zipTronbox,
exposing a TronBox download even when opts.upgradeable is true; update the
overrideZipFoundry function to first check opts?.upgradeable and if true return
undefined (or otherwise short-circuit) to suppress the secondary TronBox
download, otherwise await zipTronboxModule and return zipTronbox(c, opts);
reference overrideZipFoundry, opts.upgradeable, zipTronboxModule, and zipTronbox
to locate and modify the code.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5c829279-1582-4e6b-a48e-8dfa7336018c
⛔ Files ignored due to path filters (4)
packages/core/solidity/src/zip-hardhat-tron.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/zip-tronbox.test.ts.snapis excluded by!**/*.snappackages/ui/public/icons/tron.svgis excluded by!**/*.svgpackages/ui/public/icons/tron_active.svgis excluded by!**/*.svg
📒 Files selected for processing (33)
packages/core/solidity/src/environments/hardhat/tron/package.jsonpackages/core/solidity/src/index.tspackages/core/solidity/src/utils/transform-tron.test.tspackages/core/solidity/src/utils/transform-tron.tspackages/core/solidity/src/zip-hardhat-tron.test.tspackages/core/solidity/src/zip-hardhat-tron.test.ts.mdpackages/core/solidity/src/zip-hardhat-tron.tspackages/core/solidity/src/zip-tronbox.test.tspackages/core/solidity/src/zip-tronbox.test.ts.mdpackages/core/solidity/src/zip-tronbox.tspackages/core/solidity/zip-env-hardhat-tron.jspackages/core/solidity/zip-env-hardhat-tron.tspackages/core/solidity/zip-env-tronbox.jspackages/core/solidity/zip-env-tronbox.tspackages/ui/api/ai-assistant/function-definitions/tron.tspackages/ui/api/ai-assistant/types/languages.tspackages/ui/api/ai.tspackages/ui/public/cairo.htmlpackages/ui/public/confidential.htmlpackages/ui/public/index.htmlpackages/ui/public/polkadot.htmlpackages/ui/public/stellar.htmlpackages/ui/public/stylus.htmlpackages/ui/public/tron.htmlpackages/ui/public/uniswap-hooks.htmlpackages/ui/src/common/languages-types.tspackages/ui/src/common/post-config.tspackages/ui/src/main.tspackages/ui/src/solidity/App.sveltepackages/ui/src/solidity/overrides.tspackages/ui/src/standalone.csspackages/ui/src/tron/App.sveltepackages/ui/src/tron/handle-unsupported-features.ts
Mirrors the existing per-ecosystem tool surface for TRON, so AI agents
(via MCP) and CLI users get TRC-correct source out of the box instead of
needing to manually rewrite imports/symbol names from solidity-* output.
What's new:
- packages/common/src/ai/descriptions/tron.ts -- TRON-flavored prompts
("Make a fungible token per the TRC-20 standard, ..."). Reused by both
MCP and CLI.
- packages/mcp/src/tron/ -- seven new MCP tools:
tron-trc20, tron-trc721, tron-trc1155,
tron-stablecoin, tron-rwa, tron-governor, tron-custom
Each wraps the corresponding @openzeppelin/wizard print function with
rewriteForTron(...). Schemas are reused verbatim from the Solidity
schemas (options are identical; only the source-level rendering
differs). Account is intentionally excluded -- same as the UI.
- packages/cli/src/registry.ts -- seven new tron-* CLI commands, same
shape and same rewriteForTron wrapping.
Notes:
- Solidity schemas are deliberately reused; no separate tron-* schemas
were added. If TRON ever diverges in option shape (e.g. an upgradeable
enum value that doesn't apply), the schemas can fork at that point.
- Upgradeable options stay accepted in the schemas. When upgradeable is
set on a TRON tool, the rewriter still produces TRC* names + tron
paths. Downstream usability of those imports still depends on
@openzeppelin/tron-contracts shipping upgradeable variants -- same gap
noted in the main PR description.
Tests:
- 15 new MCP ava tests across the 7 tools (all 78 mcp tests passing)
- 12 new CLI ava tests (7 auto-generated tron-* --help snapshots + 5
direct equivalence checks; all 89 cli tests passing)
- Lint clean on all new files
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Added MCP + CLI surface (commit 83046f7)Followed up with MCP tools (7):
CLI commands (7, same names). Try locally: Design notes:
Tests: 15 new MCP tests (78 total passing) + 12 new CLI tests (89 total passing). Lint clean. |
Targets the 5 actionable comments on PR OpenZeppelin#806: - transform-tron.test.ts: fold the four pragma-cap assertions into single-line t.is(...) calls so they conform to project Prettier rules (was flagged as a CI-blocker on the static-checks job). - zip-hardhat-tron.ts: prepend a temporary-limitation warning to the generated README's "Installing dependencies" section noting that @openzeppelin/hardhat-tron and @openzeppelin/tron-contracts may not yet be on the npm registry. Users get a clear hint when npm install 404s instead of a confusing failure. - zip-tronbox.ts: same warning for the TronBox template, mentioning @openzeppelin/tron-contracts. - tron.html: add parity meta tags + Google Tag Manager + GA snippets that all the other per-language pages already have so /tron has matching social previews and traffic analytics. - tron App.svelte: hide the TronBox download button when opts.upgradeable is set, mirroring the existing hardhat-tron gate (TronBox doesn't have an upgradeable workflow either, so the secondary download was reachable even when it would emit an unbuildable project). - Refactor Overrides.omitZipFoundry from `boolean` to `(opts?: GenericOptions) => boolean` so ecosystems can gate on per-call options the same way `omitZipHardhat` already does. Polkadot's existing `omitZipFoundry: true` becomes `() => true`. Snapshots regenerated for both zip-hardhat-tron and zip-tronbox. Not addressed: CodeRabbit also flagged a missing `ERC4626: 'TRC4626'` entry in tabLabels. The wizard does not have an `ERC4626` Kind/tab (the kinds are ERC20/721/1155/Stablecoin/RealWorldAsset/Account/ Governor/Custom), so tabLabels has no key to add. ERC4626 references that appear in generated source (e.g. from a tokenized-vault Custom contract) are already handled by `rewriteForTron`'s symbol pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The `check` job requires a changeset for any package-affecting diff. This PR bumps four packages (wizard, wizard-common, contracts-mcp, contracts-cli) — all patch-level, matching the project's existing convention of using `patch` for new features pre-1.0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Empty commit to force Socket Security to re-evaluate the PR after @SocketSecurity ignore-all was posted. The flagged packages (@aws-sdk/core, @aws-sdk/credential-provider-process) are transitive deps inside hardhat/upgradeable/package-lock.json which this PR doesn't modify. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Thanks for the PR! Some initial comments:
|
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Consider replacing
|
ericglau
left a comment
ericglau
left a comment
There was a problem hiding this comment.
Inline notes from a focused review of the TRON variant — correctness plus consistency with the patterns established by the other Wizard languages. The larger rewriteForTron → structured-transform suggestion is in a separate top-level comment.
- Gate `superchain` cross-chain bridging on the CLI and MCP TRON surfaces (previously only the UI sanitized it). Promote the gate to a shared `sanitizeTronOptions` helper in `@openzeppelin/wizard`, consumed by the UI, CLI registry, and MCP tron-* handlers so all three behave identically. - Fix unresolvable dependency ranges in the generated projects: the Hardhat template pinned `@openzeppelin/hardhat-tron: ^1.0.0` (excludes 0.x) and `tron-contracts: ^0.1.0` (excludes 0.0.1); align with the intended publish versions (`^0.1.0` / `^0.0.1`), and the same for the TronBox `package.json`. - Stop the TronBox migration from silently deploying `undefined`: non-address constructor args now emit commented-out declarations and the deploy call is commented out behind a TODO when any arg is unset, matching mainline zip-hardhat/zip-foundry behaviour (an unedited migrate errors or no-ops). - Add `override` to every method in `HardhatTronZipGenerator` that overrides `HardhatZipGenerator`, so it stays correct under `noImplicitOverride`. - Extract the TRON brand colour into a `--tron-red` CSS variable in vars.css, referenced from both App.svelte and standalone.css. - Keep the TRON-specific Governor `blockTime` note out of the shared Solidity description: revert `solidityGovernorDescriptions.blockTime` and add a TRON-only `tronGovernorSchema`/`tronGovernorDescriptions`, consumed by the tron-governor CLI registry entry and MCP tool. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Now that @openzeppelin/tron-contracts-upgradeable exists, wire it up end to end so upgradeable contracts work on TRON instead of being hidden. - rewriteForTron now maps @openzeppelin/contracts-upgradeable -> @openzeppelin/tron-contracts-upgradeable (run before the base-package pattern). The transpiled `*Upgradeable` parents resolve from the upgradeable package; the stateless proxy utilities (Initializable, UUPSUpgradeable) and interfaces stay on @openzeppelin/tron-contracts, which is its peer. - New utils/tron-upgradeable.ts: detects UUPS vs transparent, picks the right proxy (TRC1967Proxy / TransparentUpgradeableProxy from @openzeppelin/ tron-contracts), and emits the throwaway Proxy.sol that pulls the proxy into the build. - Hardhat (hardhat-tron) and TronBox downloads now deploy the proxy by hand — OpenZeppelin's Upgrades plugins target EVM chains and don't deploy to TRON. Each upgradeable project ships a Proxy.sol, a deploy script / migration that deploys the implementation then a proxy running initialize() atomically, an upgradeable-aware test that reads through the proxy, and the tron-contracts-upgradeable dependency. Initializer args with no safe default are left as gated TODOs so an unedited deploy never runs with missing values. - UI: un-hide the upgradeable Hardhat/TronBox downloads, add a Remix remapping for the upgradeable package, and hyperlink @openzeppelin/tron-contracts- upgradeable imports to that repo. - Tests: cover UUPS, transparent, and gated (non-address init args) cases for both generators, plus rewriteForTron's upgradeable mapping. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…urce
`rewriteForTron` ran a global regex over the rendered Solidity, so it couldn't
tell OpenZeppelin library symbols (which should be renamed) from user data
(which must not be). That silently corrupted real inputs:
- a token name/symbol containing a standard ("My ERC20 Token" / "ERC20") had
its `name()`/`symbol()` rewritten to TRC*, and the generated test then failed
by construction;
- a contract named `ERC20Token` became `contract TRC20Token` while the zip still
wrote `ERC20Token.sol` / `getContractFactory("ERC20Token")` — a name/artifact
mismatch that wouldn't compile;
- `securityContact` like `ERC20-team@…` was mangled;
- upgradeable initializers were left as `__ERC20_init(...)` (the `\b` boundary
fails after `__`), which doesn't exist in `@openzeppelin/tron-contracts-upgradeable`
(it ships `__TRC20_init`), so the upgradeable output didn't compile either.
Replace it with a structured `tronPrintProfile` plugged into `printContract` via
the `transformName` / `transformImport` hooks — the same mechanism the
upgradeable transpilation already uses. Because the hooks only see structured
`ReferencedContract` / `ImportContract` nodes, they remap only library symbols
and import paths; user data is never touched, and a `ERC20Token` contract keeps
its name while its inherited bases still become TRC*.
- options.ts: add `transformName` (symbol rename) and `solidityVersion` hooks;
add `transformInitName` so the upgradeable `__{Name}_init` keeps the base name
with the symbol rename applied (no `Upgradeable` suffix).
- print.ts: source the pragma from `opts.solidityVersion`; route parent
constructor / initializer names through the transforms. Mainline output is
byte-identical (full core suite passes unchanged).
- transform-tron.ts: export `tronPrintProfile` + `TRON_SOLIDITY_VERSION`
(capped); drop `rewriteForTron`. Hardhat/TronBox configs source the compiler
version from the same constant.
- Route every surface (UI display via `Overrides.printOptions`, zip generators,
CLI registry, MCP tron tools) through the one profile.
- Tests assert against the same profile and add coverage for the previously
corrupting cases; the upgradeable snapshots now correctly use `__TRC20_init`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Both rely on @openzeppelin/community-contracts (ERC20Restricted / ERC20Freezable for restrictions + freezable), which is not being ported to TRON — so they can't generate valid TRON output. Remove them from every TRON surface; TRON now covers TRC20 / TRC721 / TRC1155 / Governor / Custom (Account remains out of scope too). - UI: hide the Stablecoin + RealWorldAsset tabs (`omitTabs`); `defineOmitFeatures` / `sanitizeOmittedFeatures` now only handle ERC20's `superchain` gate. - UI API: drop the Stablecoin/RWA TRON AI function definitions, and narrow the `tron` contract-names type (`Omit<…, 'Account' | 'Stablecoin' | 'RealWorldAsset'>`) so the function-definition map stays in sync. - CLI: remove the `tron-stablecoin` / `tron-rwa` registry entries. - MCP: unregister and delete the `tron-stablecoin` / `tron-rwa` tools and tests. - common: remove `Stablecoin` / `RWA` from `tronPrompts`. - Drop the obsolete cli `tron-stablecoin` test; regenerate `--help` snapshots. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Thanks, this mostly looks good to me, pending some of the below TODOs below (some are blocked on @openzeppelin/tron-contracts npm publish):
|
2 participants
Summary
Adds a TRON variant to the Contracts Wizard, alongside the existing Solidity / Cairo / Stellar / Stylus / Polkadot / Confidential / Uniswap-Hooks tabs. The variant targets the TRON Virtual Machine via
@openzeppelin/hardhat-tronand the@openzeppelin/tron-contractslibrary./tron)TRC20/TRC721/TRC1155/TRC4626and@openzeppelin/tron-contracts/...paths via a centralizedrewriteForTronpost-processorpragma soliditycapped at^0.8.26(the currenttron-solcmaximum)@openzeppelin/hardhat-tron(TRE network,tron-solc 0.8.26+ cancun + viaIR, plain ethers deploy script — nohardhat-toolbox, nohardhat-ignition)tronbox-config.js,migrations/, and a Mocha test usingartifacts.require()@openzeppelin/tron-contractsremappings override (TVM is EVM-compatible enough to compile + deploy via Remix once the npm package is published)tabLabelsoverride — TRC* names show only on/tron, mainline Solidity is unaffectedAccounttab +superchaincross-chain bridging hidden on TRON (no EntryPoint deployment / OP-stack pattern)The upgradeable proxy flow is intentionally not enabled for TRON in this PR.
@openzeppelin/tron-contractsdoes not yet ship the transpiled*Upgradeablevariants that the wizard's upgradeable path depends on (e.g.TRC20Upgradeable,OwnableUpgradeable, etc.) — and@openzeppelin/hardhat-trondoesn't pull in@openzeppelin/hardhat-upgrades. So:omitZipHardhat: (opts) => !!opts.upgradeablehides the Hardhat (TRON) download button so we don't ship a zip that fails to install.When
@openzeppelin/tron-contractsships the upgradeable transpiled variants and a compatible TRON upgrades plugin is published, the next PR can remove theomitZipHardhatgate and wire the TRC*Upgradeable names intorewriteForTron.Other dependencies awaiting publish
The following packages exist in their GitHub repos but are not yet on the npm registry:
@openzeppelin/hardhat-tron@0.1.0(OpenZeppelin/hardhat-tron)@openzeppelin/tron-contracts@0.0.1(OpenZeppelin/tron-contracts)The wizard download zips reference them in
package.json. Until they publish,npm installinside the zip will 404 — same situation Remix's import resolver will see. No code changes are required here when they do publish; thepackage-lock.jsonfor the Hardhat (TRON) env is intentionally omitted sonpm installresolves fresh on first run.Files changed
Core (
packages/core/solidity):src/utils/transform-tron.ts+.test.ts— the post-processorsrc/zip-hardhat-tron.ts+.test.ts(+ snapshots) — hardhat-tron downloadsrc/zip-tronbox.ts+.test.ts(+ snapshots) — TronBox downloadsrc/environments/hardhat/tron/package.json— hardhat-tron env depszip-env-hardhat-tron.{ts,js},zip-env-tronbox.{ts,js}— UI entry-point re-exportssrc/index.ts— exportsrewriteForTronUI (
packages/ui):src/tron/App.svelte+handle-unsupported-features.ts— TRON wizard variantsrc/solidity/overrides.ts— extended withtabLabels,overrideZipFoundry,secondaryDownloadLabel,secondaryDownloadAction,omitOpenInRemix,overrideVersionedRemappings,transformPrintedContractsrc/solidity/App.svelte— wired all new override hookssrc/main.ts,src/common/languages-types.ts,src/common/post-config.ts,api/ai.ts,api/ai-assistant/types/languages.ts,api/ai-assistant/function-definitions/tron.ts— newtronlanguage wiringpublic/tron.html+ nav entry on all 7 other per-language pagespublic/icons/tron.svg,public/icons/tron_active.svg— placeholder TRON brand icon (happy to swap for the official mark)src/standalone.css—.switch-tron.activebrand color (#ff060a)Test plan
yarn avainpackages/core/solidity: 15 new tests pass (transform-tronunit +zip-hardhat-tronsnapshots +zip-tronboxsnapshots)npx tsc --noEmitclean onpackages/core/solidityyarn validate(svelte-check) clean onpackages/ui(one pre-existing a11y warning inDropdown.svelte, unrelated)yarn lintclean on all new files/,/tron,/polkadotall render with TRON in the nav; TRON shows TRC* tab labels, hides Account + Remix imports resolve correctly; mainline Solidity unaffected@openzeppelin/hardhat-tronand@openzeppelin/tron-contracts)// Compatible with OpenZeppelin Contracts ^5.6.0headerGenerated TRON sources still emit the standard wizard provenance comment at the top of every contract, e.g.:
The version (
^5.6.0) is pinned to mainline@openzeppelin/contractsviapackages/core/solidity/openzeppelin-contracts-version.jsonand rendered byprintCompatibleLibraryVersionsinpackages/core/solidity/src/print.ts. For TRON output this is misleading — the imports are from@openzeppelin/tron-contracts, not mainline contracts, so the comment should say something like// Compatible with OpenZeppelin TRON Contracts ^X.Y.Z(or be omitted) once the TRON contracts library has a stable release line. This needs to be updated when@openzeppelin/tron-contractsis adjusted to a published, semver-tracked version. Tracking as a follow-up below; intentionally left as-is in this PR because changing the print pipeline to be ecosystem-aware deserves its own focused review.Follow-ups (not in scope for this PR)
// Compatible with OpenZeppelin Contracts ^5.6.0header for TRON output when@openzeppelin/tron-contractslands a tagged release. Options: (a) extendprintCompatibleLibraryVersionsto be ecosystem-aware so it can emitOpenZeppelin TRON Contracts ^X.Y.Zwhen the imports resolve to@openzeppelin/tron-contracts, or (b) rewrite the line insiderewriteForTron. Either way, the version source needs to track the tron-contracts package, not mainline.tron-contractsships*Upgradeablevariants (see above)tron.svgicon for the official TRON brand markoverrideRemixURLto point TRON users at TronIDE (a TRON-configured Remix fork) instead ofremix.ethereum.orgpackage-lock.jsonvia the existingupdate-envscript🤖 Generated with Claude Code