Importing files in etherscan fails no matter how I do it.
Edit: And yes I know Remix has a flattener, but it doesn’t work correctly, nor can you verify contracts on etherscan with its API on Rinkeby.
Edit2: There is an error in either the OpenZeppelin truffle repo, or every flattener. One or the other. It’s loading the IERC165 out of order for whatever reason. Manually copy pasting solves it, but it makes deployment a true PITA. I truly despise truffle. One file is easier to debug and figure out security concerns. Treating smart contracts like other JS project is really a bad idea. So many errors and time wasted. /anti-truffle and mindless polymorphism rant.
TypeError: Definition of base has to precede definition of derived contract abstract contract ERC165 is IERC165
What compiler are you using? I’m using 0.6.6. It definitely doesn’t flatten properly, even with defaults. IERC165 gets called before it is declared. You have to paste it, and only it above ERC165 manually.
I’m thinking it’s a flattener issue in general now. Perhaps there is something weird in the OZ contracts though. That’s kind of the whole problem I have with truffle, you are on a deadline, and while I trust at a cusory glance my review of OpenZeppelin’s implementation, these kind of things make it more difficult.
Working from just the flattened file. My contract is only 1700 lines long with full comments. I struggle to see how a contract really excedes 3000 lines, so I think it’s best just to keep everything in one file. Much, much easier to audit and debug.
I’m moving my team off truffle for good now because of this issue. It’s just too many simple things wasting time that professionals cannot solve with logic. That’s a problem. Imports are bad!
Using a single flat file means that licence and import information is removed and makes it harder to read.
When importing via GitHub, you should specify the release tag, otherwise you will get the latest code in the master branch. For OpenZeppelin Contracts you should only use code published in an official release. (see Importing from GitHub in the Remix documentation).
Importing from the master branch can cause issues with verifying as the code in the master branch can change over time.
I would disagree on the making it easier to read, but that's a preference thing.
However, splitting up files in smart contract development can be extremely dangerous. People just compiling things they didn't read and go through is a very, very bad idea. This is probably the biggest security threat we face. Truffle is itself is potentially dangerous in the wrong hands. I know it doesn't apply to you, but I see very smart people doing very dumb stuff with smart contracts.
Now to preach; smart contracts are about the end user being able to easily read so they can feel secure. That is the only design pattern that should be considered in smart contract development for the foreseeable future, maybe ever. I get that there are advantages in development to the predominant approach, but that's just because most people come from a more recent development mindset of patterns existing for centralized realms, it doesn't mean it is a good idea.
Using a single flat file means that licence and import information is removed and makes it harder to read.
Flattening a contract in Truffle or Remix doesn't remove license details.
e.g. // File: https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/master/contracts/token/ERC1155/IERC1155.sol
// SPDX-License-Identifier: MIT
When importing via GitHub, you should specify the release tag, otherwise you will get the latest code in the master branch. For OpenZeppelin Contracts you should only use code published in an official release. (see Importing from GitHub in the Remix documentation).
I think you just made the best argument in the world for pushing flattened contracts in the dist folder with versions so we all can live happy, healthy, long lives.
...And to finish with the solution...Remix and Truffle flatteners seem to all mix up the order of OpenZeppelin. It think it's a simple bug from a library they both share. (Kids love to copy paste things they didn't read.) I just had to manually reorder the contracts. It works now. I hope this thread saves many hours for anyone in the future trying to compile.
Verification is a pain point for the ecosystem. Hopefully it won't be too long until there are easy options when deploying to a public network to also verify at the same time.
With flattening when using third party libraries, as long as licenses are maintained, ideally with references to the original source, then it is ok. Etherscan's outline functionality does make it much easier than it used to be to find sections of a contract. Up until recently I was verifying using flattened files.
My preference now is multi-file verification. It makes it much easier for me to tell if someone has extended from OpenZeppelin Contracts or if they have copy pasted and modified, which is much more complex to identify what has been changed.
Flattening may not remove SPDX License Identifiers (unless you tell the flattener to) but the flattened file won't compile if there are multiple license identifiers in the contract file.
(From: Solidity 0.6.8 introduces SPDX license identifiers)
It may be worth creating an Issue for the flattener you used to get this resolved.
Hopefully it won’t be too long until there are easy options when deploying to a public network to also verify at the same time.
Tron (not used it in a couple years though) does things better in almost every way, so deploying there is easy. The ABI is always public too. Love that part of it.
Flattening may not remove SPDX License Identifiers (unless you tell the flattener to) but the flattened file won’t compile if there are multiple license identifiers in the contract file.
(From: Solidity 0.6.8 introduces SPDX license identifiers)
I stand corrected. I was using 6.6 compiler. I think that is a poor decision to make citing licenses more difficult. It's for everyone's benefit.
I think licensing is an issue that needs to be rethought, and that compiler strategy not it. There are countries were the Berne Convention doesn't apply for example, and a couple where copyright doesn't exist. If you deploy a contract from these countries, it's permanently in the blockchain. Who to enforce it with?
I would love royalties baked into Ethereum contracts. Instead of being a punitive thing, encourage competition for boilerplate adoption. Consensys found out the hard way what happens when the ICO fad dies. Need consistent revenue for development.
When importing via GitHub, you should specify the release tag, otherwise you will get the latest code in the master branch. For OpenZeppelin Contracts you should only use code published in an official release. (see 
