I'm contemplating introducing an alternative to Go templates for Helm. I don't think the main project will ever merge this, but I could implement it in my project, Nelm. This new option wouldn't make Go templates obsolete, but it could provide a more scalable and user-friendly alternative. This way, it would be easier to write, read, debug, and test as we scale up with many charts having lots of parameters. I want to prevent situations like some complex example charts I've seen on GitLab and GitHub.
I've done some research and ended up creating a proposal that includes a comparison table of various templating solutions like TypeScript, Python, JSONnet, and more. At this point, I'm leaning towards TypeScript since it seems stable for the long haul. What are your thoughts on this?
4 Answers
Helm 4 now allows you to use plugins to replace the Go templating layer. But honestly, post-renderers don’t really fix the core issues.
1. You need to install them separately, which means additional dependencies, losing the zero-dependency benefits.
2. They only expose rendered manifests, so expanded values and other files are left out. That’s not very flexible.
3. Fragmentation is a real concern because charts might be in multiple languages, complicating the development process.
So, while plugins are new, they don't provide much improvement over the existing Go templates for most use cases.
I completely agree with you about TypeScript! Its flexibility fits well with Kubernetes' CRD model. Having type support is super helpful when defining structures. I think using something that isn’t going to fade away like YTT or Dhall is crucial. Those languages can become dead ends if interest dwindles, unlike a mainstream language like TypeScript.
I think any new templating option should allow users to override values without modifying the chart directly. I’ve worked with Nix and found it really effective. What Helm does poorly is the requirement for users to either replicate the Kubernetes API or to underspecify, making charts unmodifiable without forking. If you're focusing on Kustomize for post-processing, go for it, but be prepared for some complexity!
Also, I’m skeptical about TypeScript handling nested structures effectively.
I’ve been building my own Kubernetes package manager which is a bit like what you're describing, but it prioritizes JavaScript. It simplifies many things: templates are more readable and you can modify manifests easily. However, it has its downsides too—like the challenge of supporting JavaScript libraries since the runtime has limitations.
One thing I love about this approach is it's fast! You can generate a lot of manifests quickly. While TypeScript is powerful, managing external libraries and ensuring smooth integration can be tricky.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically