Babel is a fairly powerful tool in the web development toolbelt. It works well by itself and can be plugged into more robust bundlers to accomplish more. While most of the more popular starters in the frontend industry use it as a piece of a more robust bundling process, Create React App as an example, there are still use cases where it is more than enough individually. So to better your understanding of Babel, we’ll be taking a look at how to compile code with Babel.
Why Compile
Those already familiar with Webpack or Rollup may be thinking what’s the benefit of just compiling? Well, there is no denying that bundling is great for combining numerous files into a minimal few, depending on your code splitting strategy. However, there are times when having all your code bundled isn’t the most optimal option.
Supporting this, let’s look at the concept of a shared component library. Most today offer two ways of injection into our applications, NPM package or CDN URL. Now the CDN URL is an all-inclusive bundle with everything needed to use said library in your application. Whereas the NPM package is a more nuanced use case. The NPM package route allows for importing only the modules you’re actually using, not the entire library. The ability to do that comes from compiling.
Setting Up For Compiling
Now that we have a better idea of how great compiling our code with Babel is, let’s look at setting up our projects with it. For that, we’ll take our attention to the babel.config.json file. This is a file that lives at the root of your project and will be home to our configuration setup for Babel in your project. Taking a snippet from the official Babel website, let’s take a quick look at what it would look like.
{
"presets": [...],
"plugins": [...]
}At the core of your implementation, and a basic config file in general, these two sections will be present. Presets and Plugins are the logic behind taking your project code to compiled files.
Presets
In the simplest of terms, presets in babel are a collection of plugins and config options. They are great because they alleviate the need for individuals to keep track of every plugin and configuration option, but instead just specify a bundle that does all that for them.
Plugins
This is where the magic really happens in Babel. Plugins can be described as functional logic used to transform your code into the desired compiled end result.
Overrides
Well, the name is self-explanatory. Overrides in your Babel config act as a way to specify a set of presets and plugins for a specific set of files. For example, say there is a certain area or file type(s) in your project that you want to have their own rules. A simple way to do that would be to specify them in the override section of your config. Let’s look at an example below.
{
"presets": [...],
"plugins": [...],
"overrides": [
{
"test": ["src/test/**/*"],
"presets": [...],
"plugins": [...]
}
]
}An alternative to overrides, less advisable personally, is having individual .babelrc files(s) placed in subdirectories of your project. This is pretty convenient for those that build in a mono repo approach, which I’m very much against.
In Closing
Babel is a great tool to be familiar with. It allows for us to write the code with the latest and greatest of features, without the need to worry about how browsers will be able to interpret them. In addition, it also allows us to be more accurate on our separation of concerns with the code we write. Breaking away from the mono repo pattern.
From here, expect to learn more about the actual compiling tool of Babel.