Save us from Config File Hell

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming again hot. Here is Wes Barracuda Boss and Scott

CSD.

Welcome to Syntax.

In today's Monday hasty treat, We're gonna be talking about config files, how much we love them, how many of them there are. I mean, we must love them because we have tons and tons of them. So My name is Scott Talinski. I'm a developer from Denver. With me as always is Wes Bos. Wes, what's up? How's your config files looking? How's your the root of your project? Is it it. Full of full of files. Root of my project is is looking good. I I this sort of stumbled I stumbled upon 1, the other day that had Thirty config files in it. And, like, I just screenshotted it, and I was like, I think that's a record for me.

Response to it was really interesting. There's a lot of people that were like modern web development, LOL, garbage. And even though half of them weren't related to front end development at all.

And the other thing is, like, kind of need them. I don't like it either. It's so obnoxious that Like, every root of your Git repo is full of a 1000000 different files and whatnot. So we're here to sort of help you Save yourself from config file hell and figure out how do we make this manageable both in local Dev as well as, like, Some ideas about like, I think Node has kinda failed this year, so we'll get into that as well. Yeah. Totally. How are you doing? You just got back from skiing, I heard. Yeah. Yeah. I was telling you, I got the classic,

ski tan where my the tip of my nose is bright red, like, the lower half of my jaw is all sunburned because I didn't wear sunscreen Before, for some reason, I typically do, but, I took Landon out there, and we we drove out, left it early, early, early, And then just sat in traffic for, like, 3 hours on the way home. And, like, when you have a a 5 year old in the car for that long, especially if they just got done skiing, it was like, How about you just take a a nap as long as possible, and then hopefully you won't have to go pee at some point in this drive because I'm not gonna get out of my way here. Oh, no. And luckily, it was all good. Yeah. That's good. Well, how was your electric car up to the mountains? Dude, let me tell you. So the 1st time that I've done a ski trip in my car by myself with Landon. I mean, we've done I've driven into the mountains where we stayed there and charged it. So I wasn't quite sure what to expect. It. We went to maybe one of the closer mountains to us and, you know, hour and a half drive without traffic, hour 15, something like that. And On the way there, the car got all the way down to 50%, 45%, and I was thinking, okay. That seems pretty fine, but it's mostly uphill. Right? You're gaining a ton of elevation. You're gaining, like, 8,000 feet of elevation.

So on the way home, I was surprised to see that an hour into the drive, I had gained 3% on my battery Because of all the the the amount that the engine's having to limit you from the amount of speed you want to gain from going downhill, I I looked looked at I left, and I had, it. Like, 98 miles till empty or something when we left the house. And then when I you know, an hour later, I look at it. It's like, you are now a 103 miles to To empty. It's like, this is awesome. I I, I got home, and I I still had, like, 80 miles till empty. So it's like the entire drive

Home barely took any of the battery just because of region. It was pretty incredible, actually. Wow. That's really cool. So, like, you can almost Spend your whole battery going up the mountain and just hope.

Yeah, right.

Yeah. Got to go. That's good. We have a massive He'll here, too. Like, Hamilton is split down the mountain, which is downtown and up the mountain. And whenever we go down it, I'm always thinking, like, I wonder Wonder how much, I always tell my wife. She's like, don't speed down the mountain. And I I used to never hit my brakes going down because I was like, this is free. Like, I'm not spending anything to go. And then I got a ticket. I got a ticket in the phone flying down the

yeah. On that same regard, it. There's some there's some spots in the drive into the Rocky Mountains west that are like a couple of minutes of just it. Really steep downwards, and they'll they'll have pull offs for trucks whose brakes go out and stuff like that. And it's so intense if you don't know what you're doing because you can it. You can go from 50 miles per hour to a 100 miles per hour without even thinking about it. So you gotta, like, ride ride the breaker. That's why driving a manual is really good because you could just keep it in a Lower gear and have the engine help you a bit, but okay. Config files. Sorry.

Alright. So we need config files. Config files are use for configuring your dev tooling, ESLint, Prettier Versus Code, your build tooling, TypeScript, Babble, SWC, Your infrastructure.

This is this is one thing that I I really like is that a lot of times the config files are Your infrastructure, meaning that you're describing what you're hosting and integrations and domain names. You're describing what all that stuff is as code.

And rather than you having to log in to something and remember what buttons to press, you just make a config file. And As much as people don't like config files, I'd much rather have the entire AWS infrastructure, configured in a single file rather than having to remember which buttons to press and whatnot, because there's no way you're going to be able to set that up again Perfectly a second time.

What other kinds? Get those ignore files, npm ignore, get ignore repo details contributing,

