You signed in with another tab or window.
Reload
to refresh your session.
You signed out in another tab or window.
Reload
to refresh your session.
You switched accounts on another tab or window.
Reload
to refresh your session.
Already on GitHub?
Sign in
to your account
.env.[mode].local is useless , Because it will always be bundled , even if git has ignored it ||||| .env.[mode].local 的使用场景在哪?即使git忽略了它,它也总是会被打包进去
#15393
.env.[mode].local is useless , Because it will always be bundled , even if git has ignored it ||||| .env.[mode].local 的使用场景在哪?即使git忽略了它,它也总是会被打包进去
#15393
AnnCY1
opened this issue
Dec 20, 2023
· 8 comments
Description
Let's say I have two files:
.env.development
and
.env.development.local
. Even though git has ignored the.local file, when npm run build-dev, vite would still bundle
.env.development.local
into the dist file, which would cause the environment variables in.local to overwrite the original file, and the development environment would work, but the production environment would break. The.local file should only exist locally.
Vite also didn't provide any configuration to ignore specific files, so I had to delete the.local file, change the.env.development file during development, and then restore the environment file in production.
Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
I think OP referred to the env vars being inlined into the final bundle. But back to the original description, I don't think it makes
.local
useless? It's used for env vars that you don't want to commit to git. If there's a mismatch in dev and build where you forgot to create the
.local
, that's an issue in the dev workflow. Closing this issue for now, but feel free to clarify if I got it wrong.
I think OP referred to the env vars being inlined into the final bundle. But back to the original description, I don't think it makes
.local
useless? It's used for env vars that you don't want to commit to git. If there's a mismatch in dev and build where you forgot to create the
.local
, that's an issue in the dev workflow. Closing this issue for now, but feel free to clarify if I got it wrong.
My problem was that vite bundled.env.[mode].local files as well, and I couldn't make.local files truly local only.
My Vue3 code looks like this:
I'm sure the variables for .env.development and .env.development are different
vite does not build the .env.development.local module during the build phase. Can you provide a minimal reproducible repository?
I don't think so. After my many tests, vite only uses loadEnv(mode, process.cwd()).xxx in the vete.config.ts file, not the build.local file, but like this: import.meta.env.xxx, will be put into the dist file by vite build.
Without specifying a mode, Vite will default to loading the production .env module during the build phase. Vite will then load the following .env modules accordingly(when the module exists), with later rules overriding previous ones.
.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
Without specifying a mode, Vite will default to loading the production .env module during the build phase. Vite will then load the following .env modules accordingly(when the module exists), with later rules overriding previous ones.
.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
Yes, but the problem is that .env.[mode].local has higher priority than.env.[mode]. After vite build, variables in .env.[mode].local will overwrite variables in .env.[mode]. I also couldn't exclude .env.[mode].local, so I think this file, despite its name, is not purely local and will be shipped online by vite.
It's used for env vars that you don't want to commit to git. If there's a mismatch in dev and build where you forgot to create the .local, that's an issue in the dev workflow.
I think @bluwy has already explained the role of .env.[mode].local.