Javascript module imports in large projects
Tags: javascript, webpack, webdev, react
Published: 2020-07-05 17:07:39

We all have been there, starting off a new project and writing long relative paths as we go ignoring all the trouble it can cause later.

But let us forget about all the upcoming troubles for a while and assume we will never reach past 15 files in the whole project. Do you actually like writing those dots and slashes? Do the unstructured codes never bother you? Has it never happened that it’s the middle of the night and you those `../../../../../../` scare the hell out of you? Anyways, let's see the actual problem.

## The problem

As you keep on scaling your project past a certain point of complexity, you’ll end up traversing up and down your directory structures. Which is first of all ***time-consuming and error-prone*** as well as absence of an IDE can make it a nightmare to remember all directory and files. Even with code-completion features like [**IntelliSense**](https://en.wikipedia.org/wiki/Intelligent_code_completion) in place (supported by almost every IDE), this can become more challenging as your codebase grows.

{% gist https://gist.github.com/mrinalraj/0d96d0ec63f5da9f325c98c5daadbe8b.js %}

Just imagine a situation where you are changing the directory structure of a module in your project. This will break all the module references and you will be forced to change all occurrences of the module throughout your project. It will be a daunting task!

## The Solution

[Webpack](https://github.com/webpack/webpack) allows you to create aliases to `import` or `require` certain modules through the `resolve.alias` property in your config without any additional plugins. Yes, you will have to use [Webpack](https://github.com/webpack/webpack) for your Nodejs projects.

How does the `webpack.config.js` look? Here are the necessary changes you need to add to the config file.

{% gist https://gist.github.com/mrinalraj/519e5356ff4a529e734f98734400fdaf.js %}

After the webpack configuration, the import can be simplified in the following way making is cleaner and less complicated.

{% gist https://gist.github.com/mrinalraj/82673259c7ef85188bfb64a869f8e5c9.js %}

Seems fair to configure webpack in a Nodejs project, but what about projects bootstrapped with [CRA](https://create-react-app.dev/). Do you React people actually want to run `npm eject` just to manage aliases? That can be even greater pain than those longer relative imports.

## CRACO saves the day

[CRACO](https://www.npmjs.com/package/@craco/craco) short for **C**reate **R**eact **A**pp **C**onfig **O**verride is an npm package that replaces the default `react-scripts` in a CRA project and overrides some of the webpack configurations. CRACO with `craco-alias` plugin can help us achieve the same. 
Here is how the configuration file will look like.

{% gist https://gist.github.com/mrinalraj/210603d684cbaf51cb194da5c33a5d19.js %}

## Are we done?

Apparently, all of these configurations absolutely breaks the [**IntelliSense**](https://en.wikipedia.org/wiki/Intelligent_code_completion) for these imports in [Visual Studio Code](https://code.visualstudio.com/).

Luckily, IDEs like [Visual Studio Code](https://code.visualstudio.com/) have the option to let them know how to resolve these aliases just by adding a `jsconfig.json` file with appropriate options. Just like the one below.

{% gist https://gist.github.com/mrinalraj/59453ff368f6b94a40655c7b825c2eee.js %}

Yeah yeah, that's all, I know it's a lot of boilerplate but in an enterprise-level project where codebase grows every day, it's a must-have. And that sums up everything you need to know for creating aliases for Javascript imports.

*Enjoyed reading the piece? A few Claps and Shares are all I need. Cheers.*