This file defines LEARNING_BASE_URL with the value: http://localhost:2000
If the runtime MFE configuration is disabled, then due to mergeConfig, the MFE will fall back to using the value from .env.development. In this case, we won’t get a correct URL for the Learning MFE.
The Authoring MFE is just one example, every MFE includes a .env.development file, and most of them also use mergeConfig.
My main question is: Should MFEs actually rely on .env.development, and should they fully support scenarios where the runtime MFE configuration is disabled? And if, for any reason, a .env.development file is required, should it contain environment variables that match the current, correct configuration values?
Thanks in advance for any thoughts, and please feel free to correct me if I’m misunderstanding anything.
This has been the case historically. Because we don’t know how people use or develop MFEs in the wild, we can’t remove this without it going through the proper DEPR process.
That’s not to say that the answer is “yes”. I actually believe the opposite: .env files no longer exist in frontend-base apps, and what replaced them, site.config.dev.tsx files, have defaults that happen to match Tutor defaults.
Yes, default local development settings should support scenarios where runtime configuration doesn’t exist, and they should hopefully Just Work with the most common scenario. Which brings us to…
Yes, it should, though I’d hesitate to call the configuration “correct”. It’s more like it should match the popular or recommended configuration, which is currently Tutor.
Long story short, I would support PRs that change .env.development files to match the current recommended development environment. After all, we already started doing an equivalent thing in all package.json files.