If I develop a module with several packages that have third party dependencies, will a go client that uses my module ALWAYS include the dependencies of all the packages in their binary? Another words, will the unused package dependencies of my module contribute to the size of the client binary?
1 Like
Hi, @Craig_Neuwirt,
The linker eliminates “dead code” from both libraries and your own code. That being said, there are limitations, not limited to:
-
If your code (or perhaps these 3rd party libraries?) use the
reflectpackage, you can look methods up so public methods can’t necessarily be eliminated. -
If those third party libraries register things (like image package - image - Go Packages, or sql package - database/sql - Go Packages, etc.) then they might not be eliminated because they might be reachable from whatever the registry is, etc.
If you’re asking, it sounds like you might have a more specific question to which maybe someone here can give you a more specific answer 
Thanks for the info Sean. I was hoping that was the case so I can avoid multi-module repositories and Go workspaces. I work on a library called Miruken and one of its objectives is to simplify the integration of other libraries through IoC patterns. I chose sub-packages for simplicity but don’t want unnecessary code bloat.
When you import a package from your module into your client code, Go’s dependency management system will analyze the imports to determine the necessary dependencies. It will then fetch and include only the required dependencies of the packages that are actually used in your client code.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.