Decide about putting `claim` in its own repo

[lumtis]

claim module is aimed to be imported by other projects.
It may make sense to move the module to its own repo with its own docs to emphasize its independency.

Solutions:

• Keep under spn
  • Drawback: doesn't emphasize module independency
• Minimal repository:
  • Only the module repository with proto definition with no environment (no app, no simulation tests)
  • Drawback: no simulation tests integrated
• Chain with module imported
  • Regular chain with app dir, simulation test, etc...
  • Drawback: may need to reimplement testutils etc...
• Repository for all independent modules we may have
  • Repo named like modules that integrates modules aimed to be imported by other projects as well
  • Might be the case with mint: Making mint module universal #895
  • Drawback: emphasize less on the module independency

[lumtis]

Let's wait upgrading everything to 0.46 before doing claim migration #906

[lumtis]

As we will work in several different independent modules. The idea would be to have ignite/modules with a test application inside for CI and test purposes

[tbruyelle]

The idea would be to have ignite/modules with a test application inside for CI and test purposes

Actually I was wondering if we can avoid integration test with custom modules. Indeed we can mock all their interactions with other modules thanks to the interfaces declared in expected_keepers.go, the other interaction I'm aware of is the KVStore, but I don't know if we can mock it.

[lumtis]

Maybe related to your point? #807

We use for now a package testutils/keeper for all tests where all keepers are initialized, but the idea in the future is to define mocks for every module so that tests for a single module can be isolated.

I think there is some room to define a generic test framework for SDK modules that could be located in ignite/modules and spn would use this framework

For the initial point, ignite/modules will also need a sample app to perform simulation tests with the modules