feat: JavaScript-based environment configuration #200
Conversation
davidjoy
force-pushed
the
djoy/js_env_config
branch
from
bd48d34 to
e0d799e
Compare
|
Fully support this plan! One thing I want to call out to make sure we account for it is the multiple builds of the same app for the masters learner portal. A quick glance at the code makes it seem like this would be fine (the tubular would just create a separate env.config.js each time?), but throwing this out there just in case :) |
|
Cool, good call out. I think that's what it should do, yes. I fully expect to have to make modifications to tubular to get this working... Details are TBD, but I sort of envision adding env.config.js files to edx-internal's environment-specific subdirs and then modifying tubular to paste those into the repo before running |
davidjoy
force-pushed
the
djoy/js_env_config
branch
2 times, most recently
from
e8c0e84 to
12cf29e
Compare
| @@ -0,0 +1,45 @@ | |||
| # JavaScript-based environment configuration | |||
- Add an alias and fallback for "env.config" in the webpack.common.config.js file. - Put an empty fallback file in the config directory in case an MFE doesn't specify its own. The idea is that an MFE (or probably frontend-platform) can provide an env.config.js file which will be linked in if it exists. This is an alternative to .env files.
This commit also organizes the tests in the example app a bit.
Also cleaning up example app linting errors.
The jest config needs to have the same sort of fallback behavior that webpack uses. It doesn't use webpack itself, just babel.
If the "fallback" webpack resolve parameter is set to `false`, then it resolves the module with an empty object. This is perfect for us. It also lets us move our fallback file into the jest subdirectory, since we still need a physical file when jest gets run.
davidjoy
force-pushed
the
djoy/js_env_config
branch
from
12cf29e to
4f9283c
Compare
We don't actually need this file in order to run the build; it pulls it from the config directory on its own.
|
Looks good to me overall! Great job with the docs too. Only question is, will there be a follow up note/message regarding here is how you take advantage of this new system, once this frontend-build is released? Maybe reading the doc is sufficient but just curious what your plans were |
|
Basically, you can't really take advantage of it properly until the follow up work in frontend-platform/tubular is done. That's what this paragraph is trying to convey: https://github.com/edx/frontend-build/pull/200/files#diff-03e6c18bd68df4f3883b33c3b5b68564e2e956efc614f7d2ace7be49956b79fcR45 Regardless, I'll clarify above in this PR, too. Thanks for the review! |
davidjoy
force-pushed
the
djoy/js_env_config
branch
from
1d03adf to
7da5144
Compare
Making the variable name match the element it's being applied to.
davidjoy
force-pushed
the
djoy/js_env_config
branch
from
7da5144 to
8d40191
Compare
|
🎉 This PR is included in version 8.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This adds a fairly simple mechanism to the webpack config that resolves a package named
env.configto a localenv.config.jsfile in the app. If such a file doesn't exit, it falls back to an emptyenv.config.jsfile in frontend-build so that webpack doesn't break.This is the groundwork required for us to use JS-based environment configuration. This would have numerous benefits, most importantly, letting us use non-string values in our config (like booleans and numbers) as well as importing other resources to be used as config, such as alternate implementations of services in frontend-platform.
Note: The code in this PR makes it technically possible for us to optionally import such a file, but the mechanism isn't really useful yet because it requires support in both frontend-platform and our build processes. Stay tuned.