Headless mode is determined by enviroment variable directly

[markusmeyer]

Commit 4771eaf introduces the possibility to control whether the browser get started in headless mode. This is done by directly checking the environment variable "headless". Running the package in the context of a application which already got this variable passed leads to problems. As further context, chrome-launcher is used by webdriver.io / devtools (https://github.com/webdriverio/webdriverio/tree/08d359b344edc02da2dd79b73865591fa7fcb36e/packages/devtools) to start up Chrome.
I would like to control from the outside if Chrome is started headless or not independently of the env variable.
I'm not too familiar with the package, but starting Chrome headless or not can be controlled from the outside by specifying "headless" as command line option, so there should be no need to access an env variable.
PR #275

[paulirish]

But...

You don't want browsers launched in this context to be headless, and yet you have an HEADLESS env variable with a truthy value.. 🤷‍♂️

Can I ask what the purpose of that env variable is then?

---

Implementation-wise... clearly we could use CHROME_HEADLESS (or CHROME_LAUNCHER_HEADLESS) instead... but... it's just.. This seems like a weird edge case I'm not inclined to support.. 😕

[connorjclark]

@markusmeyer you can try export -n HEADLESS in whatever bash script you use to run your stuff to unset an env variable

[markus-meyer-wsa]

Well, to be more specific, the problem is due to our choice of the env variable to be either "true" or "false", which all evaluates to true for chrome-starter.

Of course, the problem can also be worked around. A would be to rename the env variable. What's not possible though is to unset the variable before calling the library, because it's not a script but a typescript app (which runs the tests) that receives the env variables and in the same process the lib will be called.

But my point is that I wouldn't expect a library to directly evaluate env variables and change behavior accordingly, but rather the calling process being in total control of what the library does. Being able to control headless start by both env variable and API is confusing. So if you keep the env variable, it should be documented well (and also the fact that it overrides the API arguments should be made clear).

Another reason that the app should have control is that it could also decide that it's better not not start the browser headless and call the API likewise. Directly being able to mess with the library behaviour from outside sounds like a violation of layered architecture principles by skipping a layer.

So the application is forced to not use the "headless" env variable in the end not to interfere with the library.

If the env variable should be kept, I would suggest to make this automatic "forwarding" of env variables into the library optional and explicit with something like a flag "useEnvironmentVariables".

Just out of curiosity, can you tell me the use case of the env variable?