Web Performance with Webpack

Introducing Magic Comments

Sean Larkin

Sean Larkin

Web Performance with Webpack

Check out a free preview of the full Web Performance with Webpack course

The "Introducing Magic Comments" Lesson is part of the full, Web Performance with Webpack course featured in this preview video. Here's what you'd learn in this lesson:

Sean discusses magic comments, which is a process for naming the chunks corresponding to the modules/components being imported.


Transcript from the "Introducing Magic Comments" Lesson

>> Sean Larkin: So now let's talk about magic comments. So magic comments is, when we talk about magic comments, it's specifically for the dynamic import statement. So I actually wanna pull up the documentation because I think it's really well written in terms of what it is going to explain to you.

So if you went to, and if you wanna bookmark this, I would encourage it, it's a great resource. So we go to I believe documentation and then guides. No, I'm sorry, API and then module methods. So this actually shows you all of the module methods we support. Right, so not only just export, there's a common js, we even show the AMD ones.

>> Sean Larkin: Everything, which is really cool. Even the proprietary ones that are webpack-y. You can choose to use, there's even some for server side rendering. I don't think we'll have time to talk about server side rendering stuff. But this feature literally was designed for server side rendering and code splitting.

But anyways, let's jump to magic comments, I think, [LAUGH] where do we have it, okay, here we go, so.
>> Sean Larkin: One of the things that you'll notice is that when we use code splitting as a technique, there is no name that is created when you add the bundle, right?

Because it's not an entry point, so we can't give it some assigned name. And therefore, we used to be able to do this with require.ensure. And people really liked it because when you have, let's say, in our code base we have, now, if we run a prod build,

>> Sean Larkin: Prod, if we look at our folder here, we're gonna notice that we have like a whole bunch of files that, you're like, well, what's what, what is which feature? It's a little harder to debug, and so it's not as friendly for debugging and developer experience, right? And we also wanted to have a little bit more control over how we code split.

And so we added this feature called magic comments. And simply what it is is adding a comment before the path to the module that you're dynamically importing. So as seen here,
>> Sean Larkin: And you can add additional features specific to what the bundle is or what modules get thrown into what bundle.

Now, the one that's really popular is the webpackChunkName. So this is really great if you wanna be able to name or label one of these lazy loaded bundles. So why don't we go and just add this to one of our dynamic imports. So we know that we getFooter equals a function that returns a dynamic import.

And we can add,
>> Sean Larkin: A comment here in kind of the JS doc style, webpackChunkName. And I don't think we wrap it in quotes, right, no, we only do it for the second piece. And I would say, footer, right, so this is gonna allow wepback to have some sort of heuristic that doesn't conflict with the dynamic loader spec or the WG loader spec.

We aim to allow you to still have the features that you would get from require ensure, but not break people's code and make it not standard approved, right? So that's why they're comments, and so it's kind of a trade off and the decision that we had to make.

And so let's build our production build. So to allow this to be visible, we do have to make a slight configuration change. At least as far as I know, unless this feature is broken. So you'll be like, Sean, how come you don't know this? And it's typically, I don't use this feature a lot myself, other people find it incredibly valuable.

So we would want to say output.chunkfilename. And I believe we'd wanna set name, so I actually use a special pattern. So when you wanna have a naming pattern for your lazy loaded chunks. What we did for Mutual of Omaha is that I actually decorate them as lazy-chunk.js. And that way I know, when I look at any production code, I'm like, this is lazy loaded bundle.

I believe we can add the name helper template.
>> Sean Larkin: There we go, so now we have footer.lazyjunk.js
>> Sean Larkin: And if you didn't want to, like let's say you're like, okay, I kind of value this all the time, then you could keep it in your base configuration. Some people choose, I think, who was it, I think it was housing.

It was one of those where they only did this for production because it's easier, i'm sorry, only did this for development. But that's exactly how you would use the magic comments there. webpackChunkName, there we go, I'll make this even larger, there we go, ginormous, and I'll jump back to it.

Yes, so since webpack 2.6, we've had this feature.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now