What would you pay for?

[motdotla]

Recently I added a promotion to the runtime message and it has been met with mixed reviews. [1] On the positive it has exploded the number of users switching to dotenvx for more secure .env files. That's a net positive for software security.

But for all you haters, what could I charge for? Then I'd consider removing the promotion since I could use the money to market dotenvx.

Anything you've ever wanted dotenv to do? Is there a simple flag I could add that you'd turn on and pay a nominal one-time or yearly fee for? Help me come up with ideas to finance dotenv's continued development into this next agentic wave.

Thank you, and all the best to my haters :)

[1] #876

[stevage]

I don't want you to give me features and try to charge me for them. I want you to leave the software the way it is. If you're not willing to do that, just mark it as deprecated and I'll switch to something different.

If every package maintainer takes the path that you are, where every package will one day start spamming the user to purchase the developer's other products and services, the NPM landscape will be an absolutely miserable place.

Please, please resist.

[duncannz]

This whole thing is so embarrassing especially considering how simple this library is - any developer could write their own version in a few minutes, but has just been using this library for convenience. Now it's not even more convenient, since process.loadEnvFile() is built in to Node.

If every library decided it was okay to log ads at runtime, it would destroy the ecosystem, but if one library thought they were uniquely special enough to justify doing so, you'd think it would be something a bit more complex 😅

[Mister-Hope]

I think this library may not be needed anymore once Node.js 20 and 22 are out of LTS.

See: https://nodejs.org/docs/latest/api/process.html#processloadenvfilepath (as @duncannz has previously pointed out).

Please be aware that most users use this pkg for one simple goal: to achieve what process.loadEnvFile() now does, and nothing more.

Thank you for your work before Node.js supported this natively. But,

Do not take your stars serious, your pkg just perfectly do the job, and users prefer to use a simple package instead of writing 20 lines of code to load env in every project, that's all. There will be another similar one if you don't build it the first. That said, it should be expected that the users mentioned above are not okay with a default runtime log which makes their logs dirty. Most of them, including myself, would be fine with an install-time or a one-time log instead.

P.S: I don't think you can keep these users, even with new features, unless you stop making a promotion by default every time. I believe this is a required step.

Add something more: dotenvx is indeed a nice package, it solves some problems, but not all of us need them. I believe there should be enough users that want to simplify here: simple .env files, excluding them and not introducing any complex.

[peternixey]

I just wish you didn't publish so much spam into my logs on startup. Your updates have resulted in me having to spend four different occasions figuring out how to stop the noise. And as other people said it's pretty awful. I'm very grateful to you for the work you've done to create this but there are hundreds of NPM packages in my project and if each maintainer decided to do this then the entire project would collapse.

This is the fourth time I've been through this cycle. Your promotions are now my noise.

This is what my startup logs look like since your update:

Scope: 2 of 8 workspace projects
../code-style-config build$ :
../code-style-config build: Done
../shared prebuild$ rm -rf dist
../shared prebuild: Done
../shared build$ tsc -p tsconfig.json
../shared build: Done
  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: ⚙️  enable debug logging with { debug: true }

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: ⚙️  specify custom .env file path with { path: '/custom/path/.env' }

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: ⚙️  suppress all logs with { quiet: true }

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: 🔐 prevent building .env in docker: https://dotenvx.com/prebuild

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: ✅ audit secrets and track compliance: https://dotenvx.com/ops

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: ⚙️  write to custom object with { processEnv: myObject }

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: ⚙️  suppress all logs with { quiet: true }

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

PASS nestjs src/config/non-production-secrets-validation.spec.ts
  Non-Production Secrets Validation
    ✓ should not contain production Clerk credentials (48 ms)
    ✓ should not contain production database URLs (1 ms)

  console.log
    [dotenv@17.2.3] injecting env (15) from ../../.env -- tip: 🛠️  run anywhere with `dotenvx run -- yourcommand`

      at _log (../../node_modules/.pnpm/dotenv@17.2.3/node_modules/dotenv/lib/main.js:142:11)

[tstibbs]

I could use the money to market dotenvx.

@motdotla Is the goal just to get everyone to move to dotenvx? If so why continue to develop dotenv? If you stopped releasing new versions of dotenv, you could mark dotenv as deprecated in npm with a message saying to move to dotenvx. I feel like that would push more users across than the current marketing messages.

Sure, the deprecation message will only be seen by users that upgrade to the latest versions, but then the same is true of the log messages anyway. Sure, you'll lose a few users who don't feel that they need the complexity of dotenvx, but that's true however you market dotenvx.

[Neurone]

Guys, are you really here in 2025 complaining about the pain to set a config variable to true?

All this fuss because you need to write

require('dotenv').config({ quiet: true }) 

instead of

require("dotenv").config()

in your code when using the new v17 library?

It's trivial for new project, and even for a huge existing repository a simple replace all operation can set this in less than a few seconds.

Since 2015, Scott has created and maintained the code for this library for free, allowing ~22 million lazy developers to avoid creating, sharing, and maintaining their own code.

If you don't like v17, remain on v16, fork this repo and use your custom version, use the native process.loadEnvFile() where applicable, use dotenvx, or write your own library. The limit is the sky.

@motdotla There's no way you can make these people change their minds, make them understand the value of time spent for others, or make them pay anything. Don't waste your time on this discussion. And thank you for the work you have done and are doing with this library and with dotenvx; it is really appreciated.

[duncannz]

@Neurone That's a pretty big stretch - it's one of the simplest libraries imaginable. Any developer could write their own version in a few minutes, but this library just happened to become the most popular due to there (previously) being no real reason to use a different one.

Taking advantage of that position to push ads is unacceptable, and even if it can be turned off with a config flag, if it was seen as acceptable in the open source community, it actually would be a massive problem having to turn off spam config flags for hundreds of different libraries. That's probably the most important reason for all the pushback.

[motdotla]

Thank you @Neurone. really appreciate you speaking up.

If you ever want Dotenvx Ops, reach out and I’ll set you up with a fully comped account.

[motdotla]

@duncannz I wonder if you have considered the number of man hours put into dotenv? It's 900 commits, 520 issues, 370 pull requests, and almost 140k line changes.

[Mister-Hope]

It's 900 commits, 520 issues, 370 pull requests, and almost 140k line changes.

So, should file structure refactoring and changes in package-lock.json really be considered 'line changes'?

One-third of the commits only contain a single line change, and nearly one-fifth are meaningless merge commits.

An example here, I can see you are trying your best to make a good-looking design about the video part👍,but it's unacceptable for me that these are "15 real commits". At least for me I will do the job in a working branch and squash commit to the main branch.

I'm not trying to blame you or ignore your work dealing issues and PRs, but your data is heavily inflated.

I am also doing open source, so I fully agree that as a maintainer, you may spend a lot of time handling issues and PRs, while a lot of them may not be even any issue on your side. Again, I really appreciate this part.

But it still does not conflict with the fact that this library is still a simple one. I did not see any complex in API design, state management, reactivity tracking, plugin system, UI handling and such. For self-promotion (or just advertising), it's rare to see that a pkg is spamming users logs, specially the pkg is just installed to deal a simple goal in a project.
And again, you should be expected to see others are annoying about this. People may be acceptable for some huge project to do so, e.g.: react, Vue, nuxt, esbuild, etc., but I don't think for most of them they shall accept pkg like dotenv (and any simple ones like magic-stirng, string-width, emoji-regex).

And with all the repos are doing such like you, e.g.: glob decides to also add a "promotion" log to console: (just an example)

Matching xx files, (try our ultra-fast fs-ultra package that as glob built-in at https://ultra-fast-glob.io)

unless you gives an option quiet: true, you should find yourself being annoyed either.

That's why I also fully understand what @peternixey feels:

I just wish you didn't publish so much spam into my logs on startup. Your updates have resulted in me having to spend four different occasions figuring out how to stop the noise. And as other people said it's pretty awful. I'm very grateful to you for the work you've done to create this but there are hundreds of NPM packages in my project and if each maintainer decided to do this then the entire project would collapse.

This is the fourth time I've been through this cycle. Your promotions are now my noise.

Adding the promotion may be your right, but the community will sure leave you as the default behavior is really not the proper things that the community wants.

[peternixey]

@motdotla I apologise if my comments came off as unkind. I'm extremely grateful to you and all other open source maintainers for everything you do. None of us could do anything without open source and we are all indebted to it and to people like yourself for maintaining it.

I have always thought of the quid pro quo of open source as being the status and hireability that it creates for the owner. That said I'm hugely admiring of maintainers who commute their projects into premium versions too. I think the whole system would work better with stronger financial incentives and I'm delighted when they align.

I hope you are able to make dotenvx work well for you and generate money. My main share was that the key incentive I felt after dealing with all of the promo updates was moving off dotenv altogether. Which probably wasn't the ideal outcome ;)