Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Webpack bundles the context based on its given entry point. Works perfectly as expected.
If the current behavior is a bug, please provide the steps to reproduce.
What is the expected behavior?
If this is a feature request, what is motivation or use case for changing the behavior?
I am working on architecture at scale, where micro Frontend verticals (stand-alone web apps) can build and deploy a specific user flow.
The challenge comes in when I want to create an orchestration layer. The idea is that independent services can build their own Frontend. But when on the client, the application, which is made of many smaller builds, can act as one and Universally load code.
I know there are ways to fiddle around with webpackJsonp but looking for the correct way. How can I smoothly merge two separate webpack asset manifests to allow a large application consisting of 70 micro Frontends to act as one on the client?
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
As of now, I’ve done really crummy solutions like NPM installing a bunch of packages into a layout engine, then using common patterns, point the user to the static entry point. The issue is. React apps don’t behave as you expect because when going from one micro frontend to another, there’s usually a reload of the page as the next entry point is needed.
What I’m looking for is a way to code split and share across builds without relying on externals. I want to require code that would exist in another build and dynamically load it as if it were bundled under the same Singleton build.
Right now, think of Frontend as a monolith, if I want to code split pages. I must bundle them under the same single build.
However, in my case, I would like each microservice to build its own front and then have a layout engine of some sort which can concatenate only the manifests and deliver webpackJsonp an array that would theoretically contain modules from multiple other builds. Therefore when requiring a module from building number 7, webpack knows how to dynamically load it as if it were all done under one build. Right now it’s a guessworks and lots of manual labor, but how could I join many builds manifests so that the client would not know that one module came from another code split build rather than its own parent build.
While I do understand that there are hacks such as externals, it does seem like more effort than one would expect. My goal here is that some kind of layout engine could inject multiple manifests. Which allow webpack to treat various builds as if it were one single build on the client side. This allows for scale and ease of dependency management.
I’ve been doing this in a basic manner. I have been able to implement things like scout files which attempt to fetch the entry points ahead of time, but it’s complex.
I am more than willing to climb in and contribute to webpack. My co-author wrote require.resolveWeak for webpack, so we have had some exposure and would be willing to collaborate with webpack team again if this feature is not achievable. It’s the finale blocker on true standalone systems that can operate together as in-app one the client.
Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Webpack bundles the context based on its given entry point. Works perfectly as expected.
If the current behavior is a bug, please provide the steps to reproduce.
What is the expected behavior?
If this is a feature request, what is motivation or use case for changing the behavior?
I am working on architecture at scale, where micro Frontend verticals (stand-alone web apps) can build and deploy a specific user flow.
The challenge comes in when I want to create an orchestration layer. The idea is that independent services can build their own Frontend. But when on the client, the application, which is made of many smaller builds, can act as one and Universally load code.
I know there are ways to fiddle around with webpackJsonp but looking for the correct way. How can I smoothly merge two separate webpack asset manifests to allow a large application consisting of 70 micro Frontends to act as one on the client?
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
As of now, I’ve done really crummy solutions like NPM installing a bunch of packages into a layout engine, then using common patterns, point the user to the static entry point. The issue is. React apps don’t behave as you expect because when going from one micro frontend to another, there’s usually a reload of the page as the next entry point is needed.
What I’m looking for is a way to code split and share across builds without relying on externals. I want to require code that would exist in another build and dynamically load it as if it were bundled under the same Singleton build.
Right now, think of Frontend as a monolith, if I want to code split pages. I must bundle them under the same single build.
However, in my case, I would like each microservice to build its own front and then have a layout engine of some sort which can concatenate only the manifests and deliver webpackJsonp an array that would theoretically contain modules from multiple other builds. Therefore when requiring a module from building number 7, webpack knows how to dynamically load it as if it were all done under one build. Right now it’s a guessworks and lots of manual labor, but how could I join many builds manifests so that the client would not know that one module came from another code split build rather than its own parent build.
While I do understand that there are hacks such as externals, it does seem like more effort than one would expect. My goal here is that some kind of layout engine could inject multiple manifests. Which allow webpack to treat various builds as if it were one single build on the client side. This allows for scale and ease of dependency management.
I’ve been doing this in a basic manner. I have been able to implement things like scout files which attempt to fetch the entry points ahead of time, but it’s complex.
I am more than willing to climb in and contribute to webpack. My co-author wrote require.resolveWeak for webpack, so we have had some exposure and would be willing to collaborate with webpack team again if this feature is not achievable. It’s the finale blocker on true standalone systems that can operate together as in-app one the client.