fix: env refactor for Vite wrap-up [LIBS-690] #889
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dhis2-bot
added a commit
that referenced
this pull request
Oct 30, 2024
# [12.0.0-alpha.21](v12.0.0-alpha.20...v12.0.0-alpha.21) (2024-10-30) ### Bug Fixes * env refactor for Vite wrap-up [LIBS-690] ([#889](#889)) ([84da4e6](84da4e6))
|
🎉 This PR is included in version 12.0.0-alpha.21 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of LIBS-690
process.envvs.import.meta.envVite adds environment variables to the
import.meta.envnamespace by default. My plan was to make this the standard for the platform, too, because I thought this was a standard format that goes along with ES Modules. It turns out that it’s not standard, actually; it’s a pattern specific to Vite. Other build tools tend to useprocess.envas the default.I've noticed that there are some other tools and packages out there that depend on configuration variables that are set on
process.env, so dropping support for it entirely in favor ofimport.meta.envmay be a bit weird.This makes me think we should continue adding env vars to
process.env, since it’s a little more generic, instead of migrating entirely toimport.meta.envas the main env var namespace for the platform.We can still deprecate the
REACT_APP_-prefixed variable names, i.e.process.env.REACT_APP_DHIS2_APP_VERSION=>process.env.DHIS2_APP_VERSION. We can handle it in the same way we planned to handle moving toimport.meta.envi.e., have both variable names available in v12, then remove theREACT_APP_versions in v13.If we do, I’m not sure how much attention to give
import.meta.env— Right now, Vite is configured to filter the env for values starting with “DHIS2_” and add them toimport.meta.env. It seems that only values onimport.meta.envcan be used in HTML files, like%DHIS2_APP_NAME%inindex.html. I propose we kinda keepimport.meta.envas-is; some people may want to use it, and it doesn't really hurt to add theDHIS2_prefixed env vars onto it.Other env vars
I made some other changes to make the env var objects more concise:
undefinedvaluesundefinedvalues from the envI tested these out by starting and building both the simple-app and pwa-app examples to make sure they work with and without env vars. I also inspected the SW's caching behavior in the PWA app, and it looks good.
Examples
Before:
After: