Useful or not, from you.
lighthouse-ci thoughts on configuration

existing work

typescript doesn't have named a CLI option for setting the config file, but their config is named tsconfig.json


eslint uses --config, although it does have --no-eslintrc. allowed config names are many: image


babel doesn't have any way to set a config from the CLI, but it does have --no-babelrc. allowed config names are: image

thoughts

sorted by order of how strongly i feel

--rc-file should be --config

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.

remove ability to customize config path

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 .lhciconfig.json (or .lhcirc.json)

allow .js

right now just .json is allowed. this makes sense for now, and we should definitely defer this. just calling it out now

configure via package.json

ditto above section

nit on rc

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.js and 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 .lhcirc.js and .lhciconfig.json.

* 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.

That's a useful answer
Without any help

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 .lighthouserc I meant as opposed to other basename options like lhci.config, .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).

Sure, though ci:client and ci:server?

that's dope.