Expose svu functionality as a library and internal refactoring #126
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses the need to use
svu
as a go library directly in code (partially addresses #123) and introduces internal refactoring for maintainability.I've exposed the public API in
pkg/svu
, allowing developers to usesvu
as an import name directly in their code asgithub.com/caarlos0/svu/pkg/svu
.The exposed API uses a variadic options pattern, which mitigates the risk of future interface breaking changes. This approach ensures easy maintenance through adapter functions and flexibility for
internal/svu
to implement changes and new features without being restricted with the API contract.I had to move some functionality from the main package to
internal/svu
. This does introduce a dependency oninternal/git
ininternal/svu
that can be resolved if needed, maybe moving that code topkg/svu
instead?I've defined constants with command names and tag-mode options to prevent mismatches. However, this change has not been extended to the CLI yet, just in case it's not desired.
Open PR Conflict:
I've noticed an open PR (#125) that conflicts with these changes. I'm open to adapting my code to resolve any conflicts that may arise once that PR is merged. Alternatively, I'm willing to assist in adapting the code in #125 to ensure a smoother merge process if this PR is merged before.
I welcome any input, adjustments, or recommendations from both the community and maintainers to improve this solution and maximize its usefulness for
svu
users.