eslint-plugin-import: Using Typescript 5.0's array extends in tsconfig causes an error while linting
Typescript 5.0 now supports combining TSConfigs using array syntax in extends
Error log:
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received an instance of Array
Occurred while linting G:\gits\NutchapolSal\musicbot\botCacheInit.js:1
Rule: "import/namespace"
at new NodeError (node:internal/errors:393:5)
at validateString (node:internal/validators:163:11)
at Object.join (node:path:429:7)
at loadTsconfig (G:\gits\NutchapolSal\musicbot\node_modules\tsconfig-paths\lib\tsconfig-loader.js:93:39)
at loadSyncDefault (G:\gits\NutchapolSal\musicbot\node_modules\tsconfig-paths\lib\tsconfig-loader.js:40:18)
at tsConfigLoader (G:\gits\NutchapolSal\musicbot\node_modules\tsconfig-paths\lib\tsconfig-loader.js:26:22)
at readTsConfig (G:\gits\NutchapolSal\musicbot\node_modules\eslint-plugin-import\lib\ExportMap.js:804:521)
at isEsModuleInterop (G:\gits\NutchapolSal\musicbot\node_modules\eslint-plugin-import\lib\ExportMap.js:806:277)
at ExportMap.parse (G:\gits\NutchapolSal\musicbot\node_modules\eslint-plugin-import\lib\ExportMap.js:798:233)
at ExportMap.for (G:\gits\NutchapolSal\musicbot\node_modules\eslint-plugin-import\lib\ExportMap.js:797:201)
This also effects import/namespace, import/named, import/default, import/no-named-as-default, and import/no-named-as-default-member.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 18
- Comments: 23 (10 by maintainers)
Adding this to my
package.jsonresolves the issue for me:I think that’s the misunderstanding. It’s the decision you’ve made, as is your full right, but still your decision, not mine. You have a PR open with 90+ comments, 25 participants all of whom are not in support of your proposition. So no, I don’t think I’m practicing any entitlement or laziness. Rather, I’ve spent a fair amount of time attempting to guide you towards a different perspective which, as unbelievable as it appears to you, is not an unreasonable perspective and is in the interest of the community you lead. 🤷
I’m not really interested in putting any further effort into this sort of a cause. My organisation will see if
eslint-plugin-iis suitable, otherwise we’ll forfeit linting imports altogether.It’s something you want, and I’ve given you a path to getting what you want - and instead of you just filing the issue, you said “psh, you do it”.
Ouch - not to bring that discussion over here, but maintaining Node v4 support is not something I’ve come across before. That is your decision though, but I don’t think that
tsconfig-pathshas any obligation to backport to v3 given the fix is for new major releases of a tool. It would be nice, but I’d expect the support for TS 5 to be limited totsconfig-pathsv4.@WoodyWoodsta its a nonstarter, see #2447, so hopefully they go with option 1.
tsconfig-paths doesn’t support this yet, and even if they added that support, they’d need to backport it to v3 for us to be able to use it.
For those who suffer from this problem, I recommend eslint-plugin-i. It uses get-tsconfig instead of tsconfig-paths, which may fix this issue.
Nobody has any obligation to do anything 😃 i think their v4 platform drop was a mistake, and another park forward is for v4 to restore node 4 support (which it could do in a semver minor).
If tsconfig-paths maintainers would accept a PR restoring that support, I’d be happy to author it, so this plugin could update to v4.
For yarn it would be
resolutionslike:Using overrides/resolutions is a perfectly reasonable approach, assuming the breaking changes don’t affect our usage of the package.
Good luck to you.
@ljharb Open an issue then.
@ljharb You marked my solution as spam? WTF I just provided a VIABLE solution. As the leader of such a large community, we, as users, are grateful for your contributions to eslint. However, what you have done is chilling.
Yep, that’s indeed the kind of entitlement and laziness that explains why forks aren’t sustainable.