Ask questionsthoughts on configuration
typescript doesn't have named a CLI option for setting the config file, but their config is named
--config, although it does have
--no-eslintrc. allowed config names are many:
babel doesn't have any way to set a config from the CLI, but it does have
--no-babelrc. allowed config names are:
sorted by order of how strongly i feel
It seems to just be a config, so shouldn't it be called that? I didn't find any tools that name their config option like this.
I think babel does this to simplify compiling across project boundaries. That doesn't apply much here, but I wonder if there is any purpose to have multiple config files for LHCI? We could consider removing any option to configure, and add it in later if demand is there. If we do this, I'd recommend the file be called
right now just
.json is allowed. this makes sense for now, and we should definitely defer this. just calling it out now
ditto above section
rc stands for run commands*, and so I'd think files called
rc should be something you must run (shell, node, etc). I wouldn't consider a json file to be a executable file. I see that eslint uses
eslintrc.json (ditto for babel), so that doesn't jive with my understanding, and it's a popular enough tool that I concede any argument for using
* at least, it did initially. it has morphed into
run configuration over time, which of course kills my argument. but I did some light research on this and can't find a satisfactory source on this definition. from what I currently know, I consider this morph to be a mistake.
Answer questions paulirish
I DO NOT LIKE using .lighthouserc as there's no syntax highlighting or any automatic linting from your editor without configuration or an extension.
When I proposed
.lighthousercI meant as opposed to other basename options like
.lighthouserc.*or whatever is totally fine and preferred IMO. Please don't let this misstatement on my part let y'all throw out the baby with the bath water.
hahaha you got ALL CAPS REACTION PAUL. Heh I didn't really feel that strongly but I did want to indicate something stronger than "i don't like" and my overworked and addled brain overcompensated. 😳 🤐
ah so perhaps what you were going for was using "rc" in the name to help to differentiate from lighthouse's custom config and plugin config, etc.?
that makes sense. :)
and since we're talking about defaults & configurability... i'll drop in a relevant perspective from Jason this morning:
I'm not sure I understand the point of that tweet in this conversation. As we've already established, autodetect and using a sane default is great, planned, on the backlog, and probably fixed by 4pm today, so there's no point debating that. Is this then trying to say that offering the option of placing a config file somewhere other than your root directory is somehow user-hostile?
eh nah. we're just discussing configs and defaults a lot and i wanted to add in this POV. Basically that well-chosen defaults are extremely powerful. A la parcel vs webpack. Anyway, i'm not suggesting any action in particular here.
we'll keep the "config path flag" for now. seems fine.
going along with this... ciclient and ciserver namespacing props? These names suck, but I like the idea that they're configured separately as they're run separately (99% of the time).