Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: remove duplicate imports #2185

Merged
merged 2 commits into from
Sep 6, 2022
Merged

chore: remove duplicate imports #2185

merged 2 commits into from
Sep 6, 2022

Conversation

damiannolan
Copy link
Member

Description

  • Cleanup import aliases in ICS27 msg_server_test.go

closes: #XXXX


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@@ -18,7 +16,7 @@ import (

func (suite *KeeperTestSuite) TestRegisterAccount() {
var (
msg *controllertypes.MsgRegisterAccount
msg *types.MsgRegisterAccount
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we have icatypes, clienttypes channeltypes etc. does it make sense to have a package imported as just types? It's not immediately obvious which sort of types it is, I would lean in favour of keeping it called controllertypes and removing the unaliased one WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a lot of other packages we normally import the relative types pkg as is, and then for any types pkgs from other modules we alias them.

I don't really feel strongly about it here. It's also a test file so.. 🤷

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For interchain accounts it may help to always alias tho. Considering there is the shared icatypes and then a separate types for both controller and host submodules

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah I see okay, so we generally just do external types with the alias, that seems fine with me 👍

@damiannolan damiannolan enabled auto-merge (squash) September 6, 2022 11:36
@damiannolan damiannolan merged commit 96b0aae into main Sep 6, 2022
@damiannolan damiannolan deleted the damian/fix-linter-errs branch September 6, 2022 12:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants