Hacker News Reader

Comment by laurent123456 | Hacker News Reader

Why would they add built-in support when there's already a reliable well-supported package? Feels like bloatware and waste of resources. I'm sure there are lots of core functionalities that could be improved and optimised instead

View on HN

There is a clear trend to absorb popular packages into the core and I believe the main reason is to reduce the number of dependencies. Deno, for example, goes on this direction. Given the recent security issues with npm packages, I think it's a good idea to reduce the number of dependencies.

According to npm, dotenv has zero dependencies. That will reduce the usual dependency count from 12345 to a mind-blowing 12344.

Bloating runtimes seem like the wrong solution to this security issue though, and Node.js has security issues too. A lot of people don't ever need .env files, yet that will now be part of their deployment which will increase the attack surface of their application.

A well-supported package, plus several tools that you can learn once and use the same for any language or combo of languages. And those will still work when you have to git-bisect back to a version of your project that doesn’t have built-in .env setting.

Shipping this specific thing with nodejs seems deeply pointless to me.

Plus, having my program auto-monkey with its own environment, even optionally, feels… wrong. I should define it (or something should on my behalf) and the program should accept what it gets. Else, why even use env vars? Just use a config toml or some shit. But that part reasonable people could disagree over.

https://github.com/nodejs/node/pull/48890 provides the relevant context in some comment.

because "batteries included" is a good thing.

Reply on news.ycombinator.com