Solidity: Document or add Remix remappings when using upgradeable contracts

Aperta
  • Qualcosa non va?
#641 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
solidity
Ambito
blockchain, developer-experience

Direzione di ricerca

Inizia individuando il punto di ingresso della Wizard UI per aprire i progetti generati in Remix e l’output del progetto Remix generato. Confronta i due esempi di conflitti di importazione, quindi determina se il comportamento completato debba aggiungere automaticamente remappings.txt o documentare il remapping prima che gli utenti aprano il progetto in Remix.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Background

When opening a Solidity contract in Remix, the Contracts library version is appended to the import paths to ensure Remix uses a specific pinned version of the library, for example:

import {GovernorUpgradeable} from "@openzeppelin/[email protected]/governance/GovernorUpgradeable.sol";
Problem

In some cases when the contract directly references a contract or interface, and if the same contract/interface is referenced transitively through a different import, the transitive version is using the original path which causes a conflict.

This particularly occurs between upgradeable and vanilla Contracts dependencies, because the upgradeable variants import vanilla contracts using full paths rather than relative paths. The actual conflict itself occurs in vanilla dependencies, and is due to the inclusion/exclusion of version in its path.

Example 1

For example, when using Governor with ERC20Votes and Upgradeability, the following are in the direct imports:

import {GovernorVotesUpgradeable} from "@openzeppelin/[email protected]/governance/extensions/GovernorVotesUpgradeable.sol";
import {IVotes} from "@openzeppelin/[email protected]/governance/utils/IVotes.sol";

but GovernorVotesUpgradeable.sol itself has (note this is without @5.4.0)

import {IVotes} from "@openzeppelin/contracts/governance/utils/IVotes.sol";

This causes a compile error:

TypeError: Invalid type for argument in function call. Invalid implicit conversion from contract IVotes to contract IVotes requested.
  --> contract-3b3900f8c2.sol:22:30:
   |
22 |         __GovernorVotes_init(_token);
   |                              ^^^^^^
Example 2

A similar issue occurs for Account with Modules and Upgradeability since https://github.com/OpenZeppelin/contracts-wizard/pull/609, with the following imports:

import {Account} from "@openzeppelin/[email protected]/account/Account.sol";
import {AccountERC7579Upgradeable} from "@openzeppelin/[email protected]/account/extensions/draft-AccountERC7579Upgradeable.sol";

where draft-AccountERC7579Upgradeable.sol has

import {Account} from "@openzeppelin/contracts/account/Account.sol";

This causes a compile error:

DeclarationError: Identifier already declared.
  --> @openzeppelin/[email protected]/account/Account.sol:30:5:
   |
30 |     error AccountUnauthorized(address sender);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Note: The previous declaration is here:
  --> @openzeppelin/contracts/account/Account.sol:30:5:
   |
30 |     error AccountUnauthorized(address sender);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Solution

Remappings should be defined to remap the unversioned library path @openzeppelin/contracts/ to the versioned one. This will ensure compilation of all imports uses the same specified version.

This can be done by adding remappings.txt with the content:

@openzeppelin/contracts/=@openzeppelin/[email protected]/

We should either document the above (somewhere in the Wizard UI before the users opens in Remix), or if possible automatically add this into the generated Remix project.

Lingua principale
TypeScript
Stelle
296
Fork
188
Merge medio
3h 24m
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenZeppelin/contracts-wizard

Tutte le issue di OpenZeppelin/contracts-wizard

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.