etcetera, etcetera. There's a million of them. Yeah. All these things could be just filling the root of your your project, which is funny because you think the root of your project isn't even the source, But it tells so much about the application. Right? It tells so much. Like you said, being able to, reproduce the same Config across environments is really where these things shine and help you, and they also just make life easier. I think the my my big critique with config files in general Is how many different formats we have. Right? I have a config dot JSON for, Cypress. I have a config dot JS for post CSS.

I have a config dotjs for Svelte and Vite, a JSON config for TS, NPMRC.

Is this just kind of its own thing? Right? It's, just what what what even you know those files that are like an ENV file or a NPMRC? Is that a specific format That you know where it's just like key value pairs. Is there a name for that?

That's a good question because you think about, like, the prettier RC, And that is just JSON. But then you think about what else is there like a bashrc, and that is bash. So I I think, like, what a specific RC file is is not a specific type. So so it's usually the, like, simple, like, key value pair. I think that's just, like, bash

syntax or key value syntax. I'm not sure exactly what it is. I didn't know if it had a name, but, you know, that that to me is one of the bigger Key points when you think about config files. Right? It's just everybody kind of picks their own format and does it the way they want to do it. Yeah. It's really frustrating to have to go Between them.

I love I think my favorite is probably just straight up JavaScript config files because sometimes you can Actually write JavaScript in them.

A lot of places don't want you to do that because your config file should be static and not computed.

But it's kind of nice to be able to like, I have a Vite config file. And when I run my Vite Server. I automatically open up for specifically for my hot tips. I automatically open up the last edited HTML file in my Vite server.

And it's so handy because I've got 200 different index HTML folders, all kinds of stuff. And rather than having to find the one that I'm working on at the moment, it just automatically opens it up and says, oh, you changed this one last. Open it up. I just wrote, like, a little bit of code that looked at the files has been inserted by,

last can you share that, by the way? Just throw that in the show notes or something. I I'll have something that I can share too. We can do a little swap. I have something neat in my feed config using JavaScript. I use the define property, And I define a global variable named version, and that version is equal to a JSON stringify process dotenv npm package version. So it's grabbing the package version and writing it to a variable named version that I can then use within All sorts of things, right, whether that's Sentry for error tracking. Right?

I throw that in there, and then Sentry always knows what version I have as long as it's up to date and package dot JSON. Super handy. Oh, that's great. I I do something similar like that in the boss monster, and I just pull pull that data from the package JSON. But Doing it at a Vite level is super handy. I just posted the link in the show notes for the Vite one as well. It's probably not all that Helpful for people that are running, like, React apps or whatever. But if you have, like, a folder where you're always fussing and that's your folder for doing demos and whatnot, it's really handy. But also, you know, just the just like what you're talking about, have being able to write JavaScript in these things, you know, doesn't have to be complex to be useful. Like, these are just nice little niceties.

Exactly.

Other things we have there in YAML, TOML, a whole bunch of different things out there. And they can also go in your package .json as well.

I I like putting them in package JSON because it's just one less file to do, But often I find myself being like, freaking I hate writing JSON as well. Like, you have to double quote it.

They can't do comments.

Thankfully, a lot of the config files that are in JSON are JSON five, Which means that you can have a trailing comma. You can put comments in there. You can do all kinds of stuff like that, which is nice. So for very simple stuff, I'll throw it in my package JSON. Otherwise, I have to go ahead and create a new file for it. I almost never put it in package dot JSON, even though I think that that would be the most ideal scenario.

Because I personally would love to scoop up all of my I would love to scoop up all of my c s configs and put them into package.json, which is kind of like your apps config in the 1st place.

But like you said, no comments, No JavaScript in there.

The no comments thing is that it's kind of a big deal. Again, the for the format just kind of stinks in general compared to what you get elsewhere with, You said JSON 5 or, JavaScript or even, you know, YAML. Yeah. Totally.

So I I feel like I'll say this here. I feel like Node or n and or NPM has has kinda failed us here in that.

Like, people were talking like, we need a standard for config files, and config files need you need to be able to define a config. You need to be able to define them in different formats. You want to do it in import syntax. You want to do it in common JS. You want to do it in typescript.

You need to be able to extend configs. Like, in ESLint, you need to be able to, like, take a base and then extend off of that. You need to be able to, like, deep merge configs. If you want to do that type of thing, you want to be able to publish your config.

And wouldn't it be nice because 90% of the configs that are in my folder are NPM or tooling related that is in NPM? Wouldn't it be nice if they stepped up and said, like, here's a standard we developed this amazing config? Apparently, Python has something similar to this, Like, wouldn't it be nice if they did that, and then there's a standard type of config that we can go forward?

