fix: address module imports that end with .go

[meshuga]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

• Fixes Packages with . in them are incorrectly imported in mocks #481 generated mock incorrectly imports package ending in .go #249 Mock generation with NATS leads to import errors (version: 2.7.5) #419

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Version of Golang used when building/testing:

• 1.11
• 1.12
• 1.13
• 1.14
• 1.15
• 1.16
• 1.17
• 1.18

How Has This Been Tested?

See TestGetLocalizedPathVendored and TestGetLocalizedPathModule in generator_test.go

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[LandonTClipp]

Could you explain this a little more? Doesn't this break the caching logic if you have any local .go file that isn't under a vendor directory?

[meshuga]

Good point! I think we might break the logic in this case. It looks like I'd need to refactor the logic to ensure the path we want to preserve is only a directory and nothing else. I think we can look at the import struct we have to check

[LandonTClipp]

If you're vendoring a directory don't you want the returned path to be on-disk path instead of the URL?

[meshuga]

In golang code, you put imports to a vendored directory in same way as from modules, that's why this current logic is in place.

[LandonTClipp]

I see, I've never personally used vendored dependencies.

[meshuga]

Yeah, I used to. It's just a directory with all project dependencies in a form of a source code. In any case, we ought to check if a path element is a directory or not and if it's a file, remove it from path to build correct import statement.

[LandonTClipp]

@meshuga thanks for the contribution. I have a couple of comments/questions. Also, I'm adding table-driven tests for getLocalizedPath in #488. Could you rebase off of this once I merge it and add your test there? Thanks!

[meshuga]

@LandonTClipp I think you merged the PR too early, The PR didn't have any changes. I was digging a little bit deeper in the code to understand how imports are generated, taking more time than expected :)

[LandonTClipp]

That's really odd I didn't intend to merge this. I must have fat fingered something! Sorry about that.