Безопасность типов eslintrc в VSCode с использованием аннотаций jsdoc, импортирующих объявления машинописного текста ⇐ Javascript

[Гость]

Как заставить VSCode проверять синтаксис .eslintrc.js и выполнять автодополнение? Мне удалось использовать следующую структуру для файла конфигурации js, который соответствует пользовательскому синтаксису, определенному моим собственным приложением, но когда я пытаюсь применить тот же трюк к Linter.BaseConfig, импортированному из «eslint», это ничего не делает.

/** @typedef {import("eslint").Linter.BaseConfig} BaseConfig */ /** @param {BaseConfig} c */ // не используется функция castBaseConfig(c) {возврат c} модуль.exports = castBaseConfig({ env: {браузер: ложь, es2019: правда, узел: правда}, ignorePatterns: ["dist", "jsdoc", "out", "out2", "public"], расширяется: "eslint: рекомендуется", parserOptions: {ecmaVersion: "latest"}, // и т. д }) Обратите внимание, что node_modules/@types/eslint/index.d.ts содержит export namespace Linter {interface BaseConfig {...}} с определениями полей для env, parserOptions, плагины, правила (через HasRules) и т. д. так что, похоже, это должно работать. Это не проблема поиска файлов для node_modules или index.d.ts, поскольку во всплывающей подсказке для type BaseConfig говорится, что он расширяется до Linter.BaseConfig , но, похоже, не происходит никакой проверки типов и никакие дополнения для конкретного типа не работают.

Для другого моего файла, где я использую этот трюк, определение типа, импортированное с помощью /** @typedef {import("../lib/config").MultiConfig} MultiConfig */, корректно применяется: напр. он жалуется, если port является строкой, а не числом, или если требуемое свойство отсутствует, или если присутствует неизвестное свойство, а Ctrl+пробел предлагает оставшиеся неуказанные свойства для соответствующего контекста.< /п> Может ли это быть связано с различиями в определениях? Например. интерфейс и тип.