Yeah. And, actually, you know, it's funny because when we When we talked about this or when when you first mentioned this as an idea or you were on Twitter, I I remembered a A Twitter thread where where Kent c Dodds was talking about this last year, and I actually just googled Kent c Dodds config folder and the Twitter thread, and it was really pretty interesting because, there's a lot of a lot of comments in here about, pros and cons and stuff that I didn't necessarily had thought of, when thinking about this, but there's a lot of, like, educated educated discussion around the idea of a config folder. So it. It might be interesting to paw through if if you're the type of person who's interested in this. Totally. But I I agree. Yeah. And and then there could be a situation where you have that whole xkcd comment Their comic thing about a standard and,

you know, how old new standard. Yeah. And people are like, oh, well, I don't I don't like that standard or, like, There's so many edge cases. Like, you need some config based on your environment, but then other configs are across all the environments, you know, and then you have to People and then people will build an abstraction on top of it that are based on file names. And I don't know the answer to it. And that's probably why no one has really tackled it just yet, but there is so there is one thing called cosmic config, and this is a package for tool authors To load in configs. And what it will do is, your the people who are using your configs can put it in. You can put it in your Yeah. It's JSON. You can make a JSON or a YAML RC file.

I guess that's what that other one is. It's probably YAML, which is when it's not JSON, it's YAML.

You can also and this is the big one is put them inside a config directory. And That's probably the big one here is that a lot of these tools allow and support you putting those config files In a dot config folder and putting those and that just cleans up the root of your your repo a lot. It makes things a little bit overwhelming because, I don't know. Sometimes I just do a quick scan of a repo. I'm like, okay, where's the code to do this? And then you're just like, oh, my goodness. There's, like, 40 folders in there, and you don't even know where to look. And actually, I was here. Audience, tell us if you think this would be an interesting show is Like, wouldn't it be cool if we wrote a script to grab 8,000 repos and then saw what the most common directories were? And then we go through and Explain what those directories are. Like, what's a lib folder? Why what's a source folder? Mhmm. You know? Yeah. Totally. The cosmic config folder, the dot config is pretty Well supported. TypeScript uses it. Prettier uses it. Jest, Ioslin, Babble.

That is really nice. Vite, Webpack don't use it. However, a lot of these tools will allow you to pass in the location of your config file as, like, an argument or something like that when you are running it. I'm not a huge fan of that because I do like that it just picks it up without having to have a bunch of stuff in your, your scripts.

But you can I think you could probably get pretty far, maybe 90, 95%, putting it all in the config folder and having everything work? It's just one of those things where once it's working, it's hard to

move those things around. So just to confirm, just Just plain English wise, if one of these things that do support Cosmic Config, TypeScript, Prettier, Jest, ESLint Babel Means that out of the box, you can throw them into a config folder without having any worries. And and to be clear, that is a dot config folder. Right? Yeah. Dotconfigforward/tsconfigforward/prettierrcforward/eslintrc, All those good things. You can just toss that tsconfig in a dot config folder right now. I didn't know that TypeScript allowed it. Yeah. Yeah. And it will find it. That's interesting to me because it it seems like Somebody's gotta bite the bullet and just start putting stuff in the config folder and then Yeah.

You know, I I like it because, a lot of, Like desktop tools will also allow it for the root. You know, like, if you go to Tilda in your machine and you've got 400 dot files, you can almost Always put those in a .config file folder as well. And that really cleans up your local machines for a directory.

Yeah. You're right. What else do we have here? So this is something that just was released in Versus code, like, a week or two ago, and it's this new thing called, file nesting where if you go to it's been in for a bit. I'm sorry. Is it really? Yeah. Because I've been using it for over a year. So Oh, man. I must have. I totally miss this then. Okay. So what it does is it allows you in your Versus code to specify file types with another file.

And one common use for this is you can take all your configs and just put it under your package. JSON.

And there is a nested config.

You have to do it all yourself. Like, there's no good default, but Ant Foo has put out a really good bunch of patterns that will take all of your common configs that most of us JavaScript developers are writing and stick them under your package. JSON.

And that to me is super handy because at least you can just

Fold those up in an arrow, and then you don't see as much in in your sidebar. Yeah. Yeah. And this pattern is Awesome. Because when I first saw this, I was like, okay. I already have a bunch of these myself, but then, of course, these are just so much Beyond that, where it's like scooping up the ones that are connected to what it's specifically connected to, it cleans us all up. I I've been using this technique for a little bit, And, I'm a big fan of it. I think it it hides things nicely, but at the same time, you know, it's not hiding them To a point where you can't find them, and typically you're looking for them with a command p anyways. So Yeah. Yeah. I I really like, especially in your editor experience, just kind of shoveling them all underneath the rug. It's really handy if you use a naming convention for components.

Let's say you have a search component and then you have search done. You have your tests that are associated with that. And then you also have, like, a styles component. And then Maybe you have another one for, like, the actual markup of it. Or then maybe you also have, like, some hooks that go with it. Or maybe you have A data fetcher that goes along with that specific route. And before you know it, you have 3, 4, 5 different files that are all kind of named the same thing, you can stick those in a folder, but it's nice to just collapse them all underneath the, like, the main component.

And And then because what I do is I just open the main component. And if I want to find the styles or the logic to fetch data or the tests, I just click through. You hit the command click in your Versus Code. I don't go into the side bar to find that file. I just, oh, it's importing these styles Man, click and it opens up the folder or the file that's associated with it.

So I think I need to check that out maybe a little bit more in some of my folders. So that is config file 101 saving you. There's definitely manageable.

I think that either NPM and or GitHub need to step up next and find a way to make these types of files not so overwhelming. When you're looking at a repo, there's a couple of things that I think GitHub should do that. And all of the, like, Dependabot stuff, it really muddies up all the pull requests. It muddies up all the Git history, all that kinds of sometimes when I'm searching for something in, like, a git repo, half the searches are just depend a bot Pull request, and I'm just like, I just need to be able to they're important.

Same with configs. They're important, but I need to filter them out,

it, when I'm trying to look for something. And it's important to know. I mean, it's an important note to say, like, the the more things get muddied, the more things there are, CS the harder it is to find but also the easier it is to miss things the easier it is if there's too much noise you miss the actual thing you're looking for. So Yeah. Exactly. Config, it's a necessary evil at this point, but I don't I don't see that changing anytime soon. And I don't think the correct answer like you mentioned at at the top of the show, the correct answer isn't LOL, modern front end development or modern development or whatever. That's not the answer. That doesn't Help anything. It's not gonna go away. As long as we have tooling, we're going to need config, tooling for releasing products, tooling for helping us develop things.

That's just how it is. So, embrace the config.

Maybe embrace this, The cosmic config, I I think that's actually really pretty neat. What I would like to do, you know, Wes, that this episode's got me inspired to look at my config files and and at least standardize on A format, if that's possible.

Because just looking at my repo, I don't have a ton of configs. I have a Cypress. I have a post CSS. I have a Svelte, Avit, an ESLint and a Styleint.

I guess an NPMRC and a git ignore, But, like, half of them are different formats.

So, like, maybe just standardize and laying on one specific type of File format even inside of your repo would make things a little less rough. If it's possible, that's good. I I'm curious now how many I have. So I have let me rattle through mine. ESLint ignore,

git ignore, npmrc, caddy file, which is config for the local server, env sample. That's a sample of the environmental variables that should be set. Obviously, the the actual environmental variable should not go into your git repo.

Package JSON, PMPM lock, PMPM workspace, readme. Oh, that that's one we didn't even talk about as well is that there's So many read me files. What do you have? There's, contributing the MD, read me, code of conduct, authors, license, all of that stuff.

Oh, my gosh.

Pull request template.

Some of those a lot of those can go into a GitHub folder, I believe dot GitHub folder and then GitHub will respect that. So that's nice. And also a lot of those don't need to be there for

a lot of projects. Right. Where if you're not publishing packages or Yeah. I had I had of a bunch of products,

like, just tiny little repos.

And I had a bunch of people like, PR contributing and and code of conduct and all that stuff. And I was like, that's Not necessary. Like, if it becomes an issue, yeah, but I feel like it's a lot to just add all these files to it and then it just becomes Oh, I I don't know. I maybe I a bit too anxious on all these files, but it really bothers me. Oh, it bothers me too. Yeah. No. Definitely. And that's why I think this cosmic config thing is so appealing. I had no idea that so many things supported this already. Yeah. The one thing I cannot find is, Like, where is there a list of tools that support cosmic config? So what I ended up doing is I went to, This is actually a little feature I didn't know a whole lot about.

If you go to a Git repo and you go to the Insights tab and you click on the dependency graph, It will give you a list of packages that depend on this package, and this is way better than NPM's What does NPM have? They have a dependence tab. It's just a yes, a dump of a1000000. And there's no way to, like, sort by most popular or whatever.

So I just looked at that and I scrolled through it really quickly. And and I was like, oh, TypeScript's in here. Oh,

all these Babble's in here. I've literally never looked at the Insights tab ever.

It's awesome if you go to Insights dependency graph, And then it will tell you it'll show you which projects. And this makes me hopeful that, like, NPM itself will just be folded into GitHub at some point.

Mhmm. Alright. I think that's it for today. Thanks, everybody, for tuning in. We will catch you on Wednesday. Peace.

Head on over to syntax .fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.