Support for Node.js Built-in .env File

[x80486]

🤔 What's the problem you're trying to solve?

Currently, Cucumber.js primarily relies on environment variables set externally for configuration. With Node.js introducing support for the .env file format, it would be beneficial to allow Cucumber.js to read environment variables from the .env file as an additional or alternative source of configuration.

Why This Is Important:

1. Consistency with Node.js Ecosystem: Given that Node.js supports .env files, adding support for them in Cucumber.js would align with best practices and the Node.js ecosystem's standards.

2. Enhanced Integration: Cucumber.js could offer seamless integration with Node.js projects by providing built-in support for .env files, fostering a more cohesive testing experience.

✨ What's your proposed solution?

Since this is usually used when developing locally, I think a configuration key might be useful to enable this at the profile level, but there is also simplicity on just enabling this globally or not, in the same way Node.js currently does.

const common = {
  failFast: true,
  parallel: 1,
  require: ["step-definitions/**/*.ts", "support/**/*.ts"],
  requireModule: ["ts-node/register", "tsconfig-paths/register"],
  retry: 1,
};

module.exports = {
  ci: {
    ...common,
    format: [
      "progress"
    ]
  },
  default: {
    ...common,
    env_file: ".env" // <- This is what I meant by a "configuration key"
    format: [
      "progress-bar"
    ]
  }
};

⛏ Have you considered any alternatives or workarounds?

I'm currently using some of the libraries that provide similar behavior.

📚 Any additional context?

N/A

[davidjgoss]

Thanks for raising @x80486, I hadn't heard about the built-in .env support yet (https://nodejs.org/en/blog/release/v20.6.0#built-in-env-file-support for reference).

However, to have an envFile or similar configuration key in Cucumber , we'd be replicating this functionality rather than leaning into what Node.js now provides. As I understand it, you could do this today without any changes:

NODE_OPTIONS="--env-file=.env" npx cucumber-js

(I think this could be unergonomic in practise for users, because Cucumber only allows its own configuration to be set in files or the CLI. If we were to add support for configuration via environment variables, you could control everything - Cucumber stuff and non-Cucumber stuff - via a .env file. I've raised #2347 accordingly.)

[x80486]

I agree with the perspective that we should aim to reuse existing tools and mechanisms when possible to keep things simple and avoid redundancy. The primary goal should be to enhance Cucumber's compatibility with Node.js without adding unnecessary complexity.

Additional dependencies is also a valid concern. For instance, if users had to rely on external dependencies or complex configurations to use .env files, it could create friction and increase the learning curve for new users. What I specifically refer is to the usage of NODE_OPTIONS="--env-file=.env" npx cucumber-js. Granted this could be used, but usually we encode actions within npm scripts, and to be able to use environment variables, cross-env (or any other similar) should be used. Moreover, I guess NODE_OPTIONS is one of those variables you can even define inside .env files now — pretty tricky, at least for me because I don't fully understand all the moving parts 😬

Another suggestion that comes to my minf is to have a CLI configuration setting: --use-env-file — or similar. It would give users the flexibility to activate or deactivate the feature as needed, without introducing unnecessary complexity into the project's core configuration. Problem is that I'm not entirely sure how Cucumber can build a pass-through to activate a Node's feature, and the order in the lifecycle of the applcation.

[davidjgoss]

Problem is that I'm not entirely sure how Cucumber can build a pass-through to activate a Node's feature, and the order in the lifecycle of the application.

Yep exactly. I think we'll wait a bit and see where Node.js goes with the dotenv file support. It may be that, much like module loaders, future releases make it less friction-y to use and add the ability to activate it in-process, at which point it might start to make sense for Cucumber to lean into it.

[BeppeTW]

 "test": "export $(cat .env | xargs) && npx cucumber-js"

Not a beautiful solution, but it works...