JavaScript

Why aren't you using Aliases in webpack config?

With Aliases, you can speed up development & be ready for refactoring productively. See why you must consider Aliases in Webpack Config of FrontEnd projects

Pankaj

Dec 4, 2019 • 3 min read

Are you Developers doing FrontEnd? Are you using Webpack?

If any answer is No, you can skip this post.

But if Yes, are you using aliases in your webpack configuration?

If Yes; Congratulations ?! You are already productive with this part of your FrontEnd Application development. You can leave this post.

If No, then let me ask you a question:

Why not?

What are you going to see in this post?

Problem
Solution
Aliases in a Managed way

Problem

Let’s start with the problem here.

In a large-scale application where the codebase is huge and you often see imports like the following:

import Gallery from '../../../commons/components/Gallery'

import { getUserPrefefences } from '../../../utils/storage/browser/user'

The ../ or relative imports are the concern here.

For a small codebase, these are fine but for a large codebase where the developers work in parallel and move things around frequently, this introduces the following problems:

Need to mentally traverse the directory
Spend time fixing the imported modules not found

And for the new developers in the teams, this problem becomes 10 folds

Solution

As you have read the title of the article, this problem can be solved by using aliases in the repack config.

How does it work?

To explain the usage of aliases; consider the following directory structure:

webpack.config.js
src
  - commons
    - components
      - Gallery
        - Gallery.js
      - User
        - User.js
      - Avatar
        - Avatar.js
      - Button
        - Button.js
  - pages
    - components
		- Layout
        - Wide.js
      - Grid
      - Page
    - Messages.js
    - Profile.js
    - Dashboard.js
    - Login.js
    - Register.js
  - utils
    - url

For the above structure, consider the following scenarios:

Accessing some components in the Dashboard.js would look like the following:

import React from 'react'
import WideLayout from './components/Layout/Wide'
import Gallery from '../commons/components/Gallery/Gallery'

Now we try to rearrange the tree structure and put the gallery Component in the directory: <project-root>/src/pages/components/commons/Gallery

And not we have to refactor the above code to keep working. As our project structure taken for example is small, so it is easy to remember the Component rearrange in code as well:

  import React from 'react'
  import WideLayout from './components/Layout/Wide'
- import Gallery from '../commons/components/Gallery/Gallery'
+ import Gallery from './components/commons/Gallery/Gallery'

Now let’s try to add a few lines to our web pack config:

module.exports = {
  //...
  resolve: {
    alias: {
      Components: path.resolve(__dirname, 'src/commons/components/'),
      Pages: path.resolve(__dirname, 'src/pages/')
    }
  }
};

What the above lines in your web pack configuration will do is enable you to write the previous component in the following manner:

import React from 'react'
import WideLayout from 'Pages/components/Layout/Wide'
import Gallery from 'Components/Gallery/Gallery'

Hence, now you exactly know where these components are loaded from, provided that you know about the aliases in your config.

And then refactoring the components will also be less painful.

You can read more about the Aliases in the webpack configuration here:

Aliases at one place

Now you can manage aliases in one place, read more in the following post:

Problem

Solution

Aliases at one place

Conclusion