Ignore only local env files in Vite templates

[silvenon]

In Vite .env files work a bit differently, where .env itself is intended to be public, and .env.local is the one that should be ignored by Git. But a Vite project can have more .env files, like .env.development, which is used only in development mode, and overrides values in .env, then you can have .env.development.local as well and so on.

.env                # loaded in all cases
.env.local          # loaded in all cases, ignored by git
.env.[mode]         # only loaded in specified mode
.env.[mode].local   # only loaded in specified mode, ignored by git

https://vitejs.dev/guide/env-and-mode.html#env-files

It appears that Vite uses just *.local pattern for their templates, but I'm not comfortable with that 😄

[changeset-bot]

⚠️ No Changeset found

Latest commit: a62f3be

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[brophdawg11]

I'l defer to @pcattori and @markdalgleish here but I found this Vite recommendation surprising. I've always git ignored all .env files to avoid ever accidentally committing secrets to git history - and use whatever my deployment choices are to determine how to set ENV vars in higher environments.

IMO, loosening this to .env.local feels like a footgun and I'd prefer to let folks make that decision for their specific app/use-case after installing from the template.

[silvenon]

Fair points. I'm mostly just annoyed with migrating from a git-ignored .env setup to a Vite .env.local. Also, I can imagine that .env.[mode] are generally rarely used, but for new projects I thought it would be nice to have this extra bit of power and swim with the Vite current. And the pattern is not unheard of, Next.js has something similar with .env.local AFAICT, and people who work with Vite know or are are about to find out how environment files work with Vite.

For me it's nice that .env can serve both as defaults AND docs, instead of an often forgotten .env.template, unless dotenv-safe is used.

I just realized that it may also be good to create an .env file in each Vite template with the comment that it's a public .env file, and add a link to Vite's docs on how .env files works. In case there is interest from the team in proceeding with this I'd like to add those.

[brophdawg11]

people who work with Vite know

For whatever reason, we've seen a lot of unfamiliarity with Vite since adding support in Remix. We keep getting a lot of issues filed that are really Vite questions so we points folks to the vite docs. So I worry that we can't assume folks already know the Vite-isms.

or are are about to find out how environment files work with Vite

This is exactly my fear haha - I don't want folks to find out the hard way by accidentally leaking a secret...

The important thing here IMO is that we haven't restricted any options from end users. We've just defaulted to an arguably "safer" setup, but advanced users like yourself are one line away from the proper (but potentially riskier) Vite approach.

[silvenon]

I can't say that I don't agree, it may be most appropriate choice for this project. People can easily opt into Vite's .env variables if they want to. Handling .env across Remix templates the same way seems safer anyway.

[markdalgleish]

I'm coming in late to this one, but I agree with @brophdawg11's take on this. To me this doesn't feel like a "Vite-ism" since it's just a template concern and it's ultimately completely user controlled. I'm happy with our more conservative approach since the cost of getting it wrong is too high. If anyone disagrees, it's an easy change.