• towerful@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 year ago

      This has been made by so many packages, they would be silly not to incorporate their work - licence dependent of course.

      Edit - wait, not the exploit thing. The .env file thing

  • popcar2@programming.dev
    link
    fedilink
    English
    arrow-up
    11
    ·
    1 year ago

    Better late than never. It’s going to take a while for people to get used to not needing the dotenv package.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      1 year ago

      dotenv has lots of features and I doubt node will try to match all of them.

      The builtin node feature needs you to specify .env files as parameters to the node executable and puts values in process.env, that’s it. It’s great if that’s all you need.

      With dotenv (which should’ve been called dotini) you can choose a file (any file, not just .env) to parse programatically, you can parse variables, you can specify the encoding and the override behavior, you can enable debugging, you can put the values in a different variable from process.env, you can do decryption, and it supports multiline values.

      Last but not least, process.env was supposed to contain actual environment variables. Patching it with values from config files and mixing up the two concepts is a mistake – but at least dotenv lets you avoid it. With dotenv you can read from .config and put the values in process.config; with the node version you can read from .config files (at least I hope you’ll be able to) but it goes to process.env whether you like it or not.

  • burnso@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    I wonder of this will also apply to npm then. I have a package that uses private packages which requires a personal access token to be present in env. Would make for nicer DX in our case.