A module is a set of pieces of code: for example, code of a similar language has a common function—that is to say, it is part of the same function or operation within an application.

Often, modules in Webpack 5 are grouped according to the scripting language used, as follows:

The preceding diagram should help illustrate what most people see when exploring the contents of a Webpack build.

An application is then divided into modules and assets. As we explained in Chapter 1, Introduction to Webpack 5, an asset is essentially images and videos that are not considered scripted by a developer. The directory structure is then subdivided into these modules, usually in a directory of their own.

Dividing an application into modules will naturally make the process of debugging easier. This will also aid us in verification and testing in general.

Building applications this way ensures that a boundary is made between well-written code and more-dubiously written code. Naturally, this helps with directory navigation, as each module has a defined purpose.

Many platforms use modules and it is a term that you will no doubt be used to if you work in web development in general. However, each platform differs slightly.

Webpack 5 forms these modules according to how it expresses the dependencies of the module. Here are a few examples of how Webpack 5 expresses them:

• Through a 2015 ECMAScript import statement
• Through a CommonJS require() statement
• Through an asynchronous module definition (ASM) define and require statement
• Through an image URL in a stylesheet
• Through an @import statement in a stylesheet

In summary, modular code makes things a lot easier and understanding how Webpack expresses dependencies will help you understand how you should compile your code. From here, the natural next step is to look at the supported module types and how loaders work with them.