mysticatea / eslint-plugin-node

Additional ESLint's rules for Node.js
MIT License
962 stars 171 forks source link

[feature request]: functional `resolvePackage` option/setting support #186

Open JounQin opened 5 years ago

JounQin commented 5 years ago

Motivation: I'm always using TypeScript personally, for most packages we can use following settings:

{
  resolvePaths: [path.resolve('node_modules/@types')],
  tryExtensions: [
    '.ts',
    '.tsx',
    '.d.ts',
    '.vue',
    '.js',
    '.jsx',
    '.json',
    '.node',
  ],
}

But it won't work for scoped packages like @babel/core, its typed definition is under @types/babel__core directory, so resolvePaths will not work for it. Of course, we can use allowModules for workaround, but it could be a mistake if we forget to install the @types/babel__core module.

mysticatea commented 5 years ago

In my understanding, when we install @types/foo, we have installed foo as well because @types/foo doesn't contain any implementation.

So resolvePaths: [path.resolve('node_modules/@types')] isn't needed.

JounQin commented 5 years ago

@mysticatea We may only import types of foo, then there is no need to install foo itself.

And also, unist is a package which only has definitions without npm package.

unist (404) @types/unist

mysticatea commented 5 years ago

Ah, I got it.

mysticatea commented 5 years ago

This enhancement needs design because ESLint doesn't support function type in rule options.

JounQin commented 5 years ago

@mysticatea Is it possible to integrate with the resolvers for eslint-plugin-import?

https://github.com/alexgorbatchev/eslint-import-resolver-typescript

This resolver could help, or we can simply wrap it.