Open x80486 opened 9 months ago
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 https://github.com/cucumber/cucumber-js/issues/2347 accordingly.)
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 :grimacing:
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.
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.
"test": "export $(cat .env | xargs) && npx cucumber-js"
Not a beautiful solution, but it works...
š¤ 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:
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.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.
ā Have you considered any alternatives or workarounds?
I'm currently using some of the libraries that provide similar behavior.
š Any additional context?
N/A