- Hi everyone, my name is Ryan H Lewis. And today we're gonna look at
the newest version of Webpack, that's Webpack version five. I'm gonna go over the five biggest changes that I've found. We'll talk about how to migrate and then I'll share my
experiences migrating one of my projects from
Webpack version four to Webpack version five. All right, so Webpack version five brings a ton of new features,
changes, deprecations, all sorts of things. The release article was 10,000 words. I did not read the whole thing, and I almost wouldn't
expect you to either, unless maybe you are a plugin
author or a loader author or someone else who is doing some very, very deep things with Webpack. I think if you're a regular user, I think you can probably get the hits. This video is gonna be a
good step in that direction, but you know, looking at the article and reading some of the
top level major changes, is a good idea. It's been two years, it's
been more than two years. So February, 2018 is when
Webpack version four came out and now we're at November. Well, Webpack version
five came out last month. So Webpack version five
came out October, 2020. So that's over two years that Webpack was making adding
new features, making changes, putting warnings behind
soon to be deprecated parts of Webpack. And then finally Webpack
version five was launched. And so there's a lot in there. Webpack is a very active
open source project. And so there's just a ton 10,000 words. Good luck if you try to read it, but in this video we're gonna
break down the top five. So let's look at the
top five major changes that I found while I was
reading the documentation and trying things out. The first big change in
Webpack version five, is that anything that was deprecated, anything that was warned
that it was being deprecated in version four has actually been removed, which means that if you were
getting deprecation warnings and either you didn't see
them because of some setting in your configuration
file, or because the... You know, you just ignored them or maybe it was running on your CI server and you never saw them to begin with, well, then you are going to
have a very rude awakening when you come to version five, because all of those
things that still worked, but were deprecated in version four, are completely removed in version five and your build is just
gonna completely break. So there is a trace deprecation
flag that you can add to your Webpack builds
which will actually give you the information on what is
actually being deprecated and in which plugin or loader the deprecation is taking place. So if you are trying to do your upgrade and migrate to version five, you can use that trace deprecation flag to really find out what
is actually deprecated, 'cause you know what the
Webpack output looks like. It looks like insanity. The second big change
in Webpack version five, is that a lot of the
functionality of some plugins and loaders have been
rolled into Webpack core. And so in Webpack version four, they did this with a lot of
the optimization plugins. And in Webpack version five,
they did the same thing. Basically, I'm thinking that
the thought process behind this is that there were plugins that really kind of everyone was using, and they just felt like it made more sense to roll it into the core framework. They're probably able to
make some optimizations with those plugins as well, that when it was kind of
like an external plugin, they weren't necessarily able to. Some examples are... Let me look. NamedModulesPlugin, NamedChunksPlugin, and HashedModulesPlugin
to name a few things that I don't think I've
used those plugins before. But if you have now, you will use them. They are configuration
properties instead of plugins that you have to install separately. The third big change in
Webpack version five, is that node polyfills
are no longer included. What's a node polyfill? Well, if you know what a polyfill is, you probably have heard it
in reference to the browser because polyfills were popular. I don't know maybe five or six years ago to polyfill and JavaScript features that we're not in older
versions of Internet Explorer. The polyfills that we're
talking about here in Webpack are basically polyfills for
the node common modules, node core library that
doesn't exist in the browser. And so these Webpack polyfills
enable you to use things that are in node like... Some of the things that were
removed are the process object and the buffer object. Both of those were removed
in Webpack version five. Previously, there was a Webpack
polyfill that basically, if someone was calling one of those things and either your own code or
in a dependency NPM module that you were using, it
would use that polyfill. But because basically they
said at this point most modules are built for the browser, they don't use those things anymore. They basically found that it
was easier to remove them, reduce the code base and things like that. When they had them in there it's because a lot of NPM modules were actually not for the browser yet because when NPM originally
was really used for node. And so, now that NPM is
kind of used for JavaScript as a whole, they don't need
to do these node polyfills because a lot of modules
don't expect them anymore. The fourth big change
in Webpack version five is actually a bunch of tiny changes. Think death by a thousand cuts. The configuration, which
you're all well aware of if you're using Webpack,
that Webpack.config.jS file that you build and maintain
and change maybe once every couple of years, whenever you're upgrading
your version of Webpack, there are over 100 new
or changes to properties in that Webpack configuration file. And I will not name them all here. Probably if you use
all 100 of these things or plan to use all 100 of these things, I feel like you deserve a medal. There's a ton in there. When I was looking through
there were a few things that I recognize that I've used before, but honestly, there was a ton of stuff that I've just never seen, never touched, probably never will touch. In addition to new either like
change names to properties or new properties or new
kind of handling a property where maybe before it was a
string, now it's an object. There's also new defaults. So these properties that you
may not be actually using, before they had one default behavior, now they have another default behavior. And so usually what
I've seen is it's stuff that is not kind of on
the main path of Webpack, but if you're interested and
you have a lazy Saturday time to crunch this 10,000 word article, you can look through and
just see if it's anything that you may be interested in. The fifth big change to
Webpack version five, is that it requires node version 10. So although this is not a huge change to the Webpack user experience, this is one of those things
just from my experience, working on teams that
will probably require you to make some changes. The reason why is that a lot
of times that I have been running these continuous
integration servers that actually run Webpack
in the cloud or you know, on some third-party servers to be able to kind of build my application. A lot of times the node version
on that server or you know, whatever it is instance,
is really out of date. It doesn't get updated like the
node version on my computer. Usually node version on
my computer is whatever the most current LTS version is, just 'cause I love to
check out the new features. If the current LTS is too
far from like the application that I'm working on and
whatever the node version is on the servers in the cloud,
that application is running on, well, then I'll usually kind of stick my node version to that. I use NVM so I can switch
node versions really easily, but I'll set that as my default. But if I'm running a Webpack
in something like CircleCI or code build and AWS,
well then the node version that's running in there
is probably gonna be old, or at least it will... I will try to match it to the application. Now let's say you are like
probably most people out there and you haven't had time
or your project manager or your product manager
hasn't given you permission to take the time to actually
upgrade the node version for that application, or
you're just a little afraid to, which I don't blame you, then you may find that what's
running on your CI server is something like node
version six or version eight. And so now that Webpack five
is requiring node version 10, which granted is not even the current... Like node version 14 is
the current LTS version. So this is a couple of years old, but I wouldn't be surprised
if a lot of people are gonna find roadblocks to upgrading to Webpack version five with
this node version requirement. Now, I think it's a great
idea that they did this. I'm a little surprised they
didn't go pass version 10, but I just be aware that's a big change and it makes it, you know, potentially more difficult
to use Webpack in this case, but something I support. All right, so I wanted to go
over the upgrades process, the migration process from
version four to version five. Hopefully, you're already on version four and you're not moving from three to five because version four had a
lot more breaking changes, and the configuration file structure. Version five doesn't have nearly as many, but there's a couple of
things that is interesting. So because version five is so
new just came out last month, first of all, you may not want to migrate. I mean, what you're
getting from version five, I would say at this point
may not be worth it. Probably once the entire
ecosystem gets kind of upgraded to version five, then it
might make more sense. But if you're like me and if
you're like many projects, you probably use many
different plugins and loaders in your Webpack configuration file. And so if you do this, you
really need to go through... First of all, you have
to go through and upgrade all of plugins and loaders. That could be a lot. Second of all, you need to
check all of those plugins and loaders and make
sure that they actually even support version five. If you use something that's
in the Webpack project, one of the Webpack contrib plugins, then you're probably safe. But some of the third party
plugins that are, you know, you maybe found a plugin
or a loader out there that just did exactly
what you needed it to. And unfortunately it's
maintained by some person who, I don't know they lost their
computer for the past year. Those are gonna be a little tougher because they may not support
the changes in version five. And that's the thing is version
five, a lot of the changes, because there are a lot of changes to the internals are deep. And so the loaders and plugins, they're gonna have the most changes for these kinds of things if
you're an end user of Webpack. You know, I went through
the five major changes and you probably, you may
have gone through all five and said, "I'm already on node version 10. I don't have to do any of these things. I don't like use any of these
plugins that have changed." So you may be totally fine
with all of these changes, but all of your loaders
and plugins may not. So what you wanna do
is you wanna go through and check every loader and
plugin you want to upgrade it. If it's got a new version, if
it doesn't have a new version, you may need to look for
a beta of that plugin, or you may need to look for a new plugin or just wait to upgrade. One side benefit of doing this check is that you may find plugins
that have been deprecated or no longer supported. I did that when I was
going through this process and I was using this optimized
CSS assets, Webpack plugin. I don't know where I got it,
probably reading some tutorial, but basically it was deprecated. They said, "Use this other thing instead." So I learned that during
this process, which is good. I mean, I probably haven't
upgraded the kind of Webpack of the build for this
project in two years. So I'm not surprised that
something in there is deprecated. The other thing you should
do before you upgrade, is to use that trace
deprecations flag in Webpack when you're still on version four. That will let you know, even after you have kind of
done all of these upgrades for your loaders and plugins. What is still kind of lingering,
what isn't going to work when you upgrade to version five. The other thing that you can
do is you can just create a new get branch and just do
the upgrade of Webpack. You upgrade Webpack,
you upgrade Webpack-CLI, and then you upgrade... You probably need to
upgrade your Babel loader if you're using Babel and any of your other loaders and plugins. And once you do that, then
you run your build again, and you can see what has changed. You can see if it actually works. I mean, that would be amazing
if you just upgraded Webpack and it just immediately worked. I wouldn't be surprised
if that did not happen. That has never happened for me. So, yeah, so that's really
the installation process. The migration process
from Webpack version four to Webpack version five. So I wanted to share
my experience migrating one of my projects from
Webpack version four to Webpack version five. And this is not a production
app, it's not huge or anything, but I feel like there was... There's a little complexity in the build and so, yeah, I just wanted to share that and kind of show the project to you. So you can see here this
is my Webpack config. There's not too much going on. There's not a lot of loaders,
there's really just some CSS. I use less, it's going through Babel. I'm doing a little chunk splitting and some optimization minimization. But beyond that, there's
not a ton going on. And basically, let's see when I run this, it is running. You may have noticed that
ran really, really quickly. That is a half second Webpack
build that may surprise you, but that's a result of this
new configuration feature. And that's the file system cache. This is a new thing that
as far as I understand was not available in Webpack version four. If I commented out, you'll see that the build
takes quite a bit longer. It's actually about four
and a half second builds. So, with that file system cache, which as far as I understand
the way that it works, it caches things in the cache
folder of the Webpack folder in your node modules folder. So by running that you can see the build is crazy, crazy fast. Now, again, this is not a huge project. If you had a huge project, I feel like with this file system cache, you would still see gains like this. And that's really, really impressive. Another thing that I found
is that I currently run in production mode just for everything, but if you run it in development mode, it's actually significantly faster. And one of the reasons that
I found that was kind of... This is probably true
of Webpack version five, but at least in Webpack, I'm sorry. This is probably true
in Webpack version four, but at least in Webpack version
five, the production mode is because it's building
out these source maps. I was previously using
something like cheap source map, and it ended up being a very
slow process using this eval, it is much, much faster
for these source maps. It might not be the best thing
for running on the client, but at least in the
build it's the fastest. So, you know, those
are really the changes. Some of the other changes
that I had to do was, I had the... I was using (indistinct) JS. I had to use a TerserPlugin
and there were a few things that I just removed because
they weren't up-to-date anymore. I also noticed that the Webpack
package is actually larger in Webpack version five than version four. I think I may have done
something when I was upgrading, when I was modifying my
file and adding some things. And I think that's... I think that when I
was changing the loader or removing some of the loaders
that did something that, you know, has made the package bigger because in the Webpack release notes, it says that it's supposed to
be much better performance. And so I would just say
overall Webpack version five has been pretty awesome. I feel like if you have
a simple build like mine, it is probably something you
could jump to right away. If you have a very complicated build, some custom loaders or plugins, you might want to wait
and stay on version four until you've got time to
really put into the upgrade. Either way that file system
cache is pretty sweet, isn't it? So you may want to think
about putting that time in, it may be worth it in the long run if your development time
is significantly better. The other cool thing with
that file system cache is that if you're using something, some kind of a continuous integration and you're caching your node
modules folder in there, which is something that
I always did on mine, then that cache will also be
applied to your Webpack builds since it's in the node modules folder. So that's really cool. All right, well, that was
the five biggest things in Webpack version five. I also went through a migration guide and my own experiences. I hope you enjoyed this video. Thanks so much for watching. If you liked this video, give it a like, and subscribe to my channel
for more videos on Webpack or things like AWS or JavaScript. Thanks so much for watching
and I'll see you next time. (pop sound) (upbeat music)
