Source Maps

[00:00:00]
>> Sean Larkin: So the last piece that I think is valuable to talk about is really gonna be about source maps. It comes up a lot in question. There are a variety of different ways that you can generate source maps, or I guess I should say a variety of different formats.

[00:00:17]
And they all have trade-offs, like everything in programming. And so really I just wanna go to our docs. So for any config property, you can actually go to webpack.js.org/configuration. And you can even go to the base property name. So in this case like devtool, which is the property we'll be going to.

[00:00:37]
There's even an interactive explorer to see, what are all the different possibilities that you can add, and what do they do, for the most part. And you can always contribute by going to Edit Document. Anyways, so we're gonna go to devtool. So devtool is the property responsible for creating source maps.

[00:00:58]
Now you'll notice here that we have this little table that talks about all the different qualities of what the source maps produce. So and there's a small key here. The plus symbols mean better or faster, and then the minuses mean slower, I guess you can say. So, or kind of a mediumish, at least that's what it says here, medium, pretty slow, and slow.

[00:01:33]
So the point being is that you can make trade-offs on how long your builds take, depending on the quality of your source maps, and vice versa. So if you wanted the most beautiful looking original breakpoints and everything works in whatever browser you're working in, source map is the property [COUGH].

[00:01:54]
And so if you wanted to jump into your config and we wanna create an add source-map support, you can go into your production configuration, and just add the devtool property and supply that string, source-map. Oops, I forgot the env flag, env.presets compress. There we go. So we shall build.

[00:02:22]
And now when we look, we're actually gonna see we've had source maps generated not only for our CSS, but also for our JavaScript. And now, if we wanted to kind of live demo what these source maps look like, we could override the devtool property in our development config.

[00:02:42]
So let's say we just went over to our dev config. So I just want to show you for the case. I won't check in having it added for the development, because you want fast dev builds, right? And so we can go to the dev config and do the same thing.

[00:02:58]
So devtool and say source-map, not source-nap. I might need a source-nap after I eat that Nutella donut. That thing is good. Okay, and we'll just switch this over to instead be yarn dev.
>> Sean Larkin: Oops. I know what I did. Hoist the devtool up to the top level, not inside a module.

[00:03:30]
>> Sean Larkin: Okay, so we can check out our production environment, or I guess our dev server. So great, if we inspect this now, and hey, I like that font, nice font. Good job with the fantasy font. So if we look in our devtools and we actually wanna look at sources, we get the full source mapping, so much that we can even look at the individual files.

[00:04:02]
So you'll notice this little sidebar feature that says webpack. And you go down to the period, and you can even see your entire project structure if you want. So let's say I went to Image, and look, there's our code as is. So much that we could even set a breakpoint and reload, and it stops there, we can see the URL.

[00:04:27]
We can do debug-driven development, which is my absolute favorite.
>> Sean Larkin: Let's see.
>> Sean Larkin: Yeah.
>> Sean Larkin: And so this gives you the most accurate source maps. But why don't we play with another quality and see what we're kind of sacrificing for the speed, right? So If we went over to the, so we go back to that .js.org/devtool and we look here.

[00:05:00]
So we have, why don't we choose cheap-module-source-map. So this is the one I think by default is used in Create React App, for example. It's kind of like a medium trade-off. And so we could put that string in here. Let's see what it creates now if we run the command again.

[00:05:24]
>> Sean Larkin: All right, back to our server.
>> Sean Larkin: Okay, so we still get accurate line markings, but I wonder if we look at the bundle itself. Now the bundle is kinda transforming some of the module code, and so it's a little less accurate. On some browsers you might not get the full source map breaking that you're looking for.

[00:05:50]
And so that's kinda some of the trade-offs that you see there. And hey, you can even see now there's webpack dev server hot module replacement code that's in here as well. So that's the kind of client code that gets inlined when you're using dev server with the hot flag.

[00:06:08]
>> Sean Larkin: But yeah, really, let's look at the photo.css.
>> Sean Larkin: So here's an example of where you don't get the true, or it's not always perfect.
>> Sean Larkin: But that's what we're trading off to have better builds, or better speeded builds. So one could even say, well, when would this be valuable, to have a one-off kind of ad hoc opportunity to see a different source map?

[00:06:42]
That would be another example where you'd maybe wanna add something, add a special source map for a preset. And you could add it just if you're debugging, then you could just add it through an EMD flag. Does anybody have questions about source maps? I can kind of explain what the other properties do.

[00:07:05]
There is, I don't know where I keep losing that tab. There it is. So you might wonder, what are these ones down here? Inline.source.map will actually inline the entire source map in the module itself. So you'll notice your bundles are gonna get really huge looking. And that's why we say don't use in production, no.

[00:07:28]
And then there's some other ones like hidden-source-map, which has the original source and you can use it. It doesn't expose some of the mapping and directory information. So it's not available but you still get the source map quality. And then one, I think this is kind of cool, which is the nosources.source.map.

[00:07:50]
So what this does actually is if you don't wanna, I know some people out there think, we should obfuscate our source, but really you're shipping assets that are public to a website. So no matter what, people can see it. I think it's valuable, though, that you could hide the source, but it still maps your stack traces.

[00:08:14]
So you could still see the path to where an error occurs in your stack trace, and it maps back to that. So that's another case. If you're in a super enterprise-y land where your boss gets to call all the shots and doesn't really know that all the sources are always exposed anyways, you may be like, okay, we'll hide the source, but we get the stack traces.

[00:08:37]
And then, you can use nosource as source map, so, and then use a preset locally. And then all the way down to eval, which is what we use in the development mode by default. Super fast rebuilds, super fast initial build, and you don't use it in production cuz it wraps everything in eval strings.

[00:08:56]
Which means your bundles are gonna get really big. And eval completely de-ops your JavaScript performance, and there's lots of security issues with that as well. So yeah, that's really source mapping in a nutshell and we even kind of talk about this. What's quality? What do these qualities mean?

[00:09:15]
What do you recommend for a development environment? Special cases, like you can choose to not have column mappings versus the same thing but with the data URI in the bundle. We try to be pretty explicit here, don't use this when, or you should have your server disallow access for source maps to non-internal cases or not for normal users, I guess.

[00:09:46]
And so I would take a look if you're ever curious about source maps, or really any configuration property, there's so many. Like I said, we could spend an entire week, maybe more than a week, just covering each of the cases. But they really are case by case.