The setup above makes all files that are at the same level of the folder structure as the package.json file default to ESM. Alternatively, we can decide to set the type as commonjs, and the Node runtime will force all files to conform to the default Common JS Module system. Although this is usually the default behavior if no type field is specified.
We have covered other ways — for example, using the .mjs or .cjs file formats and how these extensions are resolved as either ESM or other module formats — in our earlier blog post as well.
In essence, when modules are flagged as ECMAScript modules, the Node runtime uses a different pattern or method for resolving file imports. For example, imports are now stricter, meaning we must append the full filename with their extensions for relative paths or requests as the case maybe.
What is code transpilation?
With the introduction of a new JavaScript version and changes to the syntax (also known as ES2015), the introduction of TypeScript, the JavaScript superset , and other language advancements like CoffeeScript, for example — writing JavaScript that runs everywhere is no longer as straightforward as it once was.
As we may already be aware, different browsers have different JavaScript engines, and their varying levels of adoption of and support for these new JS features might not be unanimous because they didn’t meet the language specification at equal times. This has resulted in cases where code can work on one browser and not work on another.
The essence of transpilation, therefore, is to be able to convert the new JS ES2015 syntax to the old ES5 syntax, so code can run on older browsers.
For example, template literals or, say, null coalescing and other ES2015 or ES2015+ features, still do not have full browser support and server-side runtime support, so we might need to transpile our code to support these versions.
Majorly, tools called loaders like Babel, Traceur, and so on are used in conjunction with webpack for transpiling code.
On a high level, transpilers work across programming languages by reading source code line by line and producing an equivalent output. For example, we might want to transpile a TypeScript codebase to plain old JavaScript.
In general, transpilers allow us to use new, non-standardized JavaScript features with assurance. Currently, the best approach to working with ES modules on both the Node.js and browser environment is to transpile them to the CommonJS module format with Babel.
Transpiling in Node.js
ESM comes with a transpiler loader by default that converts code from sources the Node runtime does not understand into plain JS using Loader Hooks.
Here, we can load our source code as needed from the disk, but before Node.js executes it for us. This is not usually applicable in a browser environment because fetching each file individually over the wire would be very slow and non-performant.
The transpiler loader also comes with a resolve Hook that tells the runtime how to handle unknown file types.
What is webpack?
Webpack is a build tool that helps bundle our code and its dependencies into a single JavaScript file. We can also say that webpack is a static module bundler of sorts for JavaScript applications. This is because it applies techniques such as tree shaking and compilation (which consists of both transpilation and minification steps) to our source code.
Bundlers like webpack work hand-in-hand with transpilers. This means that they are totally different, but rather complementary toolsets. Therefore, we need to configure webpack to work with a transpiler — say Babel.
As we have mentioned earlier, transpilers either perform the job of compiling one language to another, or to make a language backward compatible. Webpack works pretty well with Babel, and it is also easily configurable. For example, we can configure Babel to work with webpack by creating a webpack config file (webpack.config.js) using the Babel plugin — in fact, the webpack plugin ecosystem is what makes webpack what is.
Babel, on the other hand, can be configured using either a babel.config.js file or a .babelrc file.
Why webpack?
As you may know, webpack supports a couple of module types out of the box, including both CommonJS and ES modules. Webpack also works on both client- and server-side JavaScript, so with webpack, we can also easily handle assets and resources like images, fonts, stylesheets, and so on.
It remains a really powerful tool as it automatically builds and infers the dependency graph based on file imports and exports (since, under the hood, every file is a module). Combining this with loaders and plugins makes webpack a great tool in our arsenal. More details on how this works under the hood can be found in the documentation.
In terms of plugins, webpack also has a rich plugin ecosystem. Plugins support webpack in doing some dirty work like optimizing bundles, managing assets, and so on.
In summary, bundling with tools like webpack is the fastest way for working or ensuring backward compatibility with modules these days, since ESM are gradually gaining momentum as the official standard for code reuse in the ecosystem.
Webpack also supports loaders, which help it decide how to handle, bundle, and process non-native modules or files. It is important to point out how webpack treats loaders. Loaders are evaluated and executed from bottom to top. So therefore, the last loader is executed first and so on and so forth, in that order.
In this post, our major focus is on how webpack transpiles or handles ECMAScript modules.
Using loaders for transpilation
Loaders transform files from one programming language to another. For example the ts-loader can transform or transpile TypeScript to JavaScript. Usually, we use loaders as development dependencies. For example let’s see how we can make use of the ts-loader.
To install, we can run the following:
npm install --save-dev ts-loader
We can then use this loader to instruct webpack to properly handle all the TypeScript files in our source code for us. See a sample webpack.config.js file below.
module.exports = {
module: {
rules: [
{ test: /.ts$/, use: 'ts-loader' },
Here, we as we have mentioned, we are telling webpack to handle all file paths ending with a .ts extension and transpile them down to JavaScript syntax that the browser and node runtime can understand. This means that loaders can also run in the Node.js environment and, therefore, also follow the module resolution standard.
Loader naming conventions
The general way to name loaders is consistent, as loaders are named with their name and a hyphen — usually as xxx-loader. For example, babel-loader, ts-loader, and so on.
For our use case, we are most especially interested in ESNext or babel-loader, a community built and supported loader currently in version 7.16. More information on loaders can be found in the webpack documentation.
Some webpack core concepts
In order to understand how webpack works, this section covers some high-level concepts readers should be aware of.
Like we mentioned earlier, webpack uses a dependency graph, which means that it recursively builds a relationship that includes every module an application needs or depends on, then bundles all of those modules into an output file that’s ready for use. This means that webpack needs to have an entry point — and indeed it does.
In setting up our webpack configuration, the entry point is the beginning of the filepath webpack checks before it starts building out an internal dependency graph for our application. Note that webpack also supports multiple entry points for our application.
module.exports = {
entry: ['./path/to/my/entry1/file1.js', './path/to/my/entry2/file2.js']
To add multiple entry points, we can use an array instead. In webpack v5, we can now have an empty entry object. This allows us to make use of plugins when adding entries.
After webpack builds out the dependency graph internally and completes the bundling process, it needs to output the bundle to another filepath, which we then need to serve.
This is what the output property does. It tells webpack which path to emit the bundles it has created and how the files are named.
const path = require('path');
module.exports = {
entry: './path/to/my/entry/file.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: 'my-first-webpack.bundle.js',
Beginning with v4.0.0, webpack does not require a configuration file to bundle your project, although it does assume that you have defined the entry point to your application with the folder and filepath as src/index.js, and that the output is bundled into the dist/main.js folder path, minified, optimized, and ready for production.
Setting up webpack and Babel
There has been full support for using the native ES2015 module syntax. This means that we can use import and export statements without relying on external transpilation tools or dependencies like Babel. However, it is still recommended to have Babel configured, just in case there are other, newer ES2015+ features that webpack has not yet taken into consideration.
Based on the module formats in place, webpack checks the nearest package.json file and enforces the appropriate recommendations. When using webpack to bundle our code it is usually advisable to stick to a single module syntax to allow webpack properly handle the bundled output in a consistent manner and hence prevent unwanted bugs.
To get started, we need to ensure we have the webpack CLI installed on our machines. We can then make use of the init CLI command to quickly spin up a webpack config based on our project requirements. We can do so by simply running npx webpack-cli init and responding to the prompts appropriately.
Now, we need to compile our ES2015 code to ES5 so that we can use it across different browser environments or runtimes. For this, we’ll need to install Babel and all of its webpack-required dependencies.
Let’s go ahead and install the following:
Babel Core
Babel Loader, a webpack loader that interfaces with Babel Core
To install, we can run:
npm i webpack webpack-cli webpack-dev-server @babel/core @babel/preset-env babel-loader rimraf -D
At the end of the installation, our package.json should look like this:
"name": "webpack-demo",
"version": "1.0.0",
"description": "A demo of webpack with babel",
"main": "dist/bundle.js",
"scripts": {
"build": "node_modules/.bin/webpack --config webpack.config.js --mode=production",
"watch": "node_modules/.bin/webpack --config webpack.config.js --mode=development -w",
"prebuild:dev": "rimraf dist"
"author": "Alexander Nnakwue",
"license": "MIT",
"dependencies": {},
"devDependencies": {
"@babel/core": "^7.16.0",
"@babel/preset-env": "^7.16.4",
"babel-loader": "^8.2.3",
"rimraf": "^3.0.2",
"webpack": "^5.64.3",
"webpack-cli": "^4.9.1",
"webpack-dev-server": "^4.5.0"
"type": "module"
Note that we have our dependencies pinned to allow for consistency when we run our application in the future.
The @babel/preset-env package will transform all ES2015–ES2020 code to ES5 or basically any target environment we specify in the target options. We usually need it when we intend to set a particular target, which then allows Babel to target that particular environment. But it is also possible to use without setting a target, but comes at a cost of larger bundle sizes.
This package basically checks the target environment specified against its own internal mapping, and then compiles a list of plugins it passes to Babel for code transpilation. This results in smaller JavaScript bundles.
Therefore, if we do fail to specify a target, the outputted code size would be larger because, by default, Babel plugins groups ECMAScript syntax features into a collection of related features. More details on this can be found in the documentation.
Even better, with an option for smaller bundle size and larger performance gains, we can make use of babel/preset-modules, which will be eventually merged into @babel/preset-env core.
Configuring the webpack.config.js file
Now, let us proceed to configure our webpack file. Go ahead and create a new webpack.config.js file in the root of our project.
import path from "path";
import { fileURLToPath } from "url";
const __dirname = path.dirname(fileURLToPath(import.meta.url));
export default {
entry: './src/index.js',
output: {
path: path.resolve(__dirname, './dist'),
filename: 'bundle.js',
experiments: {
outputModule: true,
plugins: [
//empty pluggins array
module: {
// https://webpack.js.org/loaders/babel-loader/#root
rules: [
test: /.m?js$/,
loader: 'babel-loader',
exclude: /node_modules/,
devtool: 'source-map'
In the config above, we created a polyfill for __dirname variable. Also, we have set the field outputModule to be true, which is necessary if we intend to use webpack to compile a public library meant to be used by others. The babel-loader loads ES2015+ code and transpiles it to ES5 using Babel.
As you can also see in the config file, we have a module property, which has a rule property that contains an array for configuring the individual loaders we may need for our webpack configuration.
Here, we have added the webpack loader and set the needed options as per our project requirements.
Note that the test option is a regular expression matching the absolute path of each file and checks for files extensions. In our above example, we are testing whether our file ends with either a .mjs or .js extension.
Using (and not using) the .babelrc file
Now, we can configure Babel by creating a .babelrc file, also in the root of our project. The file content is shown below:
"presets": [
"@babel/preset-env",
"targets": {
"esmodules": true
Below is the output of running our application locally in development with the npm run watch command:
In the case we do not want to make use of the .babelrc file, we can also add the presets in an options object inside the rules array, like so:
module: {
rules: [
test: /.m?js$/,
exclude: /node_modules/,
use: {
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env', "es2015", "es2016"],
Setting presets and adding plugins
We need to set the presets so that the ES2015 features in our code can be transformed to ES5. In the options array, we can also add the plugins we want to add to our configuration.
For example, we can add this line: plugins: ['@babel/plugin-transform-runtime'], which installs a Babel runtime that disables automatic per-file runtime injection to prevent bloat.
To include this in our code, we need to install them by running:
npm install -D @babel/plugin-transform-runtime
We must also add @babel/runtime as a dependency by running npm install @babel/runtime.
Also note that in the rules object, we are telling webpack to exclude files in the node_modules folder with the exclude property. This is so that we have a faster bundling process as we do not want to bundle our node_modules folder.
There are also cases where we want webpack to handle ES 2015 modules. To allow this, we need to use a plugin called the ModuleConcatenationPlugin. This plugin enables some form of concatenation behavior in webpack called scope hoisting, which is a feature made possible by the ESM syntax. By default, this plugin is already enabled in production mode and disabled otherwise.
Conclusion
In order to avoid compatibility issues, we need to transpile our code from ES2015 to ES5. This is where webpack comes in. Webpack bundles our code and outputs a transpiled version down to the target as specified in the configuration file.
In our webpack configuration file, module rules allow us to specify different loaders, which is an easy way to display loaders. In this post, we have made use of just the Babel loader, but there are many other loaders we can also use in the ecosystem.
In terms of improvements and changes in the latest webpack release, v5, there is now out-of-the-box support for async modules. As the name implies, async modules are Promise-based and therefore do not resolve synchronously. Importing async modules via require() will now also return a Promise that resolves to their exports.
Also, in the Node.js ecosystem, the export and import fields are now supported in the package.json file. Finally, with the latest version, the minimum-supported Node.js version has been bumped up from v6.0 to v10.13.0, which is equally a LTS version.
The full demo source code can be found on my GitHub.
200s only 
Monitor failed and slow network requests in production
Deploying a Node-based web app or website is the easy part. Making sure your Node instance continues to serve resources to your app is where things get tougher. If you’re interested in ensuring requests to the backend or third-party services are successful, try LogRocket.
LogRocket is like a DVR for web and mobile apps, recording literally everything that happens while a user interacts with your app. Instead of guessing why problems happen, you can aggregate and report on problematic network requests to quickly understand the root cause.
LogRocket instruments your app to record baseline performance timings such as page load time, time to first byte, slow network requests, and also logs Redux, NgRx, and Vuex actions/state. Start monitoring for free.
#node
We use clear JavaScript, but it’s possible only for small projects. But using of webpack technique for large apps or websites makes life easier!
Thank you for the article!
