-
|
Hello everyone. My Problem:
Goal
Context What I am trying to achieve is that I can start a mife in standalone mode and then use a utility module in the mife running independently. In the standard mode of the Single-SPA, I can also obtain the module as normal via ImportMaps, but not in standalone mode. One circumstance that makes the whole thing even more difficult is that all applications are in their own repos, so there is no mono repo and it is also not an option to throw everything into a mono repo. Jose suggested writing a small plugin that provides a fake module or copies the utility module. However, I could imagine that copying would not work because the code base is not in a mono repo. Unless I have misunderstood something. Jose, could you perhaps explain in a little more detail what your two approaches would be. I have to admit that I have never written a plugin for vite before, so I have no idea what exactly I can achieve with it, or what is possible. Or maybe the possible options have changed since I shared the info about the missing possibility of a mono repo? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
Hello, @PDGallus. Indeed, what you describe is an "issue" I also have at work. In my case, and at least for now, I only need a configuration module that is only available from the root MFE. It is a super, mega simple export of a JS object, where the main property is the environment (possible values are So what do I have and what did I do? Let's see. What I haveAll non-root MFE's require this configuration file, so the appropriate configuration for each environment is used. I use the import wj-config from "wj-config";
import mainConfig from "@appDomain/client-env"; // <------ This is an alias registered in the root MFE's import map!
... // etc.Possible ScenariosThere are 3 scenarios to cover:
Deployed BuildThis is the easiest. In order to successfully bundle the project, we simply mark the // vite.config.js
export default defineConfig({
build: {
rollupOptions: {
external: ['@appDomain/client-env']
}
}
... // etc.
});What this does is tell rollup not to attempt to obtain that module's source code and merely leave the Development in single-spa ModeThis is everyone's favorite, and while it looks more like the deployed build, is actually almost identical to standalone mode. Even when running under a page provided by a root MFE, Vite, while in serve mode ( Standalone ModeThis scenario, for the purposes of your problem, is identical to the previous one. So what to do? Well, since Vite won't desist in trying to resolve the external modules, we are simply bound to provide them. How? With a very simple plug-in. Vite/rollup plug-ins are mere functions that return an object with functions, so you can write the plug-in even inside The Plug-InPlug-ins are usually written in the form of factory functions, so let's follow the pattern: // Export this function if you wrote it outside of vite.config.js.
function devPlugin() {
return {
name: 'devPlugin',
resolveId(source) {
if (source === '@appDomain/client-env') {
return source;
}
return null;
},
load(id) {
if (id === '@appDomain/client-env') {
return 'export default { environment: "Development" };';
}
}
};
}In all honesty, I think we can eliminate the Now, you say you need the real thing, not a fake. There is no choice: As seen in the sample above, you must have access to the source code so the What would I do? Well, Intel has several private NPM repositories. If I ever were in your position, I would set up a private NPM repository and create a package out of the utility module the root provides. This would mean I'd probably have a repository for the utility module, and would use that repository to produce the NPM package. This means that the root MFE would no longer contain the module's source code, and would instead use the NPM package as well. Going back to the plug-in solution with the NPM package in mind, you should at this point realize: I don't need the plug-in solution at all! You would just install the NPM package for the utility module just like you did in in the root MFE and problem solved, right? The answer is maybe. It would be yes if the NPM package's name were If you found the proposed solution of a private NPM package appealing, then simplify the plug-in above, not by removing This would be it: // Export this function if you wrote it outside of vite.config.js.
function devPlugin() {
return {
name: 'devPlugin',
resolveId(source) {
if (source === '@appDomain/client-env') {
return 'app-client-env';
}
return null;
}
};
} |
Beta Was this translation helpful? Give feedback.
-
|
@webJose you're awesome. Thank you very much for your time and effort. I will work through it and come back here and report how it goes. Have yourself a great time. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, I just remembered that you can do aliasing without plug-ins. See this piece of document. Maybe you can use it and not need the plug-in. It says, though that one must return full file paths. Unsure if that applies to NPM packages. There's an explicit mention of an |
Beta Was this translation helpful? Give feedback.
-
|
Hey @webJose! Cheers |
Beta Was this translation helpful? Give feedback.
Hello, @PDGallus. Indeed, what you describe is an "issue" I also have at work. In my case, and at least for now, I only need a configuration module that is only available from the root MFE. It is a super, mega simple export of a JS object, where the main property is the environment (possible values are
Development,Test,PreProductionandProduction).So what do I have and what did I do? Let's see.
What I have
All non-root MFE's require this configuration file, so the appropriate configuration for each environment is used. I use the
wj-configNPM package (also of my crafting) for configuration, and every non-root MFE has aconfig.jsfile similar to this: