this post was submitted on 10 Apr 2024
11 points (100.0% liked)

Cool GitHub Projects

1282 readers
1 users here now

Wormhole

[email protected]

Icon base by Caro Asercion under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
LinearArray
11
eslint-plugin-paths: A plugin for ESLint, to force use paths aliases from tsconfig (github.com)
submitted 8 months ago by vitonsky to c/cool_github_projects
5 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] vitonsky 1 points 8 months ago (1 children)

Could you elaborate your idea.

If i correct understood you, you want to use relative imports inside alias directory. This is possible, you may check test about it https://github.com/vitonsky/eslint-plugin-paths/blob/d5a307866df9cf460a50301820e12e3653eb1cca/src/rules/alias.test.ts#L36-L40

Is it that you need?

[–] [email protected] 1 points 8 months ago (1 children)

It is, but I'd specifically like a rule that enforces this style of import over aliased imports. I.e. when importing a package, the order of importance is:

  1. Relative import (if on same or lower level)
  2. Aliased import (if in ancestor directory or different module)
[–] vitonsky 1 points 8 months ago (1 children)

Current plugin is just about force use aliases instead of relative paths (and back for deprecated aliases).

If you need to sort imports, you may try rule simple-import-sort/imports from https://github.com/lydell/eslint-plugin-simple-import-sort It is very flexible, so you may customize your own groups. For instance, you may group aliases in one group and relative imports to another group. Check their docs

[–] [email protected] 1 points 8 months ago* (last edited 8 months ago)

Sorry, maybe I'm not being clear - I'm not talking about sorting. I'm talking about an ESLint rule that flags alias imports that can be expressed as relative subdirectory imports, but flags other imports that could have been alias imports. Does that make sense?

Examples:

// we're in @/lib/foo

// correct
import A from "./foobar/a"
import B from "./b"
import C from "@/lib/c"
import D from "@/d"

// incorrect
import A from "@/lib/foo/foobar/a"
import B from "@/lib/foo/b"