-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[no-unused-modules] The "path" argument must be of type string. Received undefined #1931
Comments
Thanks for the report! A PR with a failing test case would be most helpful. |
@ljharb I took a quick look at this in the process of diagnosing eslint/eslint#13789. The While end users won't hit the exception described here anymore, the This use case seems worthy of an RFC for a first-class supported API. Could it fit as part of the pre-linting hook for plugins that's been discussed in the parallel linting RFC? The import and TypeScript plugins are the two I'm aware of that most need an API for that, but I'm not yet sufficiently familiar with their respective implementation details to know exactly what's needed. That's been on my to-do list since it's at least a friction point if not a blocker for parallel linting. |
@btmills thanks a lot for confirming - I'm glad v7.12.1 fixes it. I would love an officially supported API so we don't have to use internals any more. I'm not sure when I'll have time to write an RFC; hopefully I have a good chunk of time before v8 is imminent :-) |
@ljharb
I am using also eslint-import-resolver-webpack. I think that this issue is connected to this breaking change in webpack 5. The error occurs after I upgraded webpack to version 5. Webpack 5 does not provides polyfills now so I added fallbacks for node libraries like this: resolve: {
fallback: {
fs: false,
path: false, // path fallbacks as boolean
stream: require.resolve('stream-browserify')
}
} When I fallback path with polyfill (previously used in webpack 4), the error will disappear:
resolve: {
fallback: {
fs: false,
path: require.resolve('path-browserify'), // path fallbacks as polyfill
stream: require.resolve('stream-browserify')
}
} |
@btmills @ljharb EDIT: above workaround (path fallbacks as polyfill) is working only in one of my libraries, but it is not working in two others. Resolving in same error as it is in the name of this issue: ESLint: Resolve error: TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined (import/namespace) These libraries have the same dependecies with regards to eslint: $ npm ls eslint eslint-config-airbnb eslint-import-resolver-webpack eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-mocha eslint-plugin-react eslint-plugin-react-hooks babel-eslint
+-- babel-eslint@10.1.0
+-- eslint@7.15.0
+-- eslint-config-airbnb@18.2.1
+-- eslint-import-resolver-webpack@0.13.0
+-- eslint-plugin-import@2.22.1
+-- eslint-plugin-jsx-a11y@6.4.1
+-- eslint-plugin-mocha@8.0.0
+-- eslint-plugin-react@7.21.5
`-- eslint-plugin-react-hooks@4.2.0
|
I finally found out, what is probably going on. My library where the mentioned workaround is working does not use a function as external. But my two others libararie does, so there was an issue with passing undefined (and not string) to the argument of For compatibility issue of eslint-import-resolver-webpack I am creating new issue #1966, as I am getting new error now:
My function for resolving external is looking like this: // there was change of API in webpack 5
// webpack 4 version looks line this
// function(context, request, callback) {
function({context, request}, callback) {
const modulePath = path.join(context || '', request || '');
if (/node_modules[/\\]/.test(modulePath)) {
const splittedPath = modulePath.split(/node_modules[/\\]/);
if (splittedPath && splittedPath.length > 0) {
// if request is not a relative path starting with dot (.), use request instead of the whole module path
const externalModulePath = /^\./.test(request) ? splittedPath[splittedPath.length - 1] : request;
// the externalized module is referenced as a commonjs module
return callback(null, `commonjs ${externalModulePath}`);
}
}
// Continue without externalizing the import
callback();
} |
Closing, since the original issue is resolved. |
While writing imports in VSCode recently, I started to get errors throwm from eslint that appear to originate from eslint-plugin-import. Here's the strack trace from the output panel: ``` [Error - 3:52:43 PM] TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined at validateString (internal/validators.js:124:11) at isAbsolute (path.js:1029:5) at isAbsolute (/path/to/repo/node_modules/eslint-plugin-import/src/core/importType.js:17:10) at typeTest (/path/to/repo/node_modules/eslint-plugin-import/src/core/importType.js:92:7) at resolveImportType (/path/to/repo/node_modules/eslint-plugin-import/src/core/importType.js:105:10) at reportIfMissing (/path/to/repo/node_modules/eslint-plugin-import/src/rules/no-extraneous-dependencies.js:170:7) at commonjs (/path/to/repo/node_modules/eslint-plugin-import/src/rules/no-extraneous-dependencies.js:267:7) at checkSourceValue (/path/to/repo/node_modules/eslint-module-utils/moduleVisitor.js:29:5) at checkSource (/path/to/repo/node_modules/eslint-module-utils/moduleVisitor.js:34:5) at /path/to/repo/node_modules/eslint/lib/linter/safe-emitter.js:45:58 ``` I am able to trigger this consistently when writing an import, before I start the open quote, like this: ``` import foo from ``` I found import-js#1931 which pointed at a problem in the resolvers causing this problem. We do use some custom resolvers with this plugin, so I tried disabling that but the problem persisted. Thankfully, I was able to reproduce this error in the test suite. It would be good if this plugin handled this scenario gracefully instead of throwing an error.
After ESLint upgrade
7.11.0
➜7.12.0
I noticed an error:@typescript-eslint/parser
The origin issue (eslint/eslint#13789) was opened inESLint project, because it was unclear where it came from.
I could narrow the Error down to import/no-unused-modules:
Im willing to provide you any additional info or console.debug() output that could help :D Let me know
Config details (if nedded):
Configuration `.eslintrc.json`
Configuration `tsconfig.eslint.json`
Configuration `tsconfig.base.json`
package.json
The text was updated successfully, but these errors were encountered: