-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Artifact is overwritten if there are two contracts with the same name #1087
Comments
Thanks for raising this @libertylocked. Unfortunately this is a limitation of the way Truffle handles artifact files right now. We have this work scheduled for 5.1, as it's a substantial effort. |
I find this issue important for projects that have a dependencies on other projects with collisions in the name of the contracts. General names as In any case, if it's scheduled to |
Thank you for raising this issue! It has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you would like to keep this issue open, please respond with information about the current state of this problem. |
Hi @gnidan ! Do you still plan to include this in 5.1? Do you know if there any progress regarding this issue? Thanks! |
Thanks for your response! This issue is no longer considered stale and someone from the Truffle team will try to respond as soon as they can. |
@gnidan that's a really nice document! I'm not sure I understood correctly, the idea is to use as part of the new schema new abstractions to differentiate between "Contract types" and "Contract instances" of it? I think this would solve this issue, but would it handle the problem of the "name collisions", I mean, if you depend on two projects that happen to use 2 contracts with the same name (i.e. Token), truffle will take those, compile them and put it in the Does this solution solve this other issue? |
Thank you for raising this issue! It has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you would like to keep this issue open, please respond with information about the current state of this problem. |
There has been no new activity on this issue since it was marked as stale 7 days ago, so it is being automatically closed. If you'd like help with this or a different problem, please open a new issue. Thanks! |
@anxolin Sorry I lost track of this. Yes, name collisions are being accounted for in the design! Also, that document has probably changed since you saw it. |
Thanks for the info @gnidan! looking forward to see this new version already! Is there a rough non-binding estimate time? (just curious) |
@anxolin is "not soon enough" a good answer? Can't say more now because we don't even have a complete picture of requirements. |
Thanks for your response! This issue is no longer considered stale and someone from the Truffle team will try to respond as soon as they can. |
Hehehhe, I understand, I hope you guys find the time to close the scope, :), maybe there’s something smaller that can be done and set things up in the right direction, i.e. something like making a new version, with the new format, but not implementing any of the new features but offers backwards compatibility |
It took me a long time to track down that this was the same issue I was having. I had a setup with:
and I could not figure out why I kept having my deployments fail with messages like "Contracts that inherit an abstraction must implement all its method signatures exactly." even though I knew all my methods were implemented. Turns out the artifact for the interface was overwriting the contract artifact (due to folder alphabetical ordering meaning the contract artifact was generated first, then the interface one was generated and overwrote it) so when it got to the deployment stage it was trying to deploy the interface instead. Renaming the interfaces (e.g. to i[name].sol) fixed the problem but it's an ugly workaround. Hopefully this issue can be solved, but if not, would it be possible to generate a warning or error during compilation if multiple artifacts with the same name are generated during a single compilation? |
Hi, As @Nanolucas mentioned, it would be awesome if Truffle could emit a warning if the json artifacts are corrupted because of a contract's name reused. We had many issues in Slither when it is the case. We had to develop a specific detector to know what contracts names are reused, but I think that a warning from truffle would help the users. Thanks |
This issue also affects interfaces that have the same name as a contract. More info here: #2951 |
Note: this is still blocked, because it requires Truffle to properly read from DB, which is not yet the case. |
Hi, Could you please share whether there is any timeline when to address this issue ? |
Is renaming the contracts the only solution for now? |
Sorry for the delayed response @Raunaque97. Yes, currently the only solution for this is to re-name your contracts. |
Issue
If there are multiple sol files with the same name but under different folders in contracts, for example if there's 3 sol files in contracts
Only one artifact will be generated when running
truffle compile
, because it's overwritten by the last contract compiled, typically by the one with greatest lexicographic order in full pathSteps to Reproduce
Make 3 contracts in contracts folder, with any code, as long as the 3 contracts are different
Run
truffle compile
, only 1 artifact is created inbuild/contracts
Expected Behavior
The artifacts should be placed in folders too and not just overwritten. So there should be
Which can be required by
artifacts.require("./Game1/Game.json")
and suchActual Results
Only one artifact is generated,
build/contracts/Game.json
, which is the artifact of the last contract compiled, in this casecontracts/Game2/Game.sol
Environment
truffle version
): Truffle v4.1.13 (core: 4.1.13)node --version
): v8.11.3npm --version
): 6.1.0The text was updated successfully, but these errors were encountered: