Ignore .env and .env.build for deployments by default

[TooTallNate]

Because now dev uses these dotenv files to define the Now secrets to use, it would be bad practice to include them in the deployment files since they will be using development values instead of production values.

[codecov-io]

Codecov Report

Merging #2083 into canary will decrease coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           canary   #2083      +/-   ##
=========================================
- Coverage    4.63%   4.49%   -0.14%     
=========================================
  Files         243     243              
  Lines        8572    8572              
  Branches      873     873              
=========================================
- Hits          397     385      -12     
- Misses       8158    8170      +12     
  Partials       17      17

Impacted Files	Coverage Δ
src/util/ignored.ts	100% <ø> (ø)	⬆️
src/util/get-project-name.js	90.9% <0%> (-9.1%)	⬇️
src/util/get-files.js	91.53% <0%> (-8.47%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 658c220...7efa0a0. Read the comment docs.

[antmarot]

This is a breaking change for us.
What's the recommended/easiest way to still upload .env files?

[leo]

@antmarot We marked the release that includes this change a patch release because uploading .env poses a security risk. You should never do it, under any circumstance.

As defined in dotenv (the creator of .env), the file should only be used in development.

Please use secrets instead, which will encrypt your secrets upon upload.

[antmarot]

@leo Thanks for your reply. I totally understand the reason behind the change and I am convinced it was the necessary thing to do. I would however argue this is a breaking change though.

While dotenv strongly recommends against committing .env files, I don't think their use in production is considered bad practice. In my opinion, the question is more about how do you securely get that file there.

Anyway, my use case is not about secrets, but configuration values. I purposefully do not use the env section in now.json to avoid duplication of values (now is not the only place where we deploy).

If there is no flag or config to override the ignored .env I think I'll just rename it.

[leo]

@antmarot I understand. In that case, you can use the --dotenv flag to have Now CLI convert the values inside that file into regular environment variables supported by Now for you.

[nnennajohn]

@leo Thanks for the headups. I must have searched through a dozen comments before finding this. This should be perhaps included in the docs.

Just to be clear, assuming I have .env file && .env.build in the root of a monorepo setup:
now dev would use the vars in .env?
now --dotenv would deploy my production build with the vars in env.build?