Webpack is a bundler that is wildly popular, and quite frankly, the top choice in processing our large JS applications into a proper file(s) to be loaded into our end applications. Despite it being so popular, strangely only a low percentage of engineers working with it actually understand it. With our frameworks and starters taking care of it for us, why would we need to though?

As you grow and want to gain the most performance and efficiency out of your applications, knowing the underwiring of Webpack allows for that. So eventually you’ll have to bite the bullet and get into the weeds. Luckily today is that day, and we’re starting with the basics.

Dependencies In Modern JS

For me, the first step in understanding Webpack isn’t 100% related to it at all. Before the associated packages, you’ll use are installed, there is some knowledge that is important to know. Where should they go? It may sound like a stupid question, but it is completely valid. This is so because there are two types of dependencies you define in your package.json: regular dependencies and dev dependencies.

Regular Dependencies

These are what most should be familiar with. Regular dependencies, for lack thereof a more concrete descriptive name, are where packages are installed that are then expected to be used in the application being built. Think of React as an example. In all your component files you import it at the top, so it’s clearly being used in the application. Since it’s being used, we would consider that a “regular dependency”.

Dev Dependencies

Dev dependencies can be viewed as the opposite of regular dependencies. While their counterpart is directly involved with the application building, dev dependencies are only required during development. A prime example being Webpack! Webpack, and anything related, is only used during the development of the production-ready application files. So making sure they are added here is important for a healthy application.

What’s Next

Learning to genuinely comprehend a topic starts at only one place for me. The very beginning. I could’ve easily made this first entry going at some high-level theoretical approach, but you’d be missing so much! Most engineers coming into the JS/TS space do have a tendency to bypass understanding the different dependencies available in package.json. Without that knowledge, projects can only get bloated with unnecessary tools.

In future articles, you can expect a mix of things. Some articles simply explaining the different aspects under the hood, some going over code, architecture, and a few other things depending on how I would think best to educate.

So, stay tuned!