Context

In older Cosmos-SDK versions, it was common to import the publicly exposed types
from a module by adding a "types" suffix to the package name. For example,

import (
  banktypes "github.com/cosmos/cosmos-sdk/x/bank/types"
  devgastypes "github.com/NibiruChain/nibiru/x/devgas/v1/types"
)

Task List

Implications

1. This means that the true package name, "types", has to be overwritten with an
   alias for each import. The Golang LSP (what your IDE understands) still considers
   all of the packages as having the name "types", so your IDE will only suggest
   variables if you start typing "types". You can't just type "banktypes" in a new
   file and see code suggestions.

2. When you use types from two modules at the same time or read code from within
   a module, you'll see a nonsemantic prefix, "types" everywhere. Essentially,
   package namespacing becomes irrelevant with this approach.

Suggestion

Follow the pattern of the nibiru/eth and nibiru/x/evm packages (also the
convention from v0.50 of the Cosmos-SDK) by using the top-level package of a
module for its types.

In other words, use bank.MsgSend instead of types.MsgSend or
banktypes.MsgSend.

Support Points:

1. Less namespace collisions: The module namespace is often completely unused aside from
   one place, which is the top-level "app" directory.

2. IDEs become more useful: You can type a module's name and have your IDE automatically suggest its types

3. Less aliasing: Using an alias for every import produces a bad code smell (opinionated take).

"Using a generic name makes it easy to accidentally use the wrong value in
a different file" - [Uber Golang Style Guide]

I'd argue that this argument holds for imports and not just for other
variables.