I've only worked with cdk8s, but the experience of that alone was enough for me to regret it. It's not that cdk8s is bad, per-se, it's that it turned an otherwise declarative kubernetes config into something that was much harder to grok in the first instance.<p>One of the arguments for TS in the post is that it can encourage DRY. It was DRY that made this TS-based kubernetes config so hard to follow, because simple repetitive statements got abstracted into parameterised functions, or classes to inherit from, or other things that are resolved dynamically at runtime. Not to mention that you're also going to start mixing in random dependencies from NPM to help abstract things further. This is great for application development but not so great for pure configuration.<p>A language designed for config, like Dhall or CUE, can give you much of what a typed language offers without letting you go crazy with a full-blown language runtime.
Except ....<p>(...No one asked, but here are my $0.02 ;-)<p>You need typescript in your environment to use typescript!<p>The four formats the OP listed can be read by anything from Ada to EXCEL. But typescript can only be ready by a TS build flow.<p>In fact, I think JSON was a bridge too far. A config file shouldn't need a <i>compiler</i>.[1]<p>FOR GENERAL PURPOSE: big no.<p>BUT: If this is purely for TS projects where the tooling already exists, then OK. I'd use it.<p>EDIT [1] I'm referring to the article's early suggestion to run JSON through JSMin to support comments. So transpiling is more apt, not compiling.
Great little writeup ! After mangling YAML, HCL, JSON for years as an ops engineer, I have come to the same realisation. In fact, I have put this into practice in production pipelines by using: jkcfg[1] for the last couple of years. Two data points: 1. Zero developer support contract rate around YAML syntax and templating issues 2. High number of contributions in our private typescript configuration library from developers. Using typescript as an ops frontend has made operations a lot more approachable to folks.<p>Recently I took what learnt in the last 2 years using jkcfg/typescript and taken it to Deno in form of an opinionated port of jkcfg called: dxcfg[2]. Its early days, but I would bet on Deno/typescript for future ops configuration.<p>[1] <a href="https://jkcfg.github.io/#/" rel="nofollow">https://jkcfg.github.io/#/</a>
[2] dxcfg: <a href="https://github.com/dxcfg/dxcfg" rel="nofollow">https://github.com/dxcfg/dxcfg</a>
Good to see people coming to the same conclusions we have had for a while using Clojure. There's an up and coming runtime data validation framework called Malli that I use for these sorts of files.<p>You can get many of the benefits but also run custom validations (dictate how two keys in a map relate to eachother, or force a be of a certain shape instead of just a string).<p>Here's the example from the script: [0]<p>[0] - <a href="https://malli.io/?value=%7B%20%3Alocale%20%22en-US%22%0A%20%20%3Atimezone%20%22America%2FNew_York%22%0A%20%20%3Alog-level%20%22info%22%0A%20%20%3Aenvironment%20%22local%22%7D&schema=%5B%3Amap%20%0A%20%5B%3Alocale%20string%3F%5D%0A%20%5B%3Atimezone%20string%3F%5D%0A%20%5B%3Alog-level%20%5B%3Aenum%20%22trace%22%20%22debug%22%20%22info%22%20%22warn%22%20%22error%22%20%22fatal%22%5D%5D%0A%20%5B%3Aenvironment%20%5B%3Aenum%20%22local%22%20%22dev%22%20%22staging%22%20%22production%22%5D%5D%5D" rel="nofollow">https://malli.io/?value=%7B%20%3Alocale%20%22en-US%22%0A%20%...</a>
I’m not on board with using a language that only has a single implementation and is complex enough that implementing others is difficult.<p>Please use a language designed for configuration, but still sane. There are several if we leave the JSON-inspired family. Starlark, pystachio, Dhall. All are restricted, but allow functions and code reuse. All are simple enough to write a new interpreter for.
Anyone have experiences to share about Dhall (<a href="https://dhall-lang.org" rel="nofollow">https://dhall-lang.org</a>)?<p>On their homepage they call it a "programmable configuration language that you can think of as: JSON + functions + types + imports"
Probably important to mention that at the moment, TypeScript as a configuration format means anyone who writes a configuration blob for you has arbitrary code execution. This is rarely an issue in practice, though.
Dhall seems to gather some praises, and not fall into the pits mentioned here.
<a href="https://news.ycombinator.com/item?id=17523623" rel="nofollow">https://news.ycombinator.com/item?id=17523623</a>
My money is on <a href="https://cuelang.org" rel="nofollow">https://cuelang.org</a> in this space.<p>As I understand it it's essentially the Google Configuration Language (GCL) author responding to Hashicorp Configuration Language (HCL), with language development modeled after Golang. Still in early stages but very promising.
I feel like the AWS CDK is a great example of this working well. Rather than puzzling over what config options are valid, I get autocomplete and compiler errors when I insist on using an incorrect option. You also get stuff like deprecation warnings showing up in your editor.<p>It also becomes trivial to parameterise config so I can setup the same general Cloudfront distribution once and tweak it based on the individual application. It's open to abuse but it's better than interpolating values into Cloudformation templates.
Is evaluation lazy in TypeScript ?<p>For me, one of the most important features of a configuration language is the ability to directly refer to other values of the configuration, and more importantly, in the case of a configuration split in separate modules, to refer to values that could be provided by the other modules.<p>Essentially, this means that the final configuration should be the fixed point of a function, that the user would provide the configuration as a definition of this function (or in the case of multiple modules, as multiple definitions that would be merged using function composition), and that the evaluator would be able to determine the fixed point of this function.<p>I feel like this kind of configuration (used notably in NixOS) provides a lot of what's missing in traditional configuration languages, makes it easier to compose configuration modules, without requiring to write the configuration in a Turing-complete language.
The line between configuration and code is always a little blurry. There are some projects where using a .js file for the "configuration" of another operation is incredibly useful. TS makes even more sense in many of those situations. Lots of configuration files require pre-processing already, like merging shell env vars in with textutil or something like that. So, I wouldn't dismiss this opinion outright.
I think this is kind of a no-brainer, <i>if</i> your project is already based on TypeScript.<p>Not just for configuration, but for things like test fixture data, and even data assets like i18n translations, or basically anything that projects might commonly use JSON for, internally. It's just so much easier to create, edit, manage, and deal with in TypeScript.<p>But it is hard to imagine TypeScript-as-config taking root in projects that don't already use TypeScript.
I've really come to prefer json5 as a config format: <a href="https://json5.org/" rel="nofollow">https://json5.org/</a><p>It's basically Json with comments, trailing commas, and unquoted object keys (and some other minor things).<p>Much nicer than real json as a config format, but still simple and declarative, not requiring an interpreter or being turing-complete.
Really interesting but, sincerely, I would rather use sqlite.<p>I know: It's a binary format.
And you need to add a library to read it.<p><i>BUT</i><p>- Your configuration _has_ data types.<p>- You can have a copy with an old config within the file easily (create table backup_config as select * from actual_config; ).<p>- The file is small.<p>- Encryption is built-in if you need it.<p>- And it's programable
I have used TypeScript for config in a few projects, with node-config[1], and it’s substantially better IME than JSON/YAML/etc. Yeah it’s unconventional to write configs in a general purpose language, and I understand why that would be undesirable. But having configs validated at compile time is great at preventing bugs.<p>I’m not sure I’d recommend node-config (it was chosen by a past team). Its magic undermines the confidence in type safety provided by choosing TypeScript in the first place. But it does give some good baseline conventions one can apply without all the magic.<p>1: <a href="https://github.com/lorenwest/node-config" rel="nofollow">https://github.com/lorenwest/node-config</a>
TypeScript needs to be compiled, right? So what use is a configuration file if I need to run it through the build pipeline?<p>The point of having <i>configuration</i> is to gain the ability to <i>configure</i> software without rebuilding in my mind. Maybe I'm missing something.
What would be the problem with using something like protobufs? To write the configuration, you can use whatever language you want, what matters are the outputs anyway. The outputs are stored by automation in text format so that they can be better inspected. The programs that use such configuration have the advantage of knowing the schema of the configuration and directly parse it avoiding possible typing problems. The nice thing is that you can use the same language to write the programs and the configuration.
I think parsing YAML or JSON into typed structures is the easier way to go. I e.g. do that in Golang using a little form validation and coercion library I've written. The end result is a nested, strongly typed data structure. Here's an example: <a href="https://github.com/iris-connect/eps/blob/master/settings.go" rel="nofollow">https://github.com/iris-connect/eps/blob/master/settings.go</a> (the accompanying form validation configuration: <a href="https://github.com/iris-connect/eps/blob/master/forms/settings.go#L78" rel="nofollow">https://github.com/iris-connect/eps/blob/master/forms/settin...</a>). Hashicorp has some libraries that do similar stuff, I wrote my own though since I need it quite often and wanted to have full control over it. The library is just a few hundred lines of Golang code (<a href="https://github.com/kiprotect/go-helpers/tree/master/forms" rel="nofollow">https://github.com/kiprotect/go-helpers/tree/master/forms</a>). Undocumented as of now as it's nothing I want to explicitly share with the world.<p>In my experience, a lot of the validation needs to be done at runtime anyway as type checking alone won't allow you to e.g. validate if a string is a valid regular expression. Also, I think using TypeScript for configuration requires you to compile & interpret the configuration file in order to check it and obtain the actual configuration values. Not sure if I like that as it requires bundling the entire TypeScript compiler with your program.
TypeScript is limiting for describing schema in my experience. Try requiring an array of certain length, for example.<p>Also, it’s Turing-complete, so you are enabling future developers or users to shoot themselves in the foot and write something that does not halt already at configuration stage.<p>To me the perfect language for configuration seems to be Dhall, but it doesn’t seem to have gained any traction.
Typescript has a lot of punctuation and thus it's not really human-editable. I'd prefer a ini-style format or dockerfile style (with one directive per line of text, clearly identified by a single uppercase word). Moreover, these formats are so easy to parse that you do not even need a library to do so.
You know what we don't need? Yet Another Configuration Format! Also, don't tell me I can't add comments to JSON because I sure can - add it as a field! If a comment is that important then it's important enough to transfer along with the dataset and durably persist.
Personally I wouldn't use Typescript for config. It breaks my #1 dev rule which is KISS. Keep it simple stupid. Simplicity is orders of magnitude more important than other things like DRY or config schema.
I'm curious what folks who agree with this think about setup.py then? There's been a push to move to setup.cfg to specifically avoid the fact that python libraries run arbitrary code on install.
My only real criticism is that I believe it's generally an anti-pattern to have configuration that necessitates DRY. It has essentially the same problems as OOP inheritance. Because configuration isn't and <i>shouldn't</i> be an application in and of itself, avoiding potential issues and misdirection from avoiding DRY in this case seems like the right tradeoff to having to use multi-select to change the config format in your IDE.
I like the idea of the IDE assisting with the schema-correctness of the config (which you get for free with TypeScript coupled with any competent IDE configured to use the typechecker to validate the code).<p>... but as a rule of thumb, if your config language is Turing complete, you're setting yourself up for future pain as complexity of config grows with time and someone makes the bad decision to take advantage of that Turing completeness...
Great idea.
And because you need many constants that often change in such a configuration file you could put that all in another file and include that in the 'real' configuration file. Why not call that, hmm, `config_config.txt`. But as plain text is a bit hard to parse, we could give that file some structure, so that it is like, well, another markup language, just without markup and easier to read and write.
I think typescript as a config format alone may get too complex.<p>But json backed by a typescript interface definition could be a useful middle ground.<p>You're still writing json but you get nice code completion and realtime validation of the config file.
I use TypeScript and like the ecosystem.<p>For broader use, I would like to see native support or an official extension for creating dependent types or specific constraints.<p>Things like number ranges, or the basics from JSON Schema, etc.
I've done a similar thing with Scala in the past - ship the compiler jar and then compile your configuration (which is just an abstract class implementation) as part of the startup process.
Not typed support but I find jsonnet [0] pretty useful when you have tons of configuration files.<p>[0] - <a href="https://jsonnet.org/" rel="nofollow">https://jsonnet.org/</a>
Apple takes a similar approach for swift. Package.swift files run real swift code and export an object that specifies the package’s configuration.<p>In practice I think it works fairly well.
How to add comments in json or TypeScript config files? Commenting is very much needed for any manually written code or config we keep in repositories.
Typescript is perfect for stuff like this because it's so much less verbose than most things out there<p>As a bonus, you might not need validation and schemas, too.