feat: use helm as a libary instead of copying code #77
Conversation
|
This would revert #14 |
|
Using helm as a library does not seem uncommon, quite a lot of projects do this: https://github.com/helm/helm/network/dependents?package_id=UGFja2FnZS0yMjY3Mjg4NjYw |
|
Hi @qvalentin thanks for the info regarding using helm-core as library. By leveraging the Helm code directly, we inherently reduce the overhead associated with maintaining a separate, potentially divergent codebase. This shift not only streamlines our development process but also ensures that we benefit from the latest improvements and features added to Helm, keeping our project up-to-date and robust. Regarding the concerns about the increased binary size and potential breaking changes, these are valid points. However, the reduction in binary size with compression to 29M is quite efficient, and by prioritizing thorough testing, we can mitigate the risks of breaking changes effectively. This proactive approach in testing will safeguard our project's stability and reliability. |
|
Thanks for your opinion, I will take this as a approve for the proposed changes and will make it ready to be merged soon. |
qvalentin
force-pushed
the
feature/helm-as-libary
branch
from
267c880 to
d7ebaa0
Compare
qvalentin
force-pushed
the
feature/helm-as-libary
branch
3 times, most recently
from
5a1d672 to
d46aaab
Compare
qvalentin
force-pushed
the
feature/helm-as-libary
branch
2 times, most recently
from
48e1f3c to
736cc78
Compare
qvalentin
force-pushed
the
feature/helm-as-libary
branch
from
736cc78 to
fa2a239
Compare
* fork-master: (35 commits) Build only linux amd64 Support list of glob patterns feat: support values lookup for range on mapping (mrjosh#86) feat(symbol-table): read in template context with variables (mrjosh#85) fix: prevent panic on empty or unsupported template context (mrjosh#83) feat: use helm as a libary instead of copying code (mrjosh#77) feat: completion for unfinished_selector_expression fix: update ts grammar feat(completion): tests and refactoring feat(hover): template context hover usecase feat: references for templateContext feat: add references feat(reference): symbol-tables provides definition references feat(symboltable): add symboltable feat(docs): add coc config and reword readme build(deps): bump golang.org/x/net from 0.19.0 to 0.23.0 fix(handler): remove all unimplemented panics (mrjosh#73) fix(hover): format numbers correctly fix(hover): format list as yaml fix(go-to-definition): support range values ...
This change would include the official helm code as a dependency instead of copying only the code used for linting etc. to this project.
I would really like to get your input @mrjosh on such a design decision. Other people are also welcome to the discussion.
Advantages:
Disadvantages: