4 ms·
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
by laurent123456 3y ago
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
- rat9988 3y agohttps://github.com/nodejs/node/pull/48890 https://github.com/nodejs/node/pull/48890 provides the relevant context in some comment.
- dlojudice 3y agoThere 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.
- wruza 3y agoAccording to npm, dotenv has zero dependencies. That will reduce the usual dependency count from 12345 to a mind-blowing 12344.
- shard972 3y ago[dead]
- laurent123456 3y agoBloating 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.
- _ZeD_ 3y agobecause "batteries included" is a good thing.
- hotnfresh 3y agoA 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.