Gathering detailed insights and metrics for @dword-design/eslint-plugin-import-alias
Gathering detailed insights and metrics for @dword-design/eslint-plugin-import-alias
npm install @dword-design/eslint-plugin-import-alias
Typescript
Module System
Min. Node Version
Node Version
NPM Version
85.1
Supply Chain
97.3
Quality
79.5
Maintenance
100
Vulnerability
98.6
License
JavaScript (99.45%)
Shell (0.55%)
Total Downloads
1,737,429
Last Day
5,264
Last Week
18,355
Last Month
188,718
Last Year
1,249,096
70 Stars
263 Commits
11 Forks
2 Watching
6 Branches
7 Contributors
Minified
Minified + Gzipped
Latest Version
5.1.1
Package Id
@dword-design/eslint-plugin-import-alias@5.1.1
Unpacked Size
13.04 kB
Size
4.82 kB
File Count
6
NPM Version
10.8.2
Node Version
20.16.0
Publised On
18 Aug 2024
Cumulative downloads
Total Downloads
Last day
-76%
5,264
Compared to previous day
Last week
-79.2%
18,355
Compared to previous week
Last month
295.4%
188,718
Compared to previous month
Last year
273.9%
1,249,096
Compared to previous year
An ESLint plugin that enforces the use of import aliases. Also supports autofixing.
Aliases are a great thing to make imports more readable and you do not have to change import paths that often when a file path is changed.
1import foo from '../../model/sub/foo' 2import bar from '../other/bar'
changes to
1import foo from '@/model/sub/foo' 2import bar from '@/sub/other/bar'
Now what if you are in a bigger team or you have a lot of projects to update. Or you just want to make sure that everything is consistent. This is where a linter comes into the play. This rule allows you to detect inconsistent imports and even autofix them. This works by matching alias paths agains the imports and replacing the import paths with the first matching aliased path.
1# npm 2$ npm install @dword-design/eslint-plugin-import-alias 3 4# Yarn 5$ yarn add @dword-design/eslint-plugin-import-alias
Add the plugin to your ESLint config:
1{ 2 "extends": [ 3 "plugin:@dword-design/import-alias/recommended" 4 ], 5}
Alright, now you have to tell the plugin which aliases to use. In the simplest case, you are already using babel-plugin-module-resolver for your aliases. Your babel config would look something like this:
1{ 2 "plugins": { 3 ["module-resolver", { 4 "alias": { 5 "@": ".", 6 }, 7 }] 8 } 9}
In this case lucky you, you don't have to do anything else. The plugin should work out of the box.
If you have a special project setup that does not have a babel config in the project path, you can still use the plugin by passing the aliases directly to the rule. In this case you define the rule additionally in the rules
section:
1"rules": { 2 "@dword-design/import-alias/prefer-alias": [ 3 "error", 4 { 5 "alias": { 6 "@": "./src", 7 "@components": "./src/components" 8 } 9 } 10 ] 11}
By default, the plugin will convert parent paths to aliases (like ../model/foo
), but will keep subpath imports relative. You can change that to also convert subpaths to aliased imports by passing the aliasForSubpaths
option to the rule like so:
1"rules": { 2 "@dword-design/import-alias/prefer-alias": ["error", { "aliasForSubpaths": true }] 3}
Are you missing something or want to contribute? Feel free to file an issue or a pull request! ⚙️
Hey, I am Sebastian Landwehr, a freelance web developer, and I love developing web apps and open source packages. If you want to support me so that I can keep packages up to date and build more helpful tools, you can donate here:
If you want to send me a one time donation. The coffee is pretty good 😊.
Also for one time donations if you like PayPal.
Here you can support me regularly, which is great so I can steadily work on projects.
Thanks a lot for your support! ❤️
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
6 existing vulnerabilities detected
Details
Reason
3 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 2
Reason
Found 1/28 approved changesets -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2025-01-27
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More