Looking for feedback: Limited dependecies

[wneessen]

Hi everybody,

I am currently looking for some feedback - especially by some owners of bigger projects, that make use of go-mail (looking at you @james-d-elliott, @drakkan, @m90, @kolaente).

Since I've established go-mail I was always commited to keep go-mail dependency-free, meaning only relying on the Go Stdlib. So far this has been working well and I believe that people appreciate that no further dependcies are added to their project, when they import go-mail.

But I believe we're finally at the point where adding new features might require us to import some limited dependencies. For example SCRAM-support heavily relies on RFC compliant unicode manipulation that is not covered by the stdlib. It is covered by Google's golang.org/x/text package though. Porting or re-writing those RFC compliant methods would cause a huge overhead and maintenance burden. This is just one example. golang.org/x has some other packages that we might take advantage of as well oauth2 and crypto just as examples.

Therefore my question to the community: Are you ok if go-mail would add some limited dependencies like packages from golang.org/x or maybe some other currated dependencies that might add value? Or do you appreciate the "no-depencies" aspect and would prefer to keep it that way?

I've added a poll to get a quick overview but comments/feedback are of course welcome as well. Looking forward to it. I'll keep the poll open for a week end will then draw a conclusion.

[james-d-elliott]

There's a few opinionated views about this. Some people think maintaining everything is a risk and you shouldn't reinvent the wheel. Some think do it all yourself. I think some common sense needs to be applied, and a strong unyielding view in either direction is completely asinine. Provided you implement measures to detect dependencies that have updates, particularly those that have CVE's it doesn't matter a great deal.

Sometimes you will only find dependencies that are unmaintained and difficult to work with, and it may make more sense to implement something yourself. Sometimes the difficulty of implementing a particular spec or element will incentivize finding a dependency to handle it.

[kolaente]

I think this is a good stance on this. The key is having a process of dealing with CVEs and updates. GitHub's Dependabot or renovate do a lot here already.

[wneessen]

Thanks everybody for voting and for the valuable feedback. I think it's fair to say that most of you are ok with a limited, well curated list of external packages as long as the packages are still maintained and have a good security reputation. This helps a lot as it fits my views on the matter.