Support an environment variable (such as CHROME_AWS_LAMBDA_ASSUME_HEADLESS) to optionally short circuit the serverless variable checks in Chromium.headless. For example, this could look like:
This would allow users to independently handle weird edge/use cases with minimal changes to their code and/or environments. My own use case is running an app using chrome-aws-lambda in a docker container using the AWS NodeJS Lambda image to locally emulate our production lambda environment (including using the bundled chromium), but overriding the entrypoint to use serverless-offline to mock an AWS API Gateway we have upstream of our Lambda function.
However, it looks like there are a few other edge cases that could also be served by this:
You could also make the argument that the problem here is assuming whether the user wants headless or not based on a potential breadcrumb of a specific runtime environment, rather than letting the user specifically define it. While this might be too much of a breaking change at this point, I'd think this would be less confusing for users:
static get headless() {
if (process.env.CHROME_AWS_LAMBDA_DISABLE_HEADLESS) {
return false;
}
...
}
Users could then explicitly explicitly disable the headless check.
What would you like to have implemented?
Support an environment variable (such as
CHROME_AWS_LAMBDA_ASSUME_HEADLESS) to optionally short circuit theserverlessvariable checks inChromium.headless. For example, this could look like:Why would it be useful?
This would allow users to independently handle weird edge/use cases with minimal changes to their code and/or environments. My own use case is running an app using
chrome-aws-lambdain a docker container using the AWS NodeJS Lambda image to locally emulate our production lambda environment (including using the bundled chromium), but overriding the entrypoint to use serverless-offline to mock an AWS API Gateway we have upstream of our Lambda function.However, it looks like there are a few other edge cases that could also be served by this:
Alternative (Backwards Incompatible) Proposal
You could also make the argument that the problem here is assuming whether the user wants headless or not based on a potential breadcrumb of a specific runtime environment, rather than letting the user specifically define it. While this might be too much of a breaking change at this point, I'd think this would be less confusing for users:
Users could then explicitly explicitly disable the headless check.