Toru Nagashima

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.

Ah, I got it.

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

Yes. Because I had avoided breaking changes at that time. I will merge https://github.com/mysticatea/eslint-plugin-node/pull/211 after ESLint gets supporting Optional Chaining syntax, then I will release a new major version with...

Thank you for your report. Sounds like a bug in `@typescript-eslint/parser` rather than this plugin. The code `import {MyInterface} from` must be a parsing error and don't pass invalid AST...

You are right. The config is determined before iterating files, so we cannot switch shareable configs for each file. Please use `overrides` section and `plugin:node/recommended-module` / `plugin:node/recommended-script` to configure for...

Yes, you are right. Using this `errors` option will be a breaking change for ESLint. I will make a PR to update core rules if this is accepted.

escope has been making a writable reference for variable initializers, so I treated default parameters and default values of destructuring as same as that. Currently, references for initializers, default parameters,...

Yeah, it is by design. escope makes writable-references for variable-initializers. When it's used together with destructuring and default values, the variable has multiple writable-references for its initializer. So the `Reference`...

On `const { x = 10 } = { y: 15 };`, `x` has two initializers. 1. `x = 10` is not partial. 2. `{x} = {y: 15}` is partial....