I am assuming that you know what Webpack is and what it is used for. But those who don’t, Webpack is a bundling tool primarily used to combine multiple files together to produce a single bundle. For example, you can combine multiple JavaScript files together to produce one main.js which you will eventually import in the Web application using a <script> tag.

But what separates Webpack from task runners such as Grunt or Gulp is the other functionalities it provides. You can transpile TypeScript to JavaScript on the fly and the resultant JavaScript will be used for bundling. You can also transpile SCSS (SASS) to CSS and make a .css bundle.

But Webpack in reality is just a bundling tool. The job of transplanting code and performing other operations on the bundle (while Webpack is generating the bundle or after bundles are created) are performed by Webpack loaders and Webpack plugins. These are the external JavaScript programs commonly provided through open-source NPM packages.

Babel is a program that can independently transpile one version of JavaScript to another version of JavaScript. For example, if you want to transpile ES6 to ES5, then you can use Babel for that. Babel provides a CLI tool that can do this by simply running babel es6.js --out-file es5.js command.

Babel doesn’t have a clue about Webpack. But you could ask Webpack to compile a JavaScript file using Babel before it is bundled with other JavaScript files such that the final JavaScript bundle strictly contains ES5 code. This is taken care of by the babel-loader which is an external JavaScript program that glues Webpack and Babel together.

💡 I have discussed how Babel works and also a little about Webpack plugins and loaders in “How to quickly transpile JavaScript using Babel alone.” article.

So the question is, why would you ever need Webpack if TypeScript compiler (TSC) can transpile TypeScript to JavaScript. Well, in most cases, you don’t. But the TSC isn’t designed to do everything for you. It can compile TypeScript to JavaScript, produce declaration files, produce source maps, and even produce a bundle file using [outFile](https://medium.com/jspoint/typescript-compilation-the-typescript-compiler-4cb15f7244bc) compile-option.

But the outFile option won’t work in all the scenarios. If the output module system is set to ES6, CommonJS or anything other than None, System or AMD, TSC won’t be able to produce a bundle file. I have already explained this Compilation lesson (under the _outFile_ section).

The reason why TSC won’t allow you to do this is that a bundle file with import (ES6) or require() (CommonJS) statements will try to import files from the disk (or network) at runtime but you have all the files (code) in the same bundle. There are other sorts of problems as well with this method.

However, Webpack solves these issues by replacing import and export statements with the helper functions in the output bundle. These helper functions do what exactly import/export or require/module.exports statements do but within the same bundle and without the help of a module system. Therefore the final bundle can run in any environment such as browser or Node.

You could also use Webpack with TypeScript to do other things such as process SASS (_.scss_) file imports and produce a .css bundle. You could also use Webpack to split the output bundle into multiple files such as main.js and vendor.js that TSC currently can’t do.

It’s ideal in most Web projects that use TypeScript to configure Webpack as the bundling tool. TypeScript compiler is designed to compile TypeScript and if you want to do more, you need to use Webpack or another bundling tool that provides seamless integration with TypeScript.

Now that we have settled with Webpack, let’s understand how Webpack works with TypeScript. As we know, TSC needs a tsconfig.json file for the compilation (but not necessary), Webpack needs webpack.config.js file (also not necessary) which provides configuration about the files to bundle.

Like Babel, Webpack depends on TSC to transpile TypeScript to JavaScript but as TSC doesn’t have a clue about Webpack, hence Webpack needs a loader to talk to TSC. This is where the ts-loader comes into play.

Webpack compiles a TypeScript file using ts-loader package which asks TSC to do the compilation. The result of this compilation will be JavaScript code that will be used to make a bundle. So in the end, we have a JavaScript bundle file with mangled import/export statements generated from .ts files. This whole process is explained in the following diagram.

As shown in the above diagram, the input files a.ts, b.ts and c.ts are compiled to JavaScript files using ts-loader which uses the TypeScript compiler under the hood. Then the final JavaScript files are bundled by Webpack which can undergo further processes.

But the story is far from over. We need to configure Webpack using a webpack.config.js file to use the ts-loader package when the input files have .ts extension. As this compilation of these files is done using the rudimentary TypeScript compiler, we also need to configure TSC using tsconfig.json file. So let’s get started.

#javascript-development #typescript #web-development #javascript #programming