Releases: Limegrass/eslint-plugin-import-alias
Releases · Limegrass/eslint-plugin-import-alias
v1.6.1
v1.6.0
- add support for
isRelativeImportOverridesEnforced - update documentation regarding flat config support
- minor verbiage updates
Full Changelog: v1.5.2...v1.6.0
v1.5.2
- Fixed a bug where aliases with slashes were not being properly matched
and thus no suggestions were made - Minor performance optimization when relative paths are permitted
Full Changelog: v1.5.1...v1.5.2
v1.5.1
- This should fix version compatibility with eslint@8 again.
- Silenced an edge case with the isAllowBaseUrlResolvedImport
parameter when an alias exists equivalent to a baseUrl-resolved path.
Full Changelog: v1.5.0...v1.5.1
v1.5.0
Full Changelog: v1.4.1...v1.5.0
- added support for eslint@9 with the help of @Crownpack07 in #18
v1.4.1
Full Changelog: v1.4.0...v1.4.1
- fixed a bug which mistakenly attempted to evaluate some paths as a
relative path import
v1.4.0
Full Changelog: v1.3.2...v1.4.0
- added option
isAllowBaseUrlResolvedImportto allow configuring of
whether or not non-declared paths can be used with TypeScript
absolute imports.- This defaults to
true. - The recommended config sets this to
false. This is subjective, but
it may encourage usage of a#-prefixed path to better delineate
between absolute project paths and dependency imports
- This defaults to
v1.3.2
Full Changelog: v1.3.1...v1.3.2
- Fixed a potential ESLint crash when the TSConfig file is misconfigured or otherwise had errors while loading
- Updated TSConfig resolution logic to use tsconfig-paths@^4. This should functionally work the same as before; however, please feel free to open an issue if I broke your setup. There were some potential config resolutions that could happen before that I consider essentially buggy, but we can evaluate on a case-by-case basis if you do not believe that is true.
v1.3.1
Full Changelog: v1.3.0...v1.3.1
- add tsconfig resolution based off current file evaluated
- this is now the default behavior, with the previous resolution
only finding up from the working directory remaining as a fallback.
- This is technically a potentially breaking behavior change; however,
it seems unlikely that this would cause additional issues that
TypeScript itself would not have complained about based off
the given TSConfigs.