Am I doing this right? (open source go package)

<p>Hello community, I just put together a bit of middleware (for the might GNU Clacks) for some go frameworks, I&#39;d love to hear if I&#39;m doing this fun, tiny and ultimately useless thing right. The project is <a href="https://github.com/JonathanMH/goClacks">github.com/JonathanMH/goClacks</a>.</p> <p>I&#39;m specifically wondering if it&#39;s correct to suggest the import like I do and if I accidentally could bloat peoples projects by requiring other frameworks than the one they&#39;re using by having it in the dependencies.</p> <hr/>**评论：**<br/><br/>epiris: <pre><p>No, you are not. Your intuition was correct, it makes little sense to included the entire frameworks to add a http header. What I would do-</p> <p>first rename the package to follow Go naming guidelines, lowercase single word, such as clacks, repo name of go-clacks would result in import name of clacks. Typically it would be singular but plural is probably appropriate here. Reason: naming guidelines for Go, naming guidelines for writing software in general. You wouldn&#39;t use pythonClacks, rubyClacks or even php blacks, but the latter due to not using php of course.</p> <p>In most cases you would scrap making middleware all together, providing a less intrusive function to call. For example here you would probably just provide a single func in package clacks:</p> <pre><code>Terrify() (header, value string) </code></pre> <p>And then the type of framework doesn&#39;t matter. For this specific case since it&#39;s for learning, a better option would be to return a unnamed or concrete type that satisfies your target interfaces. Here you could provide:</p> <pre><code>Handler(http.Handler) http.Handler // return a new handler that just sets header </code></pre> <p>Most frameworks provide some kind of interop with http.Handler and those that don&#39;t can use the &#34;lower&#34; level API (a cost to their poor design)</p></pre>Asdayasman: <pre><blockquote> <p>php blacks</p> </blockquote> <p>Nothing wrong with dark-skinned people using PHP.</p></pre>devdvd: <pre><p>Yes there is. And for that matter there&#39;s something wrong with light skinned people using PHP as well. ☺️</p></pre>jonathanmh: <pre><p>I believe that was a typo ;)</p></pre>jonathanmh: <pre><p>Thank you very much for your reply!</p> <p>So I should find the way in each framework how I can pass the http.Handler to my function and just write the corresponding examples into the README or other documentation, got it.</p> <p>Renaming will also be fairly easy, I just wanted to categorize my repository on github, but yeah, it&#39;s a bit silly prefixing it. I&#39;ll keep the repository name, but rename the go package if that makes sense.</p></pre>epiris: <pre><p>No problem, it may be a simple project but you where asking all the right questions that will extrapolate as you tackle tougher problems. The big takeaway is to weigh each dependency you pull in heavily because that&#39;s what other developers do. You want to provide the minimal features in each package because the more features the more dependencies, which may drive away value from potential users. For the repo, it&#39;s good in general to have the same repo and package name and avoid case sensitivity. You will save people on other platforms, build systems, home grown CI/CD headaches from fat fingers, casing bugs, copy pasta from logs, and so on. All lower case package names, repo paths. It&#39;s important, i.e: github.com/user/lang-pkgname </p> <p>For an example why both these two things are important see how the casing of a highly used package that is highly depended on (while having many dependencies) see <a href="https://github.com/sirupsen/logrus/issues/451#issuecomment-264241243" rel="nofollow">issue #451</a>. Tldr is - The authors name use to have a capital S by it caused issues you can see in thread, but changing it causes more, due to many dependencies.</p> <p>Happy coding man.</p></pre>