Rsbuild Configuration

[00:00:00]
>> Steve Kinney: So let's look at some files. Like I said, we effectively have it in one repo for our own sanity. I could have launched this from two different repos. Again, as we said before, it doesn't matter if it's in one repo if you're going to deploy separately, two repos, but we can only deploy at the same time. These are all different flavors that you can mix and match. This is just in one because I don't know, it's a decision I made at the time.

[00:00:25]
It doesn't matter. So if we go into the host app—mostly because I didn't want to change the CSS across two is really the truth. I'm one person, leave me alone. So if we go to the host application, this is, you know, kind of defining its configuration at this point, right? This is using RS Build, but like I use Vite every day and that makes sense to me, right? Like it looks like most of the other configuration files.

[00:00:57]
So we pull in the React plugin, we pull in this plugin module federation. To be clear, you do not have to use RS Build. There is a module federation plugin for the build tool of your desires, right? There's like, I think last time we did it in Vite, now RS Build is more like Webpack but in Rust, right? None of this is any different, right? And this applies basically the same no matter what. There is a same way that like, yeah, it's a different download for a plugin for React for Vite versus a plugin for React for Webpack.

[00:01:31]
React is the same. So on and so forth. So we've got the name. In this case, I was very clever. I named it host, so I had to explain this in front of people, and then it has a manifest, almost like a package.json of the various different modules that it might pull in, you know, on that chart before we saw A, B, and C. Right now we've just got effectively A so that we can wrap our head around this. We will talk about this in a second.

[00:02:00]
We're not actually using this right now, so don't stress out about that. The important part is this, right, which is where to go find that. Now, again, this now tells us that if we go to import something from remote analytics, as I'll show you in a second, it knows to go to that, go look for the manifest to figure out what that means and resolve it. Again, not unlike a package.json, but with some nuances that we should call out, right, which is, for instance, localhost:3001 is fine for right now.

[00:02:34]
It's probably fine when I'm developing. You're going to have to do something. You know, whether it's an environment variable, an itinerary or some kind of function to then or environment variables that you're interpolating in there, that you're going to have to do it between staging and production and development and all of that will be unique to the like whatever setup you were handed by people who have long quit.

[00:03:01]
And so there are things you're going to have to navigate there and unfortunately, I'd love to give you a silver bullet, but it's some version of environment variables and interpolation or like some build time shenanigans that you decided you were really clever to pull off. The shared stuff is also kind of like those, what are the shared dependencies, right? And I will let you guess what singleton and eager means.

[00:03:24]
I will tell you in a second if you can't figure it out. I'm compelled to tell you now, but I wrote a lesson plan. I feel like I should stick to it. Yeah, I think it's an approach or a principle in software development where you have a function that addresses just one thing. Yep, yep, and so I mean, yeah, let's do it now then. How many React 18 is the right number of React 18 to load for one app? One, right, loading two does not do anything for you other than like slow your app down, right?

[00:04:05]
And so saying that like, hey, these all have this dependency on React is a shared dependency, please only load one version of React, right? As you can see I have basically applied that the whole way through, because somebody will likely have a use case where I don't want that on, but I, for most of these shared dependencies, I would like only one of them, please, right? The other one is eager, which is like, should it get loaded with the shell, right?

[00:04:43]
Do, you know, and like, for this case, like we know in this case that all of our pieces are going to use React, right? So like, go load React before you load anything, you know, along with the initial bundle, right? Pull in React. But if you went down that dangerous road of like, it's all React except for that thing over there, which is Backbone and Marionette, then obviously you would not eagerly load that, you'd wait till they get to the one page that is Backbone and Marionette, right?

[00:05:12]
And then you would like load it then, right? And so it's the idea of like, we know we're going to need it for everything, don't load some things, find out that you need it, and then go load it because now that's more hops than we needed. We could have just figured that all out to begin with, right, because this is the configuration for how we build the host app. So we're saying like, as part of this bundle, make sure we only ever get one React and include it in the bundle please, right?

[00:05:45]
Versus if everything was React and one Backbone Marionette page we'd be like put React in the bundle and we'll lazily load Marionette when we need it, you know, and then you've got the HTML file like again not dissimilar from a normal Webpack Vite, ES Build, configuration and nothing particularly like novel here. It's just configuration that, you know, you need to set up. Let's go look at the similar version of this in the—it just reminded me of one thing I should have also complained about earlier.

[00:06:22]
I'll talk about that in a second. Let's look at this in the remote, right, where I've named it remote analytics. Again, you might just call it dashboard, user profile, whatever the name of the thing the team works on is. I called it remote so that we didn't have to like remember which one was the host and which one was the remote in this case. That's not a convention you need to stick to. So this case it's like its own package.json.

[00:06:47]
And we're going to call this one remote analytics, and then this exposes is like what are the things that this thing exports, right? Like very similar to if you had an export statement in a JavaScript file or module.exports in CommonJS or the exports in a package.json, right? What are the things that this module makes available outside of itself, right? That way you can't go in there and find some weird slash source, you know, like you ever do that with like a node_modules slash whatever dependency slash source, you go way deep into a module that you have no business being in.

[00:07:24]
That stops you from doing that. And again has the same shared configuration. So now again, things to think about yourself is like how do I keep this all in sync? Good thoughts. When we were looking into module federation at my last job, we saw all this config stuff as additional boilerplate beyond what was already declared in our package.json and what JavaScript modules are already capable of. Your opinion?

[00:07:59]
Yeah, yeah, okay, so yes, so we went about solving the same kind of problem with a Vite plugin that looked for peer dependencies and built an import map. Yeah, there's a bunch of clever ways to this, but the issue is, yeah, you have to solve for it now. Like you've added complexity. So yeah, you can either, like we alluded to before, like, would you like for some of these, would use environment variables to change the source of the remote, so on and so forth.

[00:08:23]
Like you could do wild stuff like, you know what the crazy thing about a package.json file is? It's a JSON file, you know, you can do with a JSON file in like Vite and Bun, I think, I think actually built in Node, I can never remember like which ones come from a framework and which ones whatever, but you can import a JSON file. So you could literally like import your package.json, treat it as a JavaScript object, bend it a little bit, right, and like create, because, you know, this configuration we're passing to the plugin module federation is taking a JavaScript object, your package.json is a JavaScript object, and if there's one thing we're good at as front-end engineers is doing is taking some JavaScript-shaped object that we didn't want and bending it into the one we needed for the UI, right?

[00:09:13]
That is like our core skill set. There was one time during an incident where like the backend engineer was like, how did you like manipulate all that JSON that fast? I'm like, I've been training for 10 years for this moment, right? So yeah, you can pull all that stuff in, but your point is like now you have to. And if the juice is worth the squeeze, yes, great, because you solved a different set of problems.

[00:09:40]
Like, if the cost of doing this, all this configuration is less than like no one being able to deploy everything because the CI queue is backed up three weeks, then this is a good choice, you know what I mean? But if you don't have this problem, this is not a solution for you, you know, like. But yeah, you can see, honestly what we expose here, which again could be very similar to what in a package.json we might have the like, export, oh yeah, you gotta spell it right.

[00:10:04]
You know, something like what you might see if you were to publish an NPM module, you might write something like that, right? It's effectively the same basic idea.