I've been looking at tools like dhall[0] over the past week to create more maintainable complex configuration files, and avoid repeating myself.
In any sufficiently sophisticated setup (kubernetes, the serverless framework, in-house tools) I find that configuration files can begin to grow out of control and become a maintenance nightmare, and custom tooling invariable emerges. I was looking into adding Dhall to our build pipeline to drastically shrink our configuration files, but encountered a few problems:
1. Everybody would have to learn dhall, which adds cognitive overhead to the engineering team
2. Installing dhall is an exceptionally involved procedure in our CI/CD pipeline, whereas we're already using JavaScript
So after considering how best to design a JavaScript-esque DSL and parse it without too much overhead, I figured that just loading in standard CommonJS code at runtime would be significantly easier.
I know it's a bit small in scope for a Show HN entry, but I'm certainly getting a lot of use out of it and wanted to share.
I'm always happy to hear constructive criticism and other thoughts on this!
To me one of the primary benefits of dhall is the type system checking that the structure of your data and its values match expectations. By using JavaScript don’t you lose all that?
Typescript can be used for type checking.
Disclaimer: I'm not familiar with jhall to know if it does or requires something inexpressible in Typescript.
Not in the slightest! jhall isn't a custom language, it loads in pure JS and spits out JSON or YAML. If the node interpreter can run it then it's fair game as far as jhall is concerned. Since Typescript compiles down to CJS you can use its output just fine - although admittedly it would be nicer to be able to run typescript files directly.
Another principle virtue of Dhall (stemming from the type system) is that it's total, so you know no funny business can go on when computing the configs. Even if you use typescript for (unsound) static type checking, you're definitely not going to get totality out of it.
If someone wanted dhall in JS, they could implement it, as has been done for Go, Ruby, Clojure, etc.[1]
Thanks for the article! jhall is definitely closer to what is described there than it is to a language like dhall - it provides a convenience wrapper around basic language features to programmatically generate configuration.
That is a tradeoff that you make using CJS, yes. You could write your config in typescript and then compile that down to CJS before usage, but admittedly that does add another step in the build process.
I am looking into enabling TypeScript/ES6 syntax in a future version of jhall to enable typing without extra build steps.
7 comments
[ 3.1 ms ] story [ 25.4 ms ] threadI've been looking at tools like dhall[0] over the past week to create more maintainable complex configuration files, and avoid repeating myself.
In any sufficiently sophisticated setup (kubernetes, the serverless framework, in-house tools) I find that configuration files can begin to grow out of control and become a maintenance nightmare, and custom tooling invariable emerges. I was looking into adding Dhall to our build pipeline to drastically shrink our configuration files, but encountered a few problems:
1. Everybody would have to learn dhall, which adds cognitive overhead to the engineering team
2. Installing dhall is an exceptionally involved procedure in our CI/CD pipeline, whereas we're already using JavaScript
So after considering how best to design a JavaScript-esque DSL and parse it without too much overhead, I figured that just loading in standard CommonJS code at runtime would be significantly easier.
I know it's a bit small in scope for a Show HN entry, but I'm certainly getting a lot of use out of it and wanted to share.
I'm always happy to hear constructive criticism and other thoughts on this!
--- 0: https://dhall-lang.org/
If someone wanted dhall in JS, they could implement it, as has been done for Go, Ruby, Clojure, etc.[1]
iiuc, this library is much more akin to the approach described in https://beepb00p.xyz/configs-suck.html
[1]: https://docs.dhall-lang.org/howtos/How-to-integrate-Dhall.ht...
I am looking into enabling TypeScript/ES6 syntax in a future version of jhall to enable typing without extra build steps.