My team currently uses the v4.5 upgradeable contracts package and has been for almost a year.
We're looking to release our next set of tokens using ERC721A, which conflicts on a _isConstructor() private method sharing a name, which does not exist in the OpenZeppelin repo as of v4.6.
The easy fix is to just upgrade our npm package, as this is a new set of contracts. However, we have other products we will continue developing on that rely on v4.5 in this repo, and we're worried about breaking them if we do a repo-wide upgrade.
My questions are:
- Is there a way to specify the version in the imports, so we can have both v4.5 and v4.6/v4.7 packages installed locally, and in the Solidity file specify the import version?
- If we can't do that, can we just upgrade to v4.6 and know our old contracts on v4.5 will be equivalent? I assume not, but the fact that its a "minor" version rather than a "major" version change could mean the memory layout is identical, even if the code changed internally?
Hi @Carson_Roscoe, please make sure to post in #support:contracts next time for a faster response. (I've moved this post now.)
Yes, you can do this with npm. From npm docs:
npm install <alias>@npm:<name>:
Install a package under a custom alias. Allows multiple versions of a same-name package side-by-side, more convenient import names for packages with otherwise long ones, and using git forks replacements or forked npm packages as replacements. Aliasing works only on your project and does not rename packages in transitive dependencies. Aliases should follow the naming conventions stated in
npm install my-react@npm:react
npm install jquery2@npm:jquery@2
npm install jquery3@npm:jquery@3
npm install npa@npm:npm-package-arg
So you can do
npm install openzeppelin-contracts-4.5@npm:@openzeppelin/contracts@^4.5.0.
I don't really understand the source of this error you mention though. How are you trying to combine ERC721A with OpenZeppelin Contracts?
As a side note we would love to know the reasons that attracted you to ERC721A.