Solidity: Document or add Remix remappings when using upgradeable contracts

Abierto
  • ¿Algo no está bien?
#641 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
solidity
Área
blockchain, developer-experience

Línea de trabajo

Comienza localizando el punto de entrada de la Wizard UI para abrir proyectos generados en Remix y la salida del proyecto Remix generado. Compara los dos ejemplos de conflictos de importación y determina después si el comportamiento final debe añadir remappings.txt automáticamente o documentar el remapeo antes de que los usuarios abran el proyecto en Remix.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
296
Forks
188
Merge medio
3 h 24 min
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenZeppelin/contracts-wizard

Todos los issues de OpenZeppelin/contracts-wizard

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.