Skip to content

--env-file support in NODE_OPTIONS #51147

Description

@afonsojramos

What is the problem this feature will solve?

Sometimes env files are used as config files, therefore it should be allowed to set an --env-file in NODE_OPTIONS, for example in the .npmrc file, so that it applies to all scripts of that specific project.

What is the feature you are proposing to solve the problem?

Allowing for the --env-file flag to be supported in NODE_OPTIONS.

What alternatives have you considered?

No response

Activity

  1. MoLow commented on Dec 13, 2023

    @MoLow
    Member

    Well, that can raise many issues and confusion since you can define NODE_OPTIONS inside the env file

  2. afonsojramos commented on Dec 13, 2023

    @afonsojramos
    Author

    I see, but I see no other solution for project specific .env, right? Do we have a way of knowing where the NODE_OPTIONS are coming from? If so, just disabling it for the .env recursive case might be a way? 🤔

  3. added
    dotenvIssues and PRs related to .env file parsing.
    on Jan 18, 2024
  4. jsumners commented on Mar 28, 2024

    @jsumners
    Contributor

    Well, that can raise many issues and confusion since you can define NODE_OPTIONS inside the env file

    Not really. Command line switches take priority over all other methods of defining the same values. Just ignore any NODE_OPTIONS in the env file when it is being loaded by --env-file. The current state of rejecting the option is frustrating and surprising.

  5. kireerik commented on Apr 22, 2024

    @kireerik

    I think this was working before version 20.12.x (related issue: remy/nodemon#2194).

  6. remy commented on Apr 22, 2024

    @remy

    I think this was working before version 20.12.x (related issue: remy/nodemon#2194).

    Not a related issue. They've opened an issue that is not related to nodemon at all (just to prevent confusion for anyone else)

  7. anonrig commented on May 28, 2024

    @anonrig
    Member

    Closing since technically this is not possible with the current implementation.

  8. jsumners commented on Jun 8, 2024

    @jsumners
    Contributor

    Can you please highlight what makes it "technically impossible"?

  9. anonrig commented on Jun 8, 2024

    @anonrig
    Member

    Can you please highlight what makes it "technically impossible"?

    With the current state it is not possible, I didn't say impossible :-)

    To summarize, if you refactor how we load and initialize node options as well as env file, it is possible. although, i think it will make both implementations more complex with little gain. if you think you can land it, with less unmaintainability, PRs are welcome.

  10. jsumners commented on Jun 10, 2024

    @jsumners
    Contributor

    @anonrig you seem to have direct knowledge of why it is impossible. I am asking you to provide a summary of that knowledge. As a reader of this thread, there is nothing in it that tells me why it would be closed without being solved.

  11. anonrig commented on Jun 10, 2024

    @anonrig
    Member

    @anonrig you seem to have direct knowledge of why it is impossible. I am asking you to provide a summary of that knowledge. As a reader of this thread, there is nothing in it that tells me why it would be closed without being solved.

    You're right. I'll write an in depth analysis of my thoughts when I have the time. Meanwhile, I'm reopening the issue.

  12. moved this from Awaiting Triage to Triaged in Node.js feature requestson Jun 27, 2024
  13. dartess commented on Nov 28, 2024

    @dartess

    This seems to be the closest I have found to my task. Perhaps someone here can give me a hint?

    I want to use --env-file (--env-file-if-exists tbh) together with running npm package. Moreover, I want to get this cross-platform and without using third-party packages.

    I think I got closer to it with npx and here I am:

    npx --node-options='--env-file-if-exists=.env' playwright test
    
    node: --env-file-if-exists= is not allowed in NODE_OPTIONS
    

    Perhaps there is another way?

  14. github-actions commented on May 28, 2025

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
    For more information on how the project manages feature requests, please consult the feature request management document.

  15. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on May 28, 2025
  16. songkeys commented on Oct 25, 2025

    @songkeys

    @anonrig you seem to have direct knowledge of why it is impossible. I am asking you to provide a summary of that knowledge. As a reader of this thread, there is nothing in it that tells me why it would be closed without being solved.

    You're right. I'll write an in depth analysis of my thoughts when I have the time. Meanwhile, I'm reopening the issue.

    any updates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dotenvIssues and PRs related to .env file parsing.feature requestIssues requesting new Node.js features.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions