3 ms·

TypeScript needs to be compiled, right? So what use is a configuration file if I need to run it through the build pipeline? The point of having configuration i

by progre 5y ago

TypeScript needs to be compiled, right? So what use is a configuration file if I need to run it through the build pipeline? The point of having configuration is to gain the ability to configure software without rebuilding in my mind. Maybe I'm missing something.

klodolph 5y ago
The fact that it is compiled does not mean you need to run it through an additional step in your build process. In practice, it would just mean that you include TypeScript in your package, which can either be used as an executable or as a library. It can be completely transparent to the user. You can even get by without including TypeScript, if you are willing to just strip out the type information (there are various libraries that do this).
nverno 5y ago
> To use this approach today requires that your project also be written in Typescript. It also means you’ll need to forgo a separate flat-file for your configuration. You're right, the summary presents this configuration as a stop-gap, a possible pre-cursor to a better, future JSON.
dragonwriter 5y ago
> TypeScript needs to be compiled, right? Yes. > So what use is a configuration file if I need to run it through the build pipeline? Compilation doesn't necessarily happen in a “build pipeline”; typescript is available as a library. > The point of having configuration is to gain the ability to configure software without rebuilding in my mind. There are many different purposes of configuration, and they are sometimes in tension, which is why there are so many configuration formats (spanning from limited languages like TOML through general purpose programming languages, whether interpreted or compiled) with an ebb and flow as to which approaches are more and less popular over time.
handrous 5y ago
I think we got here because everyone's mixed up describing a state with describing the process to describe a state. Or, configuration versus scripts that apply configuration. Most of the popularly config-as-code systems mix the two up, including Ansible, my favorite one. You end up with "config files" that are, all at once in the same file: 1) configuration, 2) templates for configuration, and 3) programs that modify config when they're run. I think the whole approach is just fundamentally misguided. Each of these systems should probably use 2-3 different languages & formats, not just one. And especially not YAML. Ugh. So you're right, config files should not be code. Unfortunately, much of "modern" config management involves writing programs in config file formats, which is also extremely bad in a whole different way.

by progre 5y ago

klodolph 5y ago

The fact that it is compiled does not mean you need to run it through an additional step in your build process. In practice, it would just mean that you include TypeScript in your package, which can either be used as an executable or as a library. It can be completely transparent to the user. You can even get by without including TypeScript, if you are willing to just strip out the type information (there are various libraries that do this).

nverno 5y ago

> To use this approach today requires that your project also be written in Typescript. It also means you’ll need to forgo a separate flat-file for your configuration. You're right, the summary presents this configuration as a stop-gap, a possible pre-cursor to a better, future JSON.

dragonwriter 5y ago

> TypeScript needs to be compiled, right? Yes. > So what use is a configuration file if I need to run it through the build pipeline? Compilation doesn't necessarily happen in a “build pipeline”; typescript is available as a library. > The point of having configuration is to gain the ability to configure software without rebuilding in my mind. There are many different purposes of configuration, and they are sometimes in tension, which is why there are so many configuration formats (spanning from limited languages like TOML through general purpose programming languages, whether interpreted or compiled) with an ebb and flow as to which approaches are more and less popular over time.

handrous 5y ago

I think we got here because everyone's mixed up describing a state with describing the process to describe a state. Or, configuration versus scripts that apply configuration. Most of the popularly config-as-code systems mix the two up, including Ansible, my favorite one. You end up with "config files" that are, all at once in the same file: 1) configuration, 2) templates for configuration, and 3) programs that modify config when they're run. I think the whole approach is just fundamentally misguided. Each of these systems should probably use 2-3 different languages & formats, not just one. And especially not YAML. Ugh. So you're right, config files should not be code. Unfortunately, much of "modern" config management involves writing programs in config file formats, which is also extremely bad in a whole different way.