Add forceConstructorArgs feature

[hellwolf]

Constructor arguments override (Optional)

You can additionally provide an explicit constructor arguments for the contract. This is useful if the contract was created by another contract instead by an EOA.

This feature has to be used together with the address overriding, e.g.:

truffle run verify SuperToken@0x439e79a6F03bDbB1cCBE14B9227c87f6822AD2B1@0000000000000000000000000cb966d6a7702a4eff64009502653e302b3ec365 --network goerli

[rkalis]

Hey @hellwolf, thanks for raising this PR! We probably want to support something like automatic argument encoding in the future, but for now I think it is a good workaround to provide the encoded args, so I'm happy to merge in this change.

One thing though is that it would be nice to be able to use this without also having to use the address override, so I'd suggest either using a different separator character for the args (e.g. |) or adding it as a flag --constructorArgs <value>. I don't have a clear preference, so feel free to choose what you think makes sense.

[hellwolf]

Hi!

I agree that using an option is a better way, but I don't know the code enough to make such suggested changes. The workaround was a quick hack I had to make. If you could point me some hint how to add an option that'd be helpful for me to modify it

[rkalis]

Alright, no worries! If you want to take it on, I wrote this article which explains Truffle plugins in a bit more detail: https://kalis.me/creating-truffle-plugins/

What it boils down to is that any flags (e.g. --abc) will end up as a named property inside the config object (e.g. config.abc) that gets passed into the main plugin function (line 13). That is all done with Truffle magic.

Then from there truffle-plugin-verify includes a parseConfig(config) function, which extracts/transforms the relevant values from the config object, the return value of that function is the "options" object that gets passed around in the rest of the plugin.

So if you want to add a new flag --constructorArgs you need to add some code to parseConfig that takes config.constructorArgs and returns it in the "options" object.

Let me know if that makes sense or if you need some more help. Thanks again!

[hellwolf]

It was actually quite easy to do:

https://github.com/hellwolf/truffle-plugin-verify/blob/cb7b35f645e5ffc087281db5e751e484ac047d56/verify.js#L28

BUT, it doesn't work for one of our cases because

npx truffle --network goerli run etherscan Superfluid@0x53C8a072165Db2D67Fe43455948BE125073A2F60 --forceConstructorArgs "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

option.forceConstructorArgs was casted to number "0", instead of the raw string value

🤦 🤦 🤦 🤦 🤦

I probably would need to hack the command line format to avoid this problem, like

forceConstructorArgs ":00000000000000000000000000000000000"

Do you have any thoughts on this?

[rkalis]

Oh wow that is interesting. I'm guessing it gets converted by Truffle, let me look into it more.

[hellwolf]

npx truffle --network goerli run etherscan Superfluid@0x53C8a072165Db2D67Fe43455948BE125073A2F60 --forceConstructorArgs string:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

I propose this workaround format:

string:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

string denoting the type, and the following is the actual value

[hellwolf]

@rkalis what do you think of the above proposal, a optional argument "forceConstructorArgs" with prefixed type "string:" as workaround to the truffle issue.

[rkalis]

Hey @hellwolf, sorry for dropping the ball on this one. The solution seems a good workaround. I made a few minor changes and updated the README. Will publish this in a new version now.

[rkalis]

Just published this new feature in 0.5.8, thanks for the contribution!