.env in .gitignore

[mlntr]

Describe the feature you'd like to request

Why doesn't Next's .gitignore include .env? Seems strange to contain multiple advanced .envs and exclude the most common and obvious one, which is the basic .env

Describe the solution you'd like

Add ".env" to Next's auto-generated .gitignore

Describe alternatives you've considered

I typically have a basic .env file in my directory, so I need to manually add a new line in .gitignore — in itself that's not a big deal, but seems dumb to have to do it when there are already multiple different .env files and yet none of these is the basic .env

[thibautsabot]

Hello!

Why would you ignore the .env file ?
It defines default values and should be included in your repository.

Only .env.*.local should be ignored IMO as it is probably the ones that will include your secrets.

See the related docs: https://nextjs.org/docs/basic-features/environment-variables#default-environment-variables

[mlntr]

I see what you mean, but it is common for .env file to be the only env file used that contains sensitive data (hence good practice to ignore).

It may be better to instead have something like .env.public, .env.production.public, etc for the purpose of shared .env files. That would be the inverse of how it currently is, so .env, .env.production, etc would be assumed to be sensitive (thus ignored), which would be more safe.

[gztomas]

To add to this, this Vercel's guide shows a good example of how ignoring .env is important. The example repo needs to ignore it.

The guide suggests pulling vars into that file vercel env pull .env. Probably because that's where Prisma reads them from by default, which is a pretty standard behavior AFAIK, as @mlntr points out.

[trevorpfiz]

this is a no-brainer. if you want env vars to be public it should be set explicitly .env.public. why is the default to have to explicitly set something to be private?