Babel gives us:
Babel manages a transpiler and a polyfill:
- The polyfill converts/translates new features (like methods or objects)
Ultimately, Babel supports several plugins and presets (or sets of plugins) to transpile in a specific mode to convert the code for browser recognition.
To use and share these packages, we need some kind of tool to manage them, which is where the node packager (“NPM”) comes in. NPM is a command-line interface that allows us to manage packages and write scripts to use on web development tools.
Node package manager was created for node.js and designed to run on the server as opposed to the frontend. To work with this tool, the command line is similar to moving around the file system, for creating files, copying files, and installations. Node.js generates a file named package.json, which is a configuration file that saves all project information.
Package.jsonshould look like this:
When sharing a project instead of sharing the node modules, you only need to share the package.json file. Others can install the packages automatically with the command “NPM install.” So, we don’t need to download from the website manually, we can automatically download and update it using NPM. Looking inside the node modules folder, we can link to the NPM downloaded version of the index.html file as follows:
The best part about this is that we can use NPM to download and update our packages through the command line. It’s simple, easy, and efficient.
Typically, if we have more significant projects, we divide it into different modules, which makes it easy for reusability. Modules cannot work in isolation; they need to collaborate with other modules to create some form of useful functionality. To reference each other, we use something called module formats of which there are two types:
- Unofficial Module Formats: These are formats like common.js, Asynchronous Module Definition(AMD), and Universal Module Definition (UMD).
- Official Module Formats: These create a standard format that everyone can follow like import/export.
First, to consume the module in HTML and to load, we have to make it in sequence as there is a dependency between them; otherwise, we’ll get errors. This is a protocol used in cases where we have complex systems like insurance or health care systems. If the dependencies don’t match, we get errors and complications in deployment and performance. We want this process to be easy with as few issues as possible with dependencies.
Second, we want to make a single request and avoid multiple requests to the server. This is where Webpack comes into the picture. Webpack will take all the necessary modules and make it a single bundle, so it’s called a module bundler. If we’re talking about complex projects, we cannot go and prompt through a command like this:
It can be tough to remember this type of syntax, and deployment becomes more complicated because we need a configuration file to define how the bundling process takes place. For that, webpack has created a file called “webpack.config.js:”
This is typically how a webpack configuration will look. In the above image, we are providing entry and output (without this webpack will not work), and doing the same thing in the command prompt by simply giving command “webpack.”
Fortunately, webpack supports common.js, AMD, and UMD. In common.js, the caller will export itself by the export variable, and whichever is the called will call the module by using the command “require,” which will have webpack bundle everything.
If we want to do some preprocessing/post-processing before bundling, we have modules and plugins. Modules are nothing but logic before bundling starts, while plugins are for post-processing uses.
- Plugins: Once the bundle has been created, you’ll need to create a plugin if you wish to do any post-processing production on it.