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:
For step-by-step instructions:
For a short video:
Wanna support the project?
- Tweet or retweet about it :)