Access env variables from Azure Static Web App

[rubenberna]

Describe the bug

Unlike variables from env files, where you can access them with import.meta.env, the ones specified in an Azure Static Web app are not accessible.

As a workaround, I've tried to change access to process.env in the vite config:

import { defineConfig, loadEnv } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig(({ command, mode }) => {
  const externalEnvs = loadEnv(mode, process.cwd(), '');
  return {
    plugins: [react()],
    define: {
      externalEnvs,
    },
    build: {
      globals: true
    },
  };
});

While I have access to the externalEnvs object in development, this variable creates an error while building:

If it's not possible to access env variables from Azure Static Web Apps configuration, is it possible to create a global variable in build? Is this a good alternative?

Thanks for the help

Reproduction

private repo

Steps to reproduce

No response

System Info

System:
    OS: macOS 13.4
    CPU: (8) arm64 Apple M1
    Memory: 33.36 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.15.1/bin/yarn
    npm: 9.4.1 - ~/.nvm/versions/node/v16.15.1/bin/npm
  Browsers:
    Chrome: 113.0.5672.126
    Safari: 16.5
  npmPackages:
    @vitejs/plugin-react: ^2.2.0 => 2.2.0 
    vite: ^3.2.4 => 3.2.5

Used Package Manager

yarn

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[itxtoledo]

I believe this should be the default behavior, taking all environment variables (from the environment itself and not from an .env file) that begin with VITE and inserting them into the code

[rbarisic-lme]

Is there any update on this? I updated our App from 2.x to 4.3.9 and now it doesn't seem to load the VITE_* variables into import.meta.env anymore

[markcouvaras]

Same issue here. Really annoying as this works perfectly fine in Vercel and Firebase but not for Azure Static Web Apps

[thomasgauvin]

Azure Static Web Apps App Settings represent runtime variables, accessible by the managed functions backends. Build time variables, such as the ones you are referring to, must be set in your build pipeline such as your GitHub Action

[StewartGF]

thanks Thomas, this was my solution🫂

[payetools]

For anyone looking how to implement this, see: https://learn.microsoft.com/en-gb/azure/static-web-apps/build-configuration?tabs=github-actions#environment-variables

[minhtranes]

Thank @thomasgauvin ,
And is it possible to change the variable value after creation by this way?

[sadranyi]

seems we have to deploy to app service instead

[Shyam-Chen]

// vite.config.ts
import envify from 'process-envify';

export default defineConfig({
  define: envify({
    FOO_BAR: process.env.FOO_BAR,
  }),
  // ...
});

// src/main.ts
const FOO_BAR = process.env.FOO_BAR;

[Mohit-cixcent]

is it working??

[TheEverestExperience]

Use case:

• App bundle will be built and it will be promoted to Container Registry. Bundle will not have statically expanded variables from VITE prefix environment variables .
• We can deploy the container on Kubernetes (K8s) and the environment variables on the K8s should be the dynamic runtime environment variables.

We tried digging into VITE. After endless a week of research we could not get it working.

Solution:
We ended up using react-env package.

https://github.com/andrewmclagan/react-env

1. Create a .env.config file in root and set as environment variable

//env.config
REACT_APP_BASE_URL = $ENV_BASE_URL
 // react-env expect has default prefix as REACT_APP and this can be changed
//ENV_BASE_URL is expected on process.env through kubernetes 

2. Use react-env to emit __ENV.js file and start app or docker(nginx) entry point

react-env --path env.config -- <start app or docker entry point>" 

//--dest option can be used this to output __ENV.js to specific directory

3. <script> reference __ENV.js in index.html

<script src="/public/__ENV.js" />

This gets away from statically expanded variables in which VITE_BASE_URL is replaced with the value.

Hope this helps. I am always eager to know if VITE has some provisioning around this.

[fu-mix]

I was able to solve the problem by adding the parameter "VITE_xxx_xxx" to the env section in the pipeline configuration as follows.

...

with:
  azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
  repo_token: ${{ secrets.GITHUB_TOKEN }}
  action: 'upload'
  app_location: 'src'
  api_location: 'api'
  output_location: 'public'
env: # Add environment variables here
  VITE_XX_XXX: xxxx
  

Refer to
https://learn.microsoft.com/en-us/azure/static-web-apps/build-configuration?tabs=github-actions#environment-variables

[wmrodrigo]

I was facing the same issue, and did the same approach, but I bind the value from Git Variables, that way you don't expose sensitive information. I'm using React+Vite, GitHub Actions and Azure SWA.
Also I have 3 environments (dev, stage, release) and I have all my env values on yml for each environment. So far so Good!

[armandasalmd]

Worked

[Salem-Abderaouf]

@Mattang-Romero what about caching this information in GitHub secrets
env:
VITE_XX: {{ secrets.XX }}

[pkaushik23]

@wmrodrigo thanks for the tip. one place where i was stuck for some time was that in my workflow i did not have a environment configured so the variable value was always blank as there was no source configured (the environment name)

[end-user]

Note, env is only an option in the build pipeline yaml. There's no way to set it in the release pipeline.