Open nitrocode opened 1 year ago
This is very nice!!
Shameless plug: as an alternative to https://github.com/pkg/errors
, you can switch to drop-in replacement gitlab.com/tozd/go/errors
. It fixes many issues, is maintained, and supports modern Go's error patterns (sentinel errors, %w formatting, joined errors, etc.). It also provides some nice utility functions and structured details so that it is easy to extract dynamic data out of errors (instead of trying to get them out of formatted strings). Has improved error formatting and JSON marshaling of errors. It is interoperable with other errors packages and does not require a dependency on itself to extract data (e.g., stack trace) from errors.
@mitar what about just the errors
package? How does it compare?
I'm hesitant to push this project to replace an archived dependency for one that's uncommonly used (judging by project stars)
@nitrocode I completely understand. But it is a bit of chicken & egg problem. :-)
I think the questions for you is if you need/want stack traces or not. If you do, then this package provides almost the same API as the standard errors
package, but with stack traces (see here for details). Also using this package and in the future (hopefully once stdlib gets stack traces) moving to errors
should also be easy as my package provides compatible API. Of course, if you find additional helper functions it provides as well, for common patterns, useful, then you can use them as well.
Community Note
Describe the user story
There are a lot of dependencies that may not be needed. Some dependencies are years old and could be vulnerable. The fewer dependencies, the less risk.
Describe the solution you'd like
It would be good to audit our dependencies and find ones that could be easily replaced or removed. We should use non forks if possible unless there is a good reason to use a fork.
It would also be good to scrutinize new PRs with additional dependencies to ensure we do not unnecessarily increase our exposure. For example, we should never use a dependency that is a fork or archived, possibly abandoned, not widely used, has old dependencies, or open security issues.
List of current dependencies https://github.com/runatlantis/atlantis/network/dependencies
Some old dependencies from a cursory look
Analyzing these will simplify dependent management via renovatebots dashboard https://github.com/runatlantis/atlantis/issues/2818
Direct
archived
errors
archived no longer
old
For testing
These do not get compiled with Atlantis
Indirect
These come from other dependencies and need to be analyzed to find the direct source
https://stackoverflow.com/a/68927825/2965993
Some tools that may be useful
Here are all the go.mod code references sorted in ascending order
Describe the drawbacks of your solution
Potential breakage of the app unless proper unit and integration test coverage is there.
Describe alternatives you've considered
None