This is the most common complaint I see for switching interactive shells to fish/nushell, but it's not a problem in practice. You don't ever uninstall bash, so if you've got a command to paste:
Can confirm; my team spent the past 9 months upgrading an application JDK 8 -> 17, and there were breaking changes even after we got it compiling + running
I would highly recommend the ts-pattern [1] library if you find yourself wanting exhaustive switch statements! The syntax is a bit noiser than case statements in simple cases, but I find it less awkward for exhaustive pattern matching and much harder to shoot yourself in the foot with. Once you get familiar with it, it can trim down a /lot/ of more complicated logic too.
It also makes match expressions an expression rather than a statement, so it can replace awkward terenaries. And it has no transitive dependencies!
> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.
Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read.
I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them.
I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'.
The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX.
> Side effects in constructors
Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.
I came across https://kdl.dev recently, and it has become my favored yaml-replacement when normal code doesn't work.
The data model is closer to XML than JSON, though, so unfortunately it's not a drop-in replacement for yaml.
Small sample:
package {
name my-pkg
version "1.2.3"
dependencies {
// Nodes can have standalone values as well as // key/value pairs.
lodash "^3.2.1" optional=#true alias=underscore
}
}
Tada!