Advertisements or whatever for dotenvx should go to stderr not stdout

[ericwooley]

Hi,

While I admit I'm not a huge fan of these advertisements being in the lib, I do get what your going for. However, out putting into stdout breaks piping and things, the proper place really should be stderr.

Because it's in standard out, I have to go back and add quiet to all the places where it's used that pipes to other scripts and things. Stderr is generally where warnings etc... are, and isn't typically used for structured data piping.

Cheers and good luck with dotenvx

[motdotla]

Really strong point @ericwooley. I will consider this.

[motdotla]

The downside is that stderr then breaks tests.

[darktohka]

stderr breaking tests is expected, I would recommend the default destination for these advertisements and "hints" to go to /dev/null by default, and allow the user to configure it to go to stderr otherwise.

[douira]

Printing advertisements in the first place is bad behavior, and printing them to stderr is even worse. I'm migrating to varlock, which seems to do the same thing as dotenv but better and I don't have to be afraid that it's going to just randomly start breaking my software by printing ads in the future. Alternatively, NodeJS also now natively supports loading env files. For simple cases where I just want to load a .env file I've written 20 lines of code that also just do the job.

[motdotla]

Yes — Node’s native support is an additional reason I’ve shifted my focus to dotenvx. Since dotenv is now built into Node, I felt it was the right time to let the world know about dotenvx through dotenv. Thanks for using dotenv while you did, and all the best.

[christian-kreuzberger-dtx]

"[dotenv@17.2.2] injecting env (0) from .env -- tip: 🔐 prevent building .env in docker: https://dotenvx.com/prebuild\n"

This is causing additional issues with protocols/components that read from STDIN/STDOUT, as shown here with Claude Desktop and our MCP Server: dynatrace-oss/dynatrace-mcp#166

Any chance we can do something about this?

[rubenbaraut]

same error in Postman MCP server

[Postman MCP Server (Full)] [error] Invalid JSON-RPC message: [dotenv@17.2.2] injecting env (0) from .env -- tip: ⚙️  override existing env vars with { override: true }
 {
  metadata: {
    context: 'connection',
    stack: 'Error: Invalid JSON-RPC message: [dotenv@17.2.2] injecting env (0) from .env -- tip: ⚙️  override existing env vars with { override: true }\n' +
      '\n' +
      '    at MessagePortMain.<anonymous> (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.js:223:2810)\n' +
      '    at MessagePortMain.emit (node:events:519:28)\n' +
      '    at MessagePortMain._internalPort.emit (node:electron/js2c/browser_init:2:111029)'
  }
}

[christian-kreuzberger-dtx]

For reference, this is how I fixed it: I've set quiet: true and I'm handling the response from config myself:
https://github.com/dynatrace-oss/dynatrace-mcp/pull/168/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80

[vm-orbit]

Ad in OSS tool output does not look right. At least it makes me avoid dotenvx.
Please consider removing it. Thanks.

[w666]

I understand that @motdotla wants to make some money, but this feels against open-source spirit. One small lib in my dev stack decided it is the most important one and can log not very useful stuff to stdout. Thanks for all these years, but I am migrating out of it, and not to detenvx.

[simonwst]

Same here, this is confusing and will make us migrate away from dotenv as it doesn't look trustworthy if the maintainer just decides to put console.log's in their library (!!!) which is downloaded a million-times. What's next? ASCII images of ads? Good riddance, but I don't want any consumer of logs to break because of this.

[duncannz]

Logging from a library is never okay. Having to set quiet to true is not an acceptable workaround - imagine if you had to do this for every library you use!

Node.js has process.loadEnvFile() now anyway, so there's no need for this library any more.