Sometimes modules can end up in your client bundle when you don't want them to.

For example, the Zod library isn't needed by the client so there's no reason to ship it.

There are a couple of ways to find out if you're including unnecessary modules in your bundle.

, which generates a visual representation of your build's source maps.

In this case, we can see that Zod is present in the bundle:

This tool gets the job done, but there's a quicker alternative without going through as much trouble.

 statement to the specific module you're interested in will let you know if it ends up in the client-side bundle.

Since I'm interested in Zod, I'll open its 

Remix and most other bundlers reference this file when building the production application, which is often in the 

At the top of the file, add a long `console.log` that will be noticeable in the console:

To check your work, trigger a rebuild by saving any file in your project.

When you check the console in your browser, if you see your console log, you know that the module has been included in your client-side bundle.

 in the module while you work on configuration or other things. When the output is gone, you know the module isn't being included (at least for the page you're currently working on).

 to confirm that the module is no longer present.

This is a nice quick and easy way to make sure something isn't showing up in your client-side bundle if you don't want it to!

There's a faster alternative to using source-map-explorer to examine your client bundle for unwanted modules.

Quickly Determine Whether a Module is Bundled

Instructor: [0:00] You might know that one of the best ways to find out whether a JavaScript module is showing up in your client bundle is by using source-map-explorer.

[0:08] You generate your build with source maps. Then you pass source-map-explorer to that source map, and then will tell you in a fancy chart like this what is in that source map.

[0:22] Here, we see that we've got zod in there, and that's the thing in particular that I'm worried about showing up in my client bundle.

[0:30] However, if you don't want to go through the trouble of that, you can actually really quickly determine whether a particular module is showing up in your client bundle by just changing that module.

[0:40] We're going to go to our node modules. We'll search through those. I'm going to look at zod, and I will go to the package.json, where we will look for a module property. This is what's going to be built, at least in a Remix application.

[0:54] Most bundlers these days will reference the module property for the client-side bundle. It will reference that file when building for the production application. We're just going to go into lib index.mjs, and at the very top we'll console.log zod.mjs.

[1:18] When my editor finally lets me save, [laughs] then we can go back here, hit save in here to trigger a rebuild. Then we can come over here and we see, "Oh, there's zod right there." We know for sure that this file is showing up in our client-side bundle.

[1:35] We can leave that console log in there and do whatever work we need to to move things around so that it doesn't show up in the client-side bundle anymore. When that console log doesn't show up anymore, you know it's gone, at least from this page.

[1:47] When you're done working through that, you can come back to source-map-explorer to be sure that it doesn't show up in this chart. This is a really nice quick and easy and fast way to make sure that something is not showing up in your client-side bundle if you don't want it to.

Whenever you run into a situation where you're having trouble seeing live updates when making changes, I find it best to try to reproduce the problem in a completely separate environment.

Here's a process you can follow to isolate these types of problems in your own project.

 directory in your project. Check that your 

 in the name. You don't want this test code ending up in your repo!

Next, create the minimum number of files you need in order to recreate the problem.

The idea is that you want to have enough code to recreate your problem without being overwhelmed by all of the other parts of your project.

Now you can start experimenting and testing potential solutions. This might involve running tests using a watcher for changes, or creating new components.

Once you've found the solution in your test code, bring it back over to your main application code.

After you've verified that your problem is solved in the main app, you're safe to delete your test directory.

Isolating your problem to a small example in a temporary directory is a great way to solve complex problems!

In this example, I have a complicated setup involving adding interactive components to an MDX file that is being treated as plain markdown.

 directory will be a minimal set of files to reproduce the problem I was seeing in the full project.

Since I'm working with MDX, I'll create a 

  file will import React and export a simple 

 component to act as a stand-in for the more complex component that would be used in the real project.

 file, import the necessary modules and bundle the MDX:

On the command line, I'll run the command 

 and check the output. If the MDX is not processed correctly, make changes to the configuration options.

By creating a smaller example with less moving pieces, I was able to track down the configuration issues with my MDX processing.

The next time you run into a problem and you have no idea what could be causing it, try moving to a separate environment and slowly add files until you've reproduced the issue.

With fewer moving parts, you can more easily identify and resolve issues much faster than in the complexity of your full project.

When faced with a complex problem, try isolating it by creating a minimal example in a temporary project directory.

Use Isolation to Solve Complex Problems

[0:00] I've got a Markdown file here that I want to treat as MDX so I can have interactive counter components or whatever other components that I want in the instructions for the workshops. As you can see here, that's not being processed as MDX.

[0:16] This is just being treated as Markdown, and if you dive through this, you can see where that is being treated as just like a regular string, rather than being treated as MDX, which I want it to be. I've got this whole, big setup here and this compile-mdx.server with a bunch of plugins and all of this stuff, even caches and stuff.

[0:37] It's really difficult to work in this. Whenever you run into a situation where it's difficult to make changes and see your changes live and everything, I find it's always best to try and reproduce the problem that you're having in a completely separate environment, and then you have fewer moving parts.

[0:58] What we're going to do is, I'm going to come down here. We're going to make a new directory called test.ignored. That's my global gitignore, just ignores everything that has a .ignore in the file name. Inside of this, we're going to make a test.ts, and we're going to also make whatever else we need.

[1:18] In my case, I need a README.md and also, let's see, a component.tsx. I'm going to make a counter component to export that. We'll import React and then in my README, I'm going to import the Counter from the component, and we'll say this is my counter, Counter. All right, great.

[1:53] That should work with what I'm trying to do, and then we'll make our test. We'll say import path from 'path' and bundleMdx. No, that's not it. mdx-bundler, and we'll make a function, because I can't use top-level await because these aren't native ESM. If it was native ESM, you don't need to make this go function. You just do await at the root.

[2:25] Now, I can say bundleMdx. I think bundleMDX in [laughs] all caps, and we'll say file: path.join and I'm going to say _dirname. That will go right there, _dirname. We're actually going to be processing the README.md.

[2:49] You take as few of the pieces of your actual code as possible to reproduce the problem. You narrow the problem down as much as possible. We'll get our result from that await, and then we'll console.log the result.code.

[3:06] You know what, another thing that we'll do is in here, we'll make it obvious when it has been processed properly by adding a bunch of exclamation points. Now, we're going to run tsx watch ./test.ignored/test.ts. Let's move this out of the way and take a look at what we've got here.

[3:32] Expected value for process.env. That's interesting. I could rerun the script with setting the app, but we'll say process.env. NODE_ENV= 'development,' which is what I'm running when I'm running my server.

[3:47] That's kind of weird that it requires that, but that's OK, because I add that additional aspect to my actual environment until I get to the point where I'm reproducing the problem. I am reproducing the problem.

[4:00] You don't see any all caps exclamation points, and in fact, there's the import right there. [laughs] This is not great. Now, we can go through docs and different configuration options, and I'm going to skip all that because I actually did that already.

[4:19] The thing that's going to fix this for us is there's this mdxOptions (options) with mdx-bundler, and options.mdxExtensions. We need to treat our Markdown files as MDX. Actually, one other thing that we could do before we get to this is, let's test a theory that if this were an MDX file, that it would be treated as such. Boom, there it is.

[4:47] All we need to do is tell our mdx-bundler or MDX that we need to treat .md files as .mdx files. Now we can switch this back to an .md. We switch this to .md. Of course, we need to return the options there. Oh no, it's still not giving us all those exclamation points in here.

[5:12] The other thing that we need to add is options.format, and we're going to force it to say, "Hey, I want the format of this thing to be MDX." That's going to force it, and now we are solid.

[5:25] Then the other thing that actually bothered me is I saw this fileName stuff in here. In production mode, that is all going to get removed, because these are debugging helpers and stuff. For my use case, I actually don't want that, and so I also am going to add development is false, and I can very quickly see, those are all gone.

[5:50] I'm able to take this now over to my actual source code and add the pieces that were just the couple of lines that make all of the difference, and now I can come over to my running app, and indeed, it does run, and I can tab over to the button and, boom, boom, boom, boom, boom, boom. The button is totally working, so huzzah.

[6:11] Next time you run into something that is there's so many moving pieces you have no idea what could be causing the problem, try to move to a separate environment and slowly add, add, add until you've reproduced the problem, and then you can work within that environment. It's way, way faster.

[6:28] I hope that helps. Have an awesome day.

If you're not sure if the right font is being applied to your app, here's an easy way to check.

1. With the help of DevTools, inspect the element where the font should be applied.

 configuration and copy the font you want to use.

3. Create a temporary style element and paste the 

4. Modify the font name slightly to see if the font changes when applied to the element.

If it doesn't change, it means the custom font is not loading properly. You can quickly check the "Network" tab and see that the font file is not loading.

To fix this, you can investigate if there are any typos in the font name or other configuration issues.

To confirm that the correct font is being applied, toggle back and forth between the font you want to use and another font. If the font changes when you toggle, then it's working properly.

This technique can help you quickly identify and fix any issues related to loading and applying custom fonts in your app.


Learn how to use DevTools to check if the correct font is being applied to your app and troubleshoot issues related to loading custom fonts.

Check if Custom Fonts are Properly Loaded in Your App

[0:00] Sometimes, the font that you're using doesn't look a whole lot different from the regular font, and so you're not sure whether you're actually loading the fonts that you're supposed to be. For example, I've got a font that I want to have applied to my app. I'm pretty sure that it's not applying, but I'm not positive. To find out, I'm going to select this Starport element, and then I'm going to go to "font family."

[0:24] Here's the configuration for my font family that I've got here, so I'm going to copy this. I'm going to stick it up here in the style element, and then all I need to do is make a change to this. If I remove the "s," then it should actually change the font, because I just changed what that font is. It didn't change. It looks exactly the same either way, so we know that this font is not loaded.

[0:48] We can actually look at that and see the font file itself is not loading properly, but this is an easy fix. We just remove the "n," and now we get a refresh. Now, I'm still not sure. Is that the right font, or is that the old thing? We're going to paste in our fonts here again, and come over here and just change it back and forth. You can see, boom, that is definitely loading the proper font.

[1:16] If you're ever not certain whether the right font is being applied, or something, then you can simply set the font family to what you want it to be, and then toggle back and forth between that being enabled and that not being enabled. You should see that the font should change. If it's not changing, then you've either got a typo in the font name, or something else is misconfigured in your app. There you go. I hope that's helpful.

Tips

Quickly Determine Whether a Module is Bundled

Use Isolation to Solve Complex Problems

Check if Custom Fonts are Properly Loaded in Your App