6 ms·

(Warning: I am being Dennis Downer) Meanwhile, we're still waiting on WebSockets and it's been nearly 10 years. Everyone should read the PR https://github.com/

(Warning: I am being Dennis Downer) Meanwhile, we're still waiting on WebSockets and it's been nearly 10 years. Everyone should read the PR https://github.com/nodejs/node/pull/48890 https://github.com/nodejs/node/pull/48890. It doesn't traverse parent directories, it doesn't have good overwrite/merge logic, multiline support, or variable expansion - things that dotenv has supported for years (sometimes with add-ons). This is another half-useful implementation that the majority will end up ignoring, and keep using better-suited third party packages for. Node is committee'd to death, and the comments in that PR are further proof. I've been in the Node ecosystem since 2010, and my money is on Bun and Deno to lead the way forward.

madeofpalk 3y ago
I think it is fine for node to have limited, basic, built in support for .env files, and then leave the opportunity for the ecosystem to add in more features. Easy things should be easy, and hard things should be possible through npm install.
- c-hendricks 3y ago
  Great way of putting it. It does seem a little off compared to how `npm run` works (it traverses up to a package.json), but I agree .env files could get sketchy. Maybe it could traverse up to where it finds a package.json actually.
cal85 3y ago
I agree. Since you seem to know the area, do you have any comment on which contender (Bun or Deno) you see as most likely to take the crown, and also which you’d prefer to take the crown? By ‘the crown’ I mean the status of being the leading JS runtime outside of web browsers. For me, Deno seems very well thought out, I’ve used it a fair bit and found it to work reliably and fast. I like the whitelist approach to system access although I worry that it could be a hurdle for adoption. I haven’t used Bun, just read about it. My sense is that Bun is more of a 1:1 replacement for Node, still tied to npm as a first class citizen, while Deno has a long term strategy to get away from npm (while supporting it as a legacy thing). Overall I’d prefer Deno to win, but I wonder if Bun has a better chance due to its closer parity with Node.
- flkenosad 3y ago
  I think you're right, Bun has a better chance just because because it's a drop in replacement and because it genuinely outperforms the existing tooling by a good margin. Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond.
  - dns_snek 3y ago
    > Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond. I'm not disagreeing necessarily, but wow, I really hope it doesn't come to that. The timeline where languages, runtimes (and by extension libraries, frameworks, and even tools) are chosen based on how well they're supported by LLM tooling sounds horrifying. It would block adoption of better designed languages, tools and frameworks. If evolution is going to be stifled by LLMs, we'll miss out on paradigm shifts like JS Promises and ES6.
    - dragonwriter 3y ago
      > It would block adoption of better designed languages, tools and frameworks. Tooling concerns are already are a major source of friction for adoption, nothing really special about LLMs in that regard.
    - cal85 3y ago
      Humans are always used to working a certain way, and this fact benefits the incumbent technologies/tools/platforms of the day. This benefit must be outweighed by other factors, or we'd still be writing Fortran (or drawing on cave walls). The addition of LLMs to the mix might add to incumbency bias by being trained on whatever ecosystems are most popular, but I think this will be vastly outweighed by all the other things they bring to the table. We know that one thing LLMs are already pretty impressive at is translating between programming languages. So if anything, I can see LLMs launching a new era of diversification by making it easier for programmers to justify choosing a more esoteric/interesting language for a project without worrying so much about whether they will be able to find library code for their needs, as they'll be able to translate it without so much trouble.
rat9988 3y ago
After reading the comments on the PR, I don't understand the doomsaying here in your comment.
- programmarchy 3y ago
  I had the same impression as you. They didn't even close the door on some of those "missing" features; rather they're being judicious about what to include in the initial release. Classic 80/20.
lcfcjs 3y ago
[dead]
ilyt 3y ago
> It doesn't traverse parent directories So there is chance it won't be massive security hole enabled by default! Great! > it doesn't have good overwrite/merge logic, multiline support, or variable expansion - things that dotenv has supported for years (sometimes with add-ons) 99% of what I used env files for was just a bunch of key-values for db passwords so their minimal implementation is probably good enough for most. Then again, that's experience from other than node ecosystems, and if config requires "multiline support, or variable expansion" we either make proper config file or a template for CM to deploy.
- willio58 3y ago
  > So there is chance it won't be massive security hole enabled by default! Great! True that. Sometimes committees lead to bloat. And sometimes committees lead to not adding magic to everything that ends up being abused by malicious actors. I love that deno and bun exist and are getting rapidly developed. By I also love the Node has been and continues to be a rock for the industry.
- hotnfresh 3y ago
  That is a strong argument for using external tools to define the environment, and not installing any of the sort that’d read a .env file on any kind of deployed environment at all (just local dev machines) So another mark in the “why have this feature in the first place?” column. The whole concept is for dev ergonomics, but this one’s making that worse for security reasons? Ugh. Just leave it out entirely, then.
thiht 3y ago
> It doesn't traverse parent directories, it doesn't have good overwrite/merge logic, multiline support, or variable expansion Sounds good to me. If I need more one day I’ll use dotenv, but having basic support in the stdlib is great
tompic823 3y ago
I'm the CTO of a popular Secrets Management platform. It's fair to say that I personally have a lot of experience with secrets and requirements around them, based on conversations with customers. The primary missing feature here seems to be multiline support. That's super common for keys, certificates, and other JSON configuration. Based on the Node PR, they appear open to adding that later (big +1 on shipping incrementally). The other missing feature that folks tend to heavily rely on is variable expansion. For that to truly work well, I recommend using a holistic platform like Doppler. That allows for expansion/referencing across environments and projects, like when you have multiple independent services that need access to the same set of secrets (e.g. database creds, error reporting tool, stripe key, etc). You can then update the secret once and have the change propagate to all the places it's used. Lastly, I'd be remiss if I didn't mention the Doppler CLI and our own fairly unique support for .env files. We've traditionally taken a dim view of .env files because they represent a static, long-lived collection of sensitive information that lives offline. Often, these get checked into a git repo. This is probably fine for personal projects, but a major issue for companies and the security aware. However, .env files are a pseudo standard and folks want a way of continuing to consume their secrets via them. Our CLI's approach is to mount a named pipe that we can write secrets to when a reader attaches. That allows us to limit the amount of times the "file" can be read (e.g. once), it guarantees that the file's contents are unavailable once the application process dies, and it uses the same open/read interface as a standard file. In all, this is an exciting development for Node. I'm glad to see more standard features make it into core and hope that multiline support is a fast follow.
- korijn 3y ago
  Check out keycmd[1], you might appreciate the ideas there. Disclaimer: it's my project. [1] https://github.com/ClinicalGraphics/keycmd https://github.com/ClinicalGraphics/keycmd
- syspec 3y ago
  > The primary missing feature here seems to be multiline support. That's super common for keys, certificates, and other JSON configuration. Easy enough to just Base64 encode the value the way Kubernetes does
euos 3y ago
Fun fact - I added a pretty feature complete WS connection in Node core (https://github.com/nodejs/node/blob/main/src/inspector_socket.cc https://github.com/nodejs/node/blob/main/src/inspector_socke...) 7 years ago (it is well-tested - every debug/profiling session goes through it). There's no public API for it because I did not want to deal with politics. There's rudimentary HTTP server as well (no TLS and such though). All in C++. Should be fairly fast, based on expertise of the Chromium team.
yxre 3y ago
[dead]
gumballindie 3y ago
I'm pretty OK with NodeJS being as basic as possible.

madeofpalk 3y ago

I think it is fine for node to have limited, basic, built in support for .env files, and then leave the opportunity for the ecosystem to add in more features. Easy things should be easy, and hard things should be possible through npm install.

c-hendricks 3y ago
Great way of putting it. It does seem a little off compared to how `npm run` works (it traverses up to a package.json), but I agree .env files could get sketchy. Maybe it could traverse up to where it finds a package.json actually.

cal85 3y ago

I agree. Since you seem to know the area, do you have any comment on which contender (Bun or Deno) you see as most likely to take the crown, and also which you’d prefer to take the crown? By ‘the crown’ I mean the status of being the leading JS runtime outside of web browsers. For me, Deno seems very well thought out, I’ve used it a fair bit and found it to work reliably and fast. I like the whitelist approach to system access although I worry that it could be a hurdle for adoption. I haven’t used Bun, just read about it. My sense is that Bun is more of a 1:1 replacement for Node, still tied to npm as a first class citizen, while Deno has a long term strategy to get away from npm (while supporting it as a legacy thing). Overall I’d prefer Deno to win, but I wonder if Bun has a better chance due to its closer parity with Node.

flkenosad 3y ago
I think you're right, Bun has a better chance just because because it's a drop in replacement and because it genuinely outperforms the existing tooling by a good margin. Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond.
- dns_snek 3y ago
  > Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond. I'm not disagreeing necessarily, but wow, I really hope it doesn't come to that. The timeline where languages, runtimes (and by extension libraries, frameworks, and even tools) are chosen based on how well they're supported by LLM tooling sounds horrifying. It would block adoption of better designed languages, tools and frameworks. If evolution is going to be stifled by LLMs, we'll miss out on paradigm shifts like JS Promises and ES6.
  - dragonwriter 3y ago
    > It would block adoption of better designed languages, tools and frameworks. Tooling concerns are already are a major source of friction for adoption, nothing really special about LLMs in that regard.
  - cal85 3y ago
    Humans are always used to working a certain way, and this fact benefits the incumbent technologies/tools/platforms of the day. This benefit must be outweighed by other factors, or we'd still be writing Fortran (or drawing on cave walls). The addition of LLMs to the mix might add to incumbency bias by being trained on whatever ecosystems are most popular, but I think this will be vastly outweighed by all the other things they bring to the table. We know that one thing LLMs are already pretty impressive at is translating between programming languages. So if anything, I can see LLMs launching a new era of diversification by making it easier for programmers to justify choosing a more esoteric/interesting language for a project without worrying so much about whether they will be able to find library code for their needs, as they'll be able to translate it without so much trouble.

rat9988 3y ago

After reading the comments on the PR, I don't understand the doomsaying here in your comment.

programmarchy 3y ago
I had the same impression as you. They didn't even close the door on some of those "missing" features; rather they're being judicious about what to include in the initial release. Classic 80/20.

lcfcjs 3y ago

[dead]

ilyt 3y ago

> It doesn't traverse parent directories So there is chance it won't be massive security hole enabled by default! Great! > it doesn't have good overwrite/merge logic, multiline support, or variable expansion - things that dotenv has supported for years (sometimes with add-ons) 99% of what I used env files for was just a bunch of key-values for db passwords so their minimal implementation is probably good enough for most. Then again, that's experience from other than node ecosystems, and if config requires "multiline support, or variable expansion" we either make proper config file or a template for CM to deploy.

willio58 3y ago
> So there is chance it won't be massive security hole enabled by default! Great! True that. Sometimes committees lead to bloat. And sometimes committees lead to not adding magic to everything that ends up being abused by malicious actors. I love that deno and bun exist and are getting rapidly developed. By I also love the Node has been and continues to be a rock for the industry.
hotnfresh 3y ago
That is a strong argument for using external tools to define the environment, and not installing any of the sort that’d read a .env file on any kind of deployed environment at all (just local dev machines) So another mark in the “why have this feature in the first place?” column. The whole concept is for dev ergonomics, but this one’s making that worse for security reasons? Ugh. Just leave it out entirely, then.

thiht 3y ago

> It doesn't traverse parent directories, it doesn't have good overwrite/merge logic, multiline support, or variable expansion Sounds good to me. If I need more one day I’ll use dotenv, but having basic support in the stdlib is great

tompic823 3y ago

I'm the CTO of a popular Secrets Management platform. It's fair to say that I personally have a lot of experience with secrets and requirements around them, based on conversations with customers. The primary missing feature here seems to be multiline support. That's super common for keys, certificates, and other JSON configuration. Based on the Node PR, they appear open to adding that later (big +1 on shipping incrementally). The other missing feature that folks tend to heavily rely on is variable expansion. For that to truly work well, I recommend using a holistic platform like Doppler. That allows for expansion/referencing across environments and projects, like when you have multiple independent services that need access to the same set of secrets (e.g. database creds, error reporting tool, stripe key, etc). You can then update the secret once and have the change propagate to all the places it's used. Lastly, I'd be remiss if I didn't mention the Doppler CLI and our own fairly unique support for .env files. We've traditionally taken a dim view of .env files because they represent a static, long-lived collection of sensitive information that lives offline. Often, these get checked into a git repo. This is probably fine for personal projects, but a major issue for companies and the security aware. However, .env files are a pseudo standard and folks want a way of continuing to consume their secrets via them. Our CLI's approach is to mount a named pipe that we can write secrets to when a reader attaches. That allows us to limit the amount of times the "file" can be read (e.g. once), it guarantees that the file's contents are unavailable once the application process dies, and it uses the same open/read interface as a standard file. In all, this is an exciting development for Node. I'm glad to see more standard features make it into core and hope that multiline support is a fast follow.

korijn 3y ago
Check out keycmd[1], you might appreciate the ideas there. Disclaimer: it's my project. [1] https://github.com/ClinicalGraphics/keycmd https://github.com/ClinicalGraphics/keycmd
syspec 3y ago
> The primary missing feature here seems to be multiline support. That's super common for keys, certificates, and other JSON configuration. Easy enough to just Base64 encode the value the way Kubernetes does

euos 3y ago

Fun fact - I added a pretty feature complete WS connection in Node core (https://github.com/nodejs/node/blob/main/src/inspector_socket.cc https://github.com/nodejs/node/blob/main/src/inspector_socke...) 7 years ago (it is well-tested - every debug/profiling session goes through it). There's no public API for it because I did not want to deal with politics. There's rudimentary HTTP server as well (no TLS and such though). All in C++. Should be fairly fast, based on expertise of the Chromium team.

yxre 3y ago

[dead]

gumballindie 3y ago

I'm pretty OK with NodeJS being as basic as possible.