Create a common folder

[pavel-raykov]

Moved files from chainlink/common to chains with the following caveats:

• chainlink/common/types files go directly to chains, other folders (fees, headtracker, txmgr) are copied as folders
• a new module github.com/smartcontractkit/chainlink-framework/chains has been created
• all the imports have been changed as follows:
  • "github.com/smartcontractkit/chainlink/v2/common/types" -> "github.com/smartcontractkit/chainlink-framework/chains"
  • "github.com/smartcontractkit/chainlink/v2/common/fees" -> "github.com/smartcontractkit/chainlink-framework/chains/fees"
  • "github.com/smartcontractkit/chainlink/v2/common/headtracker" -> "github.com/smartcontractkit/chainlink-framework/chains/headtracker"
  • "github.com/smartcontractkit/chainlink/v2/common/txmgr/types" -> "github.com/smartcontractkit/chainlink-framework/chains/txmgr/types" (txmgrtypes alias is collapsed whenever possible)

A one-to-one diff is available here https://github.com/smartcontractkit/chainlink/pull/15960/files

[jmank88]

This dependency is unfortunate. Although it looks like the only usages is for a SendTxReturnCode which has a binary state. I bet we could eliminate it. 🤔

[pavel-raykov]

Sorry, could you please clarify why you think this dependency is "unfortunate"? Do you mean that in general we want the code dependencies to be as simple as possible and this one complicates it, or is there any other reason to eliminate it?

[jmank88]

Dependencies between modules in the same repo can be a headache, since devs want to be able to update them both atomically, which forces us to use hacky local replaces. In this case, I think we should just switch to using a bool instead of a custom type with two values for success/fatal.

[pavel-raykov]

Ok, but what about txmgr/broadcaster.go and txmgr/confirmer.go that have a full-fledged switch logic for SendTxReturnCode? Do you think we should try changing them to also use boolean?

[jmank88]

No, there are actually many different kinds of meaningful codes. This module was only referencing two of them though. I don't think a bool is the answer, but there might be a different way to approach it, like by making the aggegrate func pluggable so that this module only deals with an opaque RESULT any. We can figure this out in a follow-up.

[jmank88]

LGTM, but let's see the chainlink/ PR build/test with this before merging 👍

[pavel-raykov]

LGTM, but let's see the chainlink/ PR build/test with this before merging 👍

This is the corresponding draft smartcontractkit/chainlink#15972 (I can update it once this is submitted)