Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exposed env vars are not available #6626

Closed
7 tasks done
jost-s opened this issue Jan 25, 2022 · 16 comments · Fixed by #10370
Closed
7 tasks done

Exposed env vars are not available #6626

jost-s opened this issue Jan 25, 2022 · 16 comments · Fixed by #10370
Labels
bug: upstream Bug in a dependency of Vite p2-edge-case Bug, but has workaround or limited in scope (priority)
Milestone

Comments

@jost-s
Copy link

jost-s commented Jan 25, 2022

Describe the bug

Using an .env file to define environment variables, static values are passed on and available in Vue as expected. Exposing existing env vars to Vue, however, does not work and produces empty values.

I've exposed the env var using the syntax from this comment.

STR:

  • open reproduction
  • start dev server with command PORT=4000 npm run dev

Expected:
PORT should be available from main.js and output 4000.

Actual:
PORT is an empty string.

Reproduction

https://stackblitz.com/edit/vitejs-vite-bxj6nd?devtoolsheight=33&file=.env

System Info

System:
    OS: macOS 11.6.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Memory: 1.36 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.2 - ~/.nix-profile/bin/node
    npm: 8.1.2 - ~/.nix-profile/bin/npm
  Browsers:
    Brave Browser: 97.1.34.81
    Safari: 15.2

Used Package Manager

npm

Logs

...
vite:config   env: {
vite:config     VITE_PORT: '',
vite:config     BASE_URL: '/',
vite:config     MODE: 'development',
vite:config     DEV: true,
vite:config     PROD: false
vite:config   },
...

Validations

@bluwy
Copy link
Member

bluwy commented Jan 26, 2022

I'm able to reproduce this, but this doesn't seem to be Vue specific

@jost-s jost-s changed the title Exposed env vars are not available in Vue Exposed env vars are not available Jan 26, 2022
@jost-s
Copy link
Author

jost-s commented Jan 26, 2022

I'm able to reproduce this, but this doesn't seem to be Vue specific

You're right, plus issues here are supposed to be framework agnostic. I've removed it from the title, thanks!

@bluwy
Copy link
Member

bluwy commented Jan 26, 2022

Looks like this line is preventing it:

ignoreProcessEnv: true

But I'm not sure if this was suppose to work in the first place since the comment linked is almost 2 years ago, and it's not documented.

@bluwy bluwy added enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority) and removed pending triage labels Jan 26, 2022
@poyoho
Copy link
Member

poyoho commented Jan 26, 2022

but use all the process env will trigger unexpected error, may be env set aaa=123
in the build mode will replace const aaa = 123 to const 123 = 123

@jost-s
Copy link
Author

jost-s commented Jan 26, 2022

but use all the process env will trigger unexpected error, may be env set aaa=123 in the build mode will replace const aaa = 123 to const 123 = 123

This is about explicitly exposed env vars, not all env vars. Only if you write

VITE_PORT=$PORT

in a .env file, it should be made available in Vite.

@jost-s
Copy link
Author

jost-s commented Jan 26, 2022

Yes, it would be great if it did. I'm looking for a way to pass env vars into Vite, and Evan's comment from back then sounded like it should be possible.

@poyoho
Copy link
Member

poyoho commented Jan 26, 2022

may be VITE_PORT?

@jost-s
Copy link
Author

jost-s commented Jan 26, 2022

That's what I tried, please look at the reproduction and debug output above.

@poyoho
Copy link
Member

poyoho commented Jan 30, 2022

may be motdotla/dotenv-expand#55 mentioned this

@svenjacobs
Copy link

I'm currently also struggling with this. I want to pass along a Docker environment variable to a VITE_ variable so that it is available during compile time and I can access it in my JavaScript frontend and backend code, let's say a GraphQL URL for example. This is a SvelteKit app but it shouldn't make any difference.

VITE_GRAPHQL_URL=$GRAPHQL_URL

Is there any solution / workaround?

@jost-s
Copy link
Author

jost-s commented Feb 8, 2022

@svenjacobs The workaround that I'm currently using is to declare the env var as part of the script that I run to start vite, e. g.:

VITE_PORT=$PORT vite

@svenjacobs
Copy link

@svenjacobs The workaround that I'm currently using is to declare the env var as part of the script that I run to start vite, e. g.:

VITE_PORT=$PORT vite

Thanks, this seems to work for now 😃

@bluwy bluwy added bug: upstream Bug in a dependency of Vite p2-edge-case Bug, but has workaround or limited in scope (priority) and removed enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority) labels Apr 4, 2022
@lasseborly
Copy link

I'm currently also struggling with this. I want to pass along a Docker environment variable to a VITE_ variable so that it is available during compile time and I can access it in my JavaScript frontend and backend code, let's say a GraphQL URL for example. This is a SvelteKit app but it shouldn't make any difference.

VITE_GRAPHQL_URL=$GRAPHQL_URL

Is there any solution / workaround?

I'm in the same situation.

Just returns an empty string.

@svenjacobs
Copy link

I'm in the same situation.

Just returns an empty string.

In my case it was an improper Docker / Docker Compose configuration. In my Dockerfile I had to make sure to specify the arguments which I want to pass during Docker build time as ARG and assign them to ENV variables, something like

ARG HASURA_GRAPHQL_URL
ENV VITE_HASURA_GRAPHQL_URL $HASURA_GRAPHQL_URL

and my docker-compose.yml looks like

services:
  my-service:
    build:
      dockerfile: my-service/Dockerfile
      args:
        HASURA_GRAPHQL_URL: https://some-url

Maybe this helps 🤷🏼‍♂️

@szisiu
Copy link

szisiu commented Aug 5, 2022

Hi, I am experiencing the dotenv variables expanding issue while trying to develop a component for my vue3 app that displays its current version from package.json.

.env

# Only VITE_SOME_KEY will be exposed as import.meta.env.VITE_SOME_KEY to your client source code
VITE_APP_VERSION=$npm_package_version

AppVersion.vue

<template>
  <span>v. {{ version }}</span>
</template>

<script setup lang="ts">
const version = import.meta.env.VITE_APP_VERSION;
</script>

Other solution that worked for me (maybe better in my case) was to use vite's define config option:

vite.config.ts

import { defineConfig, loadEnv } from 'vite'

// https://vitejs.dev/config/
export default defineConfig(({ command, mode }) => {
  // src: https://github.com/vitejs/vite/blob/main/packages/vite/src/node/env.ts
  // Load env file based on `mode` in the current working directory.
  // Set the third parameter to '' to load all env regardless of the `VITE_` prefix.
  const env = loadEnv(mode, process.cwd(), '')
  return {
    // vite config
    define: {
      __APP_VERSION__: JSON.stringify(env.npm_package_version),
    }
  }
})

.env.d.ts

/// <reference types="vite/client" />

declare const __APP_VERSION__: string;

AppVersion.vue

<template>
  <span>v. {{ version }}</span>
</template>

<script setup lang="ts">
/* global __APP_VERSION__ */
const version = __APP_VERSION__;
</script>

Hope it helps someone.

I am looking forward guys from dotenv-expand to solve the issue: motdotla/dotenv-expand#55

@motdotla
Copy link

Just released https://github.com/motdotla/dotenv-expand/blob/master/CHANGELOG.md#900-2022-08-30

@bluwy bluwy added this to the 4.0 milestone Sep 23, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Nov 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug: upstream Bug in a dependency of Vite p2-edge-case Bug, but has workaround or limited in scope (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants