chiru-labs / erc721a-upgradeable Goto Github PK

License: MIT License

JavaScript 44.39% Shell 0.62% Solidity 54.99%

erc721a-upgradeable's Introduction

📢 Version 4.x introduces several breaking changes. Please refer to the documentation for more details.

We highly recommend reading the migration guide, especially the part on supportsInterface if you are using with OpenZeppelin extensions (e.g. ERC2981).

About The Project

This repository hosts the Upgradeable variant of ERC721A, meant for use in upgradeable contracts. This variant is available as separate package called erc721a-upgradeable.

This version uses the diamond storage layout pattern.

It follows all of the rules for Writing Upgradeable Contracts: constructors are replaced by initializer functions, state variables are initialized in initializer functions, and we additionally check for storage incompatibilities across minor versions.

Warning

There will be storage incompatibilities across major versions of this package, which makes it unsafe to upgrade a deployed contract from one major version to another, for example from 3.4.0 to 4.0.0.

It is strongly encouraged to use these contracts together with a tool that can simplify the deployment of upgradeable contracts, such as OpenZeppelin Upgrades Plugins.

This repository is generated by a transpiler.

Chiru Labs is not liable for any outcomes as a result of using ERC721A and ERC721A-Upgradeable. DYOR.

Docs

https://chiru-labs.github.io/ERC721A/

Installation

npm install --save-dev erc721a-upgradeable

Usage

Once installed, you can use the contracts in the library by importing them:

pragma solidity ^0.8.4;

import 'erc721a-upgradeable/contracts/ERC721AUpgradeable.sol';
import '@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol';

contract Something is ERC721AUpgradeable, OwnableUpgradeable {
    // Take note of the initializer modifiers.
    // - `initializerERC721A` for `ERC721AUpgradeable`.
    // - `initializer` for OpenZeppelin's `OwnableUpgradeable`.
    function initialize() initializerERC721A initializer public {
        __ERC721A_init('Something', 'SMTH');
        __Ownable_init();
    }

    function mint(uint256 quantity) external payable {
        // `_mint`'s second argument now takes in a `quantity`, not a `tokenId`.
        _mint(msg.sender, quantity);
    }

    function adminMint(uint256 quantity) external payable onlyOwner {
        _mint(msg.sender, quantity);
    }
}

Contributing

This repository is automatically transpiled from the main ERC721A repository by a workflow.

Any changes to the contracts and test directories will be overwritten.

If you want to make a contribution to the transpiler workflow:

Fork the Project
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit your Changes (git commit -m 'Add some AmazingFeature')
Push to the Branch (git push origin feature/AmazingFeature)
Open a Pull Request

Running tests locally

npm install
npm run test

License

Distributed under the MIT License. See LICENSE.txt for more information.

Contact

2pm.flow (owner) - @2pmflow
location tba (owner) - @locationtba
cygaar (maintainer) - @cygaar_dev
vectorized.eth (maintainer) - @optimizoor

Project Link: https://github.com/chiru-labs/ERC721A-Upgradeable

erc721a-upgradeable's People

Contributors

Stargazers

Watchers

erc721a-upgradeable's Issues

Wrong modifier

I think it should be initializerERC721A() in https://github.com/chiru-labs/ERC721A-Upgradeable/blob/main/contracts/ERC721AUpgradeable.sol#L96 instead of onlyInitializingERC721A()

Proposal: Separate internal and public functions into different files to help with Diamonds

I'm using the Diamond standard and it would be useful for me to be able to _mint() from multiple facets.

However, multiple facets cannot inherit from ERC721AUpgradeable because ERC721AUpgradeable has public functions and multiple facets cannot define the same public function.

I propose adding a ERC721AInternal contract that Diamond-ers can inherit from in multiple places. This would not affect anyone else as they could continue inheriting from ERC721AUpgradeable (basically what I'm proposing is a copy-paste).

SolidState takes this approach for their ERC721, so it has been done!

Thanks!

is 4.0.0 stable?

sorry for the question as an "issue", but didn't see another venue for such things. are you planning on publishing 4.0.0 to npm, or should i wait for 4.0.1?

cheers and thanks for your efforts!

Missing `override` specifier

Trying to use the ERC4907AUpgradeable contract with the ERC721A contract and I'm getting a

TypeError: Overriding function is missing "override" specifier.
  --> erc721a-upgradeable/contracts/extensions/ERC4907AUpgradeable.sol:61:5:
   |
61 |     function userOf(uint256 tokenId) public view virtual returns (address) {
   |     ^ (Relevant source part starts here and spans across multiple lines).
Note: Overridden function is here:
  --> erc721a-upgradeable/contracts/extensions/IERC4907AUpgradeable.sol:42:5:
   |
42 |     function userOf(uint256 tokenId) external view returns (address);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


TypeError: Overriding function is missing "override" specifier.
  --> erc721a-upgradeable/contracts/extensions/ERC4907AUpgradeable.sol:79:5:
   |
79 |     function userExpires(uint256 tokenId) public view virtual returns (uint256) {
   |     ^ (Relevant source part starts here and spans across multiple lines).
Note: Overridden function is here:
  --> erc721a-upgradeable/contracts/extensions/IERC4907AUpgradeable.sol:47:5:
   |
47 |     function userExpires(uint256 tokenId) external view returns (uint256);

Also, likely unrelated, but I'm required to override the supportsInterface function, but am getting a

TypeError: Invalid contract specified in override list: "IERC721AUpgradeable".
  --> contracts/myContract.sol:72:9:
   |
72 |         override(
   |         ^ (Relevant source part starts here and spans across multiple lines).
Note: This contract: 
  --> erc721a-upgradeable/contracts/IERC721AUpgradeable.sol:10:1:
   |
10 | interface IERC721AUpgradeable {
   | ^ (Relevant source part starts here and spans across multiple lines).

On pragma solidity ^0.8.4;

Here's my inheritance list:

contract CurdRouletteTableNft is
    ERC721AUpgradeable,
    Initializable,
    AccessControlUpgradeable,
    ERC721ABurnableUpgradeable,
    ERC721AQueryableUpgradeable,
    ERC4907AUpgradeable,
    UUPSUpgradeable

Happy to make necessary change and post a PR for review

ERC721A Upgradeable v3.3.0 Update

In the most recent update for ERC721A (v3.3.0) the upgradeable version of the contract now has a constructor instead of an initializer function. Was this intended?

In addition the Upgradeable suffix has been removed from the contracts. I believe this may be a mistake.

📢 Breaking changes in v4.x

Version 4.x introduces several breaking changes.

Please refer to the documentation for more details.

Maybe Bug: explicitOwnershipOf doesn't work correct on our ERC721G contract

OwnableUpgradeable Declares State Variables Outside Diamond Storage

The example code on the README file inherits OwnableUpgradeable.sol from OpenZeppelin. OwnableUpgradeable.sol declares state variables outside Diamond Storage which can lead to storage collision if any other contracts, or inherited contracts declare state variables outside Diamond Storage. The best practice for diamonds is to declare all state variables within AppStorage or Diamond Storage.

SafeOwnable.sol from solidsate-solidity could be used instead, or other implementation.

Cyclic dependencies in ERC721AUpgradeable.sol and ERC721AStorage.sol

Issue: Cyclic dependencies in ERC721AUpgradeable.sol and ERC721AStorage.sol cause Hardhat flatten error.

Error Message:

Error HH603: Hardhat flatten doesn't support cyclic dependencies.
For more info go to https://hardhat.org/HH603 or run Hardhat with --show-stack-traces

Version: 4.2.0

Cyclic Dependencies Code:

ERC721AUpgradeable.sol line 8

import {ERC721AStorage} from './ERC721AStorage.sol';

ERC721AStorage.sol line 5

import {ERC721AUpgradeable} from './ERC721AUpgradeable.sol';

Is this code dependency approach intentional?
Thank you :D