The end-to-end solution for configuring, refactoring, maintaining and using path aliases

Path "aliases" are @identifiers that simplify unwieldy or lengthy file imports.

Using them in your projects makes your code easier to read and maintain:

// from this
import { fooify } from '../../../core/services/foo' 

// to this
import { fooify } from '@services/foo' 

They are widely supported in the JavaScript ecosystem, however:

• libraries have incompatible formats so require separate configurations
• maintaining duplicate configurations is fiddly and error-prone
• migrating source code is laborious and long-winded

If you are thinking about using aliases:

• The Alias CLI migrates your project by configuring your paths and rewriting your imports

If you are already using aliases:

• The Alias API simplifies your tooling with a single config file and one-liner integrations

You can configure and migrate any project in less than a minute by:

• installing the package
• running the CLI
• following the prompts

Alias HQ is configured using your project's ts/jsconfig.json:

{
  "baseUrl": "src",
  "paths": {
    "@packages/*": [ "../packages/*" ],
    "@/*": [ "/*" ],
    "@app/*": [ "/app/*" ],
    "@services/*": [ "/app/services/*" ],
    ...
  }
}

Note that you do not have to use TypeScript or VS Code to use Alias HQ.

The API makes sure your IDE, framework and toolchain are always in sync:

// webpack.config.js
config.resolve.alias = hq.get('webpack')

// jest.config.js
config.moduleNameMapper = hq.get('jest')

// etc...

The CLI makes sure your code is always up-to-date:

? What do you want to do?
  - Configure paths
  - Setup integrations
❯ - Update source code
  - Help
  - Exit

Install via your package manager of choice:

npm i --save-dev alias-hq

yarn add -D alias-hq

To jump in without much reading:

• Quick start

For step-by-step instructions:

• Documentation

For a short video:

• Click here

Wanna support the project?

• Tweet or retweet about it :)