Why commit typechain types?

[sebastiantf]

I see that you started checking in types generated by typechain into version control starting from this commit: 4eaa67e

Typechain docs suggests not to commit the generated types though.

Having the types checked in along with the contracts does seem good. But the biggest con of that I've noticed is having to keep track of all the types and factories in .gitignore like you've done in the hifi packages

Would love to know what finally pushed you to this approach

[PaulRBerg]

Hey @sebastiantf, the rationale is that I want to nudge my template users to ship the types as part of the publicly distributed npm package. For instance, see the published types of the @hifi/amm package.

There are lots of benefits to having the types as part of the npm package - the main one being that your package users would enjoy type safety when working with your smart contracts.

That comes at the cost of having to somehow track the types over time, and committing them in version control is the best way to do that. I know it's a chore to add many additional lines in .gitignore, but there's a lot of third-party contracts that must be excluded from both git and npm, and I know no better way to achieve that than excluding the entire types directory by default and add bespoke rules to skip the types that should be kept.

[sebastiantf]

Thanks!

Maybe the .gitignore chore is something that can be handled by hardhat-packager too?

[PaulRBerg]

I don't think so, because hardhat-packager cannot know what other files you want to git ignore.

I know that this isn't ideal - I'm still investigating better options.

[sebastiantf]

Doesn't hardhat-packager have the contracts config? It can just append to the existing gitignore?

[PaulRBerg]

Hmm that's an interesting idea .. could you create a discussion for it in the hardhat-packager repo?

[sebastiantf]

Done: PaulRBerg/hardhat-packager#15