Vscode: Запрос функции: отображать все ошибки и предупреждения в проекте для всех файлов, а не только для открытых.

@waderyan это запрос на добавление функций в конструктор, который мы обсуждали с командой TS.

Для справки - ссылка на проблему - https://github.com/Microsoft/TypeScript/issues/11229.

Ну, я просто использую задачу сборки с "problemMatcher": "$tsc-watch" (см. Https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchers) и все ошибки и предупреждения правильно отображаются в представлении «Проблемы». Это довольно приятный рабочий процесс, потому что изменения в открытых файлах сразу же замечаются из-за языкового сервера, но save запускает инкрементную компиляцию (с tsc --watch ), которая все еще занимает некоторое время, но я могу контролировать эту задержку, сохраняя / не сохраняя пока что.

какое-нибудь ETA на этом? Для этой функции открыто много проблем, и я не уверен, пропустил я что-то или нет: smile:

@ maxime1992 спасибо за продолжение. Это на нашем радаре. Точных сроков пока нет.

Я не понимал, что это можно сделать с помощью инфраструктуры задач, которая есть в VSCode. Все, что вам нужно сделать, это поместить это в свой файл tasks.json:

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", "."],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

Затем просто запустите его, и вы получите все ошибки по всему проекту в режиме просмотра проблем.

Я немного озадачен, почему это не отображается более заметно. Это супер полезно и круто.

@johnfn Отличное решение, большое спасибо. Я бы даже добавил аргумент "--noEmit", если единственная цель задачи - показать ошибки.

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", ".", "--noEmit"],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

@kevinjreece Вы можете использовать функцию семантической истории iTerm (https://www.iterm2.com/documentation-one-page.html), чтобы предотвратить «забавный танец между моим терминалом и кодом VS». Когда cmd нажимает на имя файла + номер строки, он автоматически открывает соответствующую строку в vscode!

Кто-нибудь знает, можно ли с помощью сочетания клавиш открывать файлы с ошибками / в панели «Проблемы»? Настоящая боль - постоянно переключаться между мышью и клавиатурой даже после выполнения задачи.

Вы можете открыть панель «Проблемы» с помощью Ctrl+Shift+M (или Cmd+Shift+M ), она находится в разделе «Сочетания клавиш» как «Показать проблемы» - это вы имеете в виду?

Нет, я бы хотел, чтобы ярлык переходил к следующему файлу с ошибкой, независимо от того, открыт он или нет.

Я искал расширение для этого, но API жестко заблокирован, команды не имеют доступа к MarkerService (отслеживает проблемы) каким-либо способом, который я могу видеть.

О, я вижу. Это могло быть весьма полезно. Похоже, что область Problems vscode в целом имеет много возможностей для улучшения.

кто-нибудь испытывает эту проблему https://github.com/Microsoft/vscode/issues/34412?
если одна и та же ошибка возникает между последующими сборками, он игнорирует ее

Трюк с tsc в задаче отладки не всегда возможен, например, в проекте Vue с пользовательскими загрузчиками Webpack для обработки файлов .vue ( tsc не может анализировать файлы Vue из коробки ).

Но вы можете найти способ избавиться от всех ошибок, просмотрев и скомпилировав свой проект в терминале VS Code.

Например, я сделал такой сценарий npm:
"live-check": "webpack --config ./build/webpack.dev.conf.js -w --display none",

И я запускаю его через "npm run live-check" в терминале VS, и у меня все ошибки появляются в реальном времени.

даже с решением от @johnfn я вижу ошибки только из открытых файлов :(.
Я вижу, что задача выполняется на вкладке вывода, но не показывает никаких ошибок

tasks.json:

{
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    "args": ["-w", "-p", ".", "--noEmit"],
    "showOutput": "silent",
    "isBackground": true,
    "problemMatcher": "$tsc-watch"
  }

tsconfig.json

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es2015",                       /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
    "module": "es2015",                       /* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. */
    // "lib": [],                             /* Specify library files to be included in the compilation:  */
    "allowJs": true,                          /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    "jsx": "react-native",                    /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    "sourceMap": true,                        /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    "outDir": "./build",                      /* Redirect output structure to the directory. */
    "rootDir": "./src",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    "removeComments": false,                  /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    "noImplicitAny": true,                    /* Raise error on expressions and declarations with an implied 'any' type. */
    "strictNullChecks": true,                 /* Enable strict null checks. */
    "noImplicitThis": true,                   /* Raise error on 'this' expressions with an implied 'any' type. */
    "alwaysStrict": true,                     /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    "moduleResolution": "node",               /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    "allowSyntheticDefaultImports": true      /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */

    /* Source Map Options */
    // "sourceRoot": "./",                    /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "./",                       /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  },
  "include": [
    "src/**/*",
    "./node_modules/react-native-dev-kit/**/*"
  ],
  "exclude": [
    "__tests__",
    "index.android.js",
    "index.ios.js",
    "build",
    "local_history",
    "node_modules"
  ]
}

Почему я не вижу ошибок из закрытых файлов (уверен, что ошибки есть)?

👍

Как сказал @apperside .. задача показывает ошибки только тогда, когда файл был изменен ..

Благодаря новой функции, которая отображает ошибки в рабочем пространстве на боковой панели, мы будем очень благодарны за эту работу вне коробки.

Похоже, что в последних версиях vscode формат задачи немного изменился. Новый формат:

        {
            "label": "Monitor TS Errors",
            "command": "./node_modules/.bin/tsc",
            "type": "shell",
            "args": ["--watch", "--project", "."],
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared"
            },
            "isBackground": true,
            "problemMatcher": "$tsc-watch"
        }

Вы запускаете задачу каждый раз, когда открываете VSCode? Или есть способ его автоматически запускать?

Я предполагаю, что последняя версия кода VS показывает количество ошибок на файл

Как я могу это отключить?

// Показывать ошибки и предупреждения для файлов и папок.
"issues.decorations.enabled": правда,

Проще говоря, ложь;)

15 февраля 2018 г. в 01:36 pabloli [email protected] написал:

Как я могу это отключить?

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/13953#issuecomment-365838054 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAy0aayEHkVuxumJRuZz-mdWmBvBhdn9ks5tU9B2gaJpZM4KaH3J
.

Это то, что я использую

{
  "label": "TSCompileAll",
  "type": "shell",
  "command": "./node_modules/.bin/tsc --watch --noEmit --project .",
  "problemMatcher": ["$tsc-watch"]
}

Это бесценно, мне интересно, можно ли сделать это по умолчанию или, по крайней мере, настройкой.

Можно ли автоматически запустить эту задачу в рабочей области или проекте?

Я использую это:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "tsc watch",
            "type": "shell",
            "command": "./node_modules/.bin/tsc",
            "isBackground": true,
            "args": ["--watch", "--noEmit", "--project", "www"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "never",
                "echo": false,
                "focus": false,
                "panel": "dedicated"
            },
            "problemMatcher": "$tsc-watch"
        }
    ]
}

Я использую это расширение для запуска задачи при запуске: https://marketplace.visualstudio.com/items?itemName=yukidoi.blade-runner

Я до сих пор не знаю, как сохранить ошибки файла (в панели «Проблемы») при его закрытии.

Было бы очень полезно иметь возможность сохранять проблемы, перечисленные на панели, после закрытия файла.

Есть ли у кого-нибудь способ решения этой проблемы? Для средних и крупных проектов может быть довольно сложно открывать каждый файл, чтобы убедиться в отсутствии ошибок.

Есть ли способ открыть все файлы сразу одной командой? Для меня это было бы приемлемым обходным путем.

@daarong У меня обычно в терминале работают eslint-watch, пока я кодирую vscode, чтобы проверить весь проект. Это не так хорошо, как наличие всей информации о линтинге в vscode, но это достойный запасной вариант, чтобы сразу увидеть, есть ли в каких-либо файлах вашего проекта ошибки.

Есть ли у кого-нибудь обходной путь для файлов java?
Я хочу видеть все ошибки всех файлов в панели задач в любое время, а не только ошибки открытых файлов.

Это шутка? У меня около 2000 файлов, я должен пойти и открыть их все вручную, чтобы найти ошибки ворса ???

Есть ли способ вызвать ts lint в коде vs? Я мог бы использовать e. tslint чтобы отобразить его в консоли.
Было бы здорово, если бы я мог запустить VS Code для сканирования всех файлов в папке src на наличие ошибок (синтаксис и линтер)
Другими словами: как открыть все файлы (ts) в папке src одновременно?

Не ищите в других папках, таких как node_modules. ... Просто для протокола. 😄
Может быть, было бы неплохо включить / исключить путь? ...

Около месяца назад у меня были маленькие красные значки рядом с моими файлами в средстве просмотра рабочей области. Теперь их больше нет, и я понятия не имею, как я это сделал. Либо новая версия VSCode изменила способ работы, либо я установил расширение, которое сломало его. Как заставить его снова работать? Я даже не слышал о tasks.json, и тот факт, что он работал раньше, подсказывает мне, что теперь это поведение по умолчанию.

Вот как вы можете увидеть все проблемы менее чем за 10 секунд.

Вы используете небольшую хитрость.

Открыть заменить все в файлах (Ctrl + Shift + H).

Заменять ; с участием ;

Хит заменить все. Вот и все. Теперь проверьте "Проблемы".

Предполагается, что все файлы имеют хотя бы одну точку с запятой. Для более крупных проектов, если вы получите предупреждение с просьбой уточнить поиск, просто введите то, что является общим для всех файлов, но нечасто присутствует.

Есть новости по этому поводу? Хотя ярлык Аджая работает, он кажется довольно хакерским. Похоже, это очевидная и легкая победа для VSC. Переключатель «Показать все ошибки / Показать ошибки для открытых файлов» - это все, что требуется.

Другая мысль, вместо того, чтобы это происходило автоматически при изменении файла. Я был бы полностью согласен с кнопкой на нижней панели или командой, которую я могу явно запустить, чтобы проверить все файлы.

Это правильно, я думаю, что проблема связана с координирующей службой TS, которая проверяет все открытые файлы и, с другой стороны, проверяет файлы, которые закрыты и обычно не проверяются автоматически, это правильно? Итак, простое решение - убедиться, что панель задач получает все проблемы TS из одного источника, правильно?

Видя, как проблема не решается командой vscode (?), Предложение:

Разве нельзя решить эту проблему с помощью надстройки или с помощью средства сопоставления задач vscode? Потому что тогда вы могли бы самостоятельно убедиться, что и когда будет отображаться панель проблем? Тогда вам просто нужно будет каким-то образом отключить vscode от показа своего материала? Может ли разработчик vscode сказать мне, будет ли что-то подобное работать?

Однако я по-прежнему считаю, что с этим должен работать сам vscode. Не похоже, что ошибки TS решаются сами собой, когда вы закрываете файлы ... Просто заставьте сервер TS обрабатывать все файлы, открытые или нет, должно делать трюки. Должен быть вариант, конечно, но вариант должен быть.

Как может быть, это не самая важная из всех проблем, которую нужно решить в первую очередь? IDE сломана, пока не будет исправлена.

Хорошо, это хакерское решение.
Используйте решение @plievone , заставив задачу использовать $ tsc-watch. Затем получите плагин, такой как AutoLaunch, чтобы запускать задачу каждый раз, когда открывается код Visual Studio. (https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch)

чтобы расширить предложение @mateuscb , может быть, что-то в контекстном меню файлового проводника было бы хорошо, если бы вы могли щелкнуть правой кнопкой мыши по определенной папке и сделать «найти проблемы в папке» было бы хорошим вариантом, поскольку это позволило бы Пользователь должен выбрать компромисс между прицелом и скоростью.

Не делайте предложения @ ajayRaghav37 , vscode зависнет.
Блин, я больше не буду писать ts код в будущем)

Есть какие-нибудь обновления или идеи о том, когда это будет запущено? Было бы здорово иметь эту функцию прямо из коробки.

ES-Lint представил новую задачу в VS Code. Вы должны включить его в настройках рабочего пространства.

"eslint.provideLintTask": true

Просто зайдите в меню терминала и выберите запустить задачу, затем выберите

eslint: lint целую папку.

Вы также можете автоматически исправить большинство проблем, выполнив следующую команду в терминале:

.\node_modules\.bin\eslint.cmd --fix .

Ссылка: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

Хотя мы все еще ждем сканера проблем в VS Code, это достаточно хорошая альтернатива, если вы используете eslint.

Действительно, очень необходимая функция для более крупных проектов. Любые обновления?

@ ajayRaghav37 , похоже, что eslint не может отлавливать опечатки, только правила линтинга:

https://github.com/typescript-eslint/typescript-eslint/issues/36#issuecomment -478820127

+1

Вверх это. Я также думаю, что должна быть возможность отключить встроенную проверку TS и линтинг и просто использовать результаты задачи сборки.

+1

Теперь я запускаю tsc --noEmit -w чтобы решить эту проблему.

Но я думаю, что было бы лучше поделиться ts-server с VSCode.

Но почему его так долго не реализовали?

Кто-нибудь здесь знаком с языковым сервером TS? Есть ли у LSP API способ передать это в IDE? Это проблема производительности? Очевидно, что люди увлечены отсутствием этой функции (я люблю), поэтому я думаю, что было бы интересно получить помощь сообщества, чтобы преодолеть финишную черту.

Но это если проблема здесь просто в нехватке кадров в команде VS Code.

Если проблема в другом (большее влияние на архитектуру VS Code, требуется изменение LSP, неясное влияние на производительность, соображения UX), знание этого поможет объяснить, почему эта, казалось бы, простая функция занимает так много времени.

В этом выпуске я вижу различные комментарии о том, что ответственность за это лежит на команде TypeScript, а не на команде Visual Studio Code. Но это также проблема со встроенной функцией @ ts-check в VS Code. Обходные пути, упомянутые в этом сообщении, для использования задачи, выполняющей команду tsc, не работают для меня, потому что у меня не установлен tsc (я использую только @ ts-check и jsdoc).

Раньше я щелкал каждый файл в своем проекте, чтобы найти ошибки. Это было утомительно, но, по крайней мере, проблемы не исчезли с боковой панели после того, как я закрыл файл. После одного из обновлений за последние несколько месяцев появилась эта проблема: # 73153.

Как может быть, это не самая важная из всех проблем, которую нужно решить в первую очередь? IDE сломана, пока не будет исправлена.

Я согласен.

Когда?

Принятое выше решение работает, но некоторые поля устарели.

{
      "label": "Watch TS Errors",
      "type": "shell",
      "command": "tsc",
      "args": ["-w", "-p", ".", "--noEmit"],
      "isBackground": true,
      "problemMatcher": "$tsc-watch"
}

Работает для меня.

Также см. Https://code.visualstudio.com/docs/editor/tasks для создания файла tasks.json, если у вас его еще нет.

Можно ли отключить встроенный TS-сервер VS Code при запуске tsc качестве такой задачи сборки? Причина, по которой я спрашиваю, заключается в том, что в противном случае мы получим два набора ошибок: ошибки встроенного сервера TS и ошибки задачи, а иногда они не синхронизированы.

IDE сломана и непригодна для работы над проектами Typescript. Поэтому я должен придерживаться версии 1.28.2 и отключить обновления.

Странно, но раньше как-то работало. Что произошло? И когда снова заработает? Прошел уже год, а изменений нет ...

Октябрь 2019 года, и это все еще на свободе.

3 года на функцию, которую предлагают другие IDE .... NNNNICCCEEEEEEEEEEEEEE

3 года на функцию, которую предлагают другие IDE .... NNNNICCCEEEEEEEEEEEEEE

Помните, что VSCode не является IDE. Это нечто среднее между редактором и IDE.
Во всяком случае, я надеюсь, что они это сделают

3 года на функцию, которую предлагают другие IDE .... NNNNICCCEEEEEEEEEEEEEE

Помните, что VSCode не является IDE. Это нечто среднее между редактором и IDE.
Во всяком случае, я надеюсь, что они это сделают

Какая разница. Тем не менее, я даже не могу запустить эту чертову задачу, чтобы проверить файлы ts.

Представленное руководство похоже на изучение совершенно нового долбаного языка программирования.
Мы действительно работаем и производим, у меня нет времени тратить время на изучение всей подножки ерунды с веб-пакетами (и аналогичными инструментами), чтобы создать сценарий, который проверяет мои ts-файлы в среде IDE (я НАЗЫВАЮ ЭТО IDE в порядке?), Который не работает. t даже поддерживает язык, правильно созданный теми же создателями IDE ....

что за фигня

что за фигня

Для некоторой точки зрения:

Microsoft создала программное обеспечение и раздала его бесплатно.
Это программное обеспечение полезно миллионам людей, которые за него благодарны.
Microsoft не принуждает вас использовать это программное обеспечение.

Вы злитесь на них за то, что они дают вам что-то бесплатно, потому что это не так идеально, как могло бы быть теоретически.

Кроме того, он использует тот же язык "IDE", а IDE имеет открытый исходный код и принимает запросы на вытягивание ...

Я наблюдал за этим уже давно, все еще жду лучшего способа отслеживания ошибок и предупреждений, и я использую его с момента публичного запуска.

При этом VS Code, на мой взгляд, несомненно, лучшая IDE для разработки JS / TS - черт возьми, это может быть даже лучший продукт MS, уступающий только Github. Определенно произошли улучшения в функциях и производительности, и огромное количество расширений меня очень радует. Да, документация могла бы быть лучше, но вы можете сказать это обо всех имеющихся технических документах.

Я уверен, что команда VS Code постоянно работает над улучшением инструментов и интеграции.

И я считаю, что мы все еще можем просить о новых функциях или продолжать вежливо предлагать эту.

Добавление к обходному пути - похоже, что теперь есть предварительно настроенная задача для отслеживания вывода tsc -w. На Mac Терминал -> Настроить задачи ... -> tsc: watch - tsconfig.json. Затем нажмите ctrl + shift + B и запустите задачу.

Три года спустя ... Есть новости?

В разгаре масштабного рефакторинга. Я не понимал, что, закрыв все затронутые файлы, я больше не увижу все ошибки :-(

3 года и все еще открыт: танцор:

3 года и все еще открыт

Ура, случайные голоса против идиотов.

В любом случае это неприятная проблема давай !!! Вы ведь понимаете, что в серьезном бизнес-проекте есть сотни файлов?
Как мы должны их мысленно отслеживать?

Это одна из основных функций, для которой люди используют IDE ...

И теперь кажется, что он время от времени распространяется также на визуальную студию и ее intellisense.

Кстати, кажется, что задачи, по крайней мере, смягчают ее, а для файлов ts, похоже, также доступны некоторые сценарии управления. Я не знаю, установлены ли они всеми расширениями angular / typescript из диспетчера расширений в vscode, но если вы выполните поиск в строке поиска задач (которая показана [здесь]) (https://code.visualstudio.com / docs / editor / tasks) вы можете искать что-то вроде часов или что-то в этом роде, которое помогает каждый раз, когда вы компилируете (кажется, он делает это вместе с обычным процессом компиляции, что тоже является другой задачей)

Я считаю вкладку "Проблемы" бесполезной из-за этого, поэтому никогда ею не пользуюсь. Вместо этого я запускаю какую-то команду в терминале, которая действительно дает мне то, что мне нужно. Например, если я все ошибки компилятора для проекта, я запускаю tsc -w . Я либо хочу увидеть все проблемы в моем проекте, либо их нет. Меня не волнует, открыт файл или нет. Это не имеет значения.

Ну если кому-то так важно видеть ошибки только для открытых файлов во вкладке Problems , пусть будет.

Но не могли бы вы создать еще одну вкладку, скажем Build Output как в Visual Studio.

На этой вкладке будут отображаться ошибки и предупреждения от компилятора в виде простого однострочного текста, а двойной щелчок по нему откроет файл и поместит курсор прямо в строку с ошибкой.

Также ярлыки F4 / Shift-F4 отлично подходят для перехода к следующей / предыдущей ошибке (но это не так важно)

Просто полностью очищайте эту вкладку и заполняйте ее заново после каждой компиляции. Этого было бы достаточно.

А может кто-нибудь сможет создать для этого расширение?

Я использую расширение «Open Matching Files», чтобы открывать все файлы .ts. Это немного тяжеловато, но, по крайней мере, выполняет свою работу.

Я думаю, это из-за того, что сервер машинописного языка является однопоточным и не ведет себя как компилятор C #.
Все еще жду этой функции, потому что иногда я открываю файл и пытаюсь найти тип по имени, используя палитру команд с #, и ничего не происходит 😞

Для тех, кто хочет жить на грани, следующая сборка инсайдеров VS Code представляет параметр "typescript.tsserver.experimental.enableProjectDiagnostics" который позволяет сообщать об ошибках в рамках экспериментального проекта.

Обратите внимание, что это еще не готово к производству! Известны проблемы с производительностью для более крупных проектов, и он может нарушить ваш intellisense.

Если у вас возникла проблема при использовании этого параметра, откройте новую проблему

Для тех, кто хочет жить на грани, следующая сборка инсайдеров VS Code представляет параметр "typescript.tsserver.experimental.enableProjectDiagnostics" который позволяет сообщать об ошибках в рамках экспериментального проекта.

Обратите внимание, что это еще не готово к производству! Известны проблемы с производительностью для более крупных проектов, и он может нарушить ваш intellisense.

Если у вас возникла проблема при использовании этого параметра, откройте новую проблему

хорошая работа ~

Где мы можем проверить прогресс этой функции? Я с нетерпением жду его добавления в стандартную редакцию кода VS, когда он будет готов.

Для тех, кто хочет жить на грани, следующая сборка инсайдеров VS Code представляет параметр "typescript.tsserver.experimental.enableProjectDiagnostics" который позволяет сообщать об ошибках в рамках экспериментального проекта.

Обратите внимание, что это еще не готово к производству! Известны проблемы с производительностью для более крупных проектов, и он может нарушить ваш intellisense.

Если у вас возникла проблема при использовании этого параметра, откройте новую проблему

Спасибо всем участникам Visual Studio Code за вашу замечательную работу.

Для тех, кто хочет жить на грани, следующая сборка инсайдеров VS Code представляет параметр "typescript.tsserver.experimental.enableProjectDiagnostics" который позволяет сообщать об ошибках в рамках экспериментального проекта.

Как это работает с другими линтерами?

У меня возникла проблема, когда каждый раз, когда я включаю "typescript.tsserver.experimental.enableProjectDiagnostics" , линтер Typescript в конечном итоге оказывается в кроличьей норе, просматривая node_modules и выкапывая сотни ошибок из файлов распространения, даже если "exclude" в tsconfig.json содержит "node_modules" . Я не совсем понимаю, как это отладить.

Я также получаю тот же эффект, что и @vdh - мой VSCode анализирует всю мою папку node_modules и запускает eslint для каждого файла.

Моя конфигурация eslint / редактора:

    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    },
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        "typescript",
        "typescriptreact"
    ],
    "[javascript]": {
        "editor.formatOnSave": false
    },
    "[javascriptreact]": {
        "editor.formatOnSave": false
    },
    "[typescript]": {
        "editor.formatOnSave": false
    },
    "[typescriptreact]": {
        "editor.formatOnSave": false
    },
    "eslint.enable": true

Похоже, что первым делом действительно должно быть то, что любой файл с node_modules на своем пути должен игнорироваться, по крайней мере, для действий при сохранении.

Это очень ценная функция.
У меня такое же поведение, как у @Martaver @vdh .
«Решил» это на данный момент, добавив фильтры

!*node_modules, !*.vscode

в вид терминала. (только визуально отличается). На случай, если кому-то интересно поиграть с этим.

@ blackfan23 немного похоже на подметание пыли ковриком: D

@Martaver Согласен. Что-то вроде:

"typescript.tsserver.experimental.enableProjectDiagnostics.ignores": [
  "**/node_modules/**"
]

было бы идеально. Какое-то дерьмо видеть в проекте более 1000 проблем, когда их на самом деле 0.

@ blackfan23 Это не вариант из-за чрезмерного оттока ЦП, вызванного переходом в node_modules

@vdh Я установил для skipLibCheck значение true в tsconfig, и на вкладке "проблемы" перестали отображаться ошибки от node_modules.

Однако, исходя из этого потока stackoverflow , включение этого параметра ухудшает проверку типов. Будем признательны, если кто-то из разработчиков кода VS или машинописного кода может пролить свет на плюсы и минусы включения этой опции.

@mjbvz
Работает отлично! Благодарность!
Можем ли мы выполнить «Исправить все» для этих ошибок с помощью одной команды?

А как насчет других языков, а не машинописного текста? Например, у меня есть сотни файлов PHP в проекте, и я могу видеть проблемы, о которых сообщает расширение Intellephense для отдельного файла, но на самом деле я хочу запустить диагностику для всей рабочей области.

Да, это также вызывает проблемы, когда ESLint делает то же самое в node_modules ("ESLint: Failed to load config", поскольку он просматривает там каталоги). На самом деле нужен черный список или что-то в этом роде, вместо того, чтобы пытаться исправить эту ошибку для каждого линтера.

Исключение node_modules было бы исправлением №1 :)

Кажется, что это работает, но - ваш размер может отличаться, и, конечно же, нет гарантии:

Учитывая, что у вас есть машинописный текст 3.9.2 в вашем package.json и вы выбрали эту версию из своей рабочей области в VSCode:

1. https://www.npmjs.com/package/patch-package

2. : ./patches/typescript+3.9.2.patch

diff --git a/node_modules/typescript/lib/tsserver.js b/node_modules/typescript/lib/tsserver.js
index 2b6f035..ac6c9b4 100644
--- a/node_modules/typescript/lib/tsserver.js
+++ b/node_modules/typescript/lib/tsserver.js
@@ -149353,7 +149353,7 @@ var ts;
                     return;
                 }
                 // No need to analyze lib.d.ts
-                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts"); }); // TODO: GH#18217
+                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts") && !ts.stringContains(value, "node_modules"); }); // TODO: GH#18217
                 if (fileNamesInProject.length === 0) {
                     return;
                 }

1. npm install или yarn
2. Перезапустить VSCode

= прибыль?

@mjbvz Я попытался включить это, и я вижу довольно высокую

Это не длится вечно, но сейчас мои поклонники MacBook раскручиваются настолько, что я бы скорее выключил его, чем включил.

Проводились ли до сих пор какие-либо исследования того, почему "typescript.tsserver.experimental.enableProjectDiagnostics" всегда ныряет во все файлы внутри node_modules , несмотря на наши различные неудачные попытки установить конфигурации линтера, чтобы избежать node_modules ?

Это разочаровывает, потому что эта потенциально потрясающая функция полностью уничтожена чрезмерным оттоком ЦП, вызванным повторением ненужных файлов и каталогов… 😢

Я видел те же проблемы @vdh, упомянутые выше, с ошибками TypeScript из node_modules появляющимися на панели PROBLEMS - не был уверен, сообщать ли об ошибке или это просто ошибка Конфигурация, которую я вызвал.

Я пробовал различные настройки tsconfig.json , например:

"exclude": ["node_modules", "./node_modules/*"],

Я не совсем понял, есть ли закономерность в том, вижу ли я проблему или нет. Я подозреваю, что некоторые вещи могут происходить / происходить:

• Казалось, что это случайным образом приходит и уходит, иногда перезапуск vscode помогал немного, но он вернется позже.
• Оказалось, что на одни проекты повлияли больше, чем на другие.
• Я не вижу проблемы прямо сейчас, так что, возможно, недавнее обновление что-то исправило? Я все еще использую версию для инсайдеров.

Не совсем уверен в приведенных выше пунктах, возможно, я просто сбит с толку. Просто добавляю еще один, возможно, относящийся к делу анекдот. Если некоторые из нас все еще сталкиваются с проблемой в текущих версиях, возможно, стоит зарегистрировать новую проблему. Я еще не сделал этого, но я не совсем уверен в этом.

У меня была такая же проблема, и моим решением в # 90430 было использование typescript-tslint-plugin .

@enko TSLint устарел в пользу ESLint с 2019 года , поддержка плагина для устаревшего линтера не является хорошим решением этой проблемы.

Мне пришлось отключить typescript.tsserver.experimental.enableProjectDiagnostics потому что это сделало

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }

очень медленно (2 минуты для сохранения одного файла).

Я также заметил случайные ошибки TS из node_modules, которые появлялись / исчезали.

На самом деле существует рабочий обходной путь, если вы правильно установите applyTo в задачах.

Ниже показана полная рабочая задача, которая будет наблюдать за компиляцией и сообщать о проблемах на панель «Проблемы» даже для файлов, которые в данный момент не просматриваются :

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "tsc watch",
      "type": "shell",
      "command": "tsc",
      "isBackground": true,
      "args": ["--build", "--watch"],
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "panel": "dedicated"
      },
      "problemMatcher": {
        "base": "$tsc-watch",
        "applyTo": "allDocuments"
      }
    }
  ]
}

@ samesfahani-tuplehealth. Отредактируйте свой комментарий, указав, как эта задача напрямую связана с enableProjectDiagnostics , или перефразируйте, что это временное решение, а не исправление. Различие между обходными путями и реальными фактическими исправлениями важно делать при комментировании цепочек проблем.

@vdh Достаточно enableProjectDiagnostics ; проблема заключалась в том, что мы не можем просматривать проблемы во всем проекте даже для файлов, которые в данный момент не просматриваются.

Что касается проблемы с нежелательными ошибками node_modules , я создал новую проблему, чтобы специально обсудить это: https://github.com/microsoft/vscode/issues/103539

@vhd / @martaver / @ blackfan23 / @SupremeTechnopriest / @patroza / @jgoux / кто-нибудь еще ... Если бы вы могли добавить еще какие-либо подсказки, которые могли бы помочь в этой проблеме, это может помочь в ее решении, надеюсь.

Та же проблема, что и @jgoux , он не работает с "source.fixAll.eslint": true - eslint начинает проверять каждый файл в проекте, а не только открытые файлы, и перепроверяет весь проект при каждом отдельном изменении. VSCode просто зависает. Понятия не имею, почему он изменяет поведение ESLint по умолчанию, но это действительно блокировщик

"typescript.tsserver.experimental.enableProjectDiagnostics" действительно следует исправить и улучшить. Это сделало бы машинописный текст более мощным, чем уже есть.

Решение, опубликованное @ samesfahani-tuplehealth, работает очень хорошо. Это очень важно для меня, когда я перемещаю импортированный тип из одного файла в другой и мне нужно найти все, что не удалось импортировать. Я не вижу высокой загрузки процессора, но если это так, вы можете просто запустить его, когда вам это нужно.

@phatmann Это обходной путь , а не решение. Обход этой функции и использование вместо нее _ другой, совершенно другой функции _ не _ способ исправить проблемы с производительностью. Я ненавижу настойчивость в этом, но я бы предпочел, чтобы шум отвлекал внимание от исправления этой замечательной (но экспериментальной) функции. Он мог бы стать чем-то невероятно полезным, если бы получил заслуженное внимание.

@Vdh ты конечно прав. (И на самом деле более простая версия задачи, встроенная задача tsk: watch, одинаково хорошо работает для обходного пути). Мое замешательство заключается в следующем: обходной путь настолько эффективен и действенен, что я не чувствую необходимости в фактической функции, упомянутой в этом выпуске. Я что-то упускаю?

@phatmann Если бы я хотел запустить задачу просмотра Typescript, я бы уже мог это сделать. Речь идет не только о проведении проверок TS. Он выполняет все проверки VSCode для каждого файла проекта. Typescript, ESLint, CSpell и т. Д. Это действительно мощно и полезно знать, что даже если я забыл открыть файл, я могу найти ошибки во всем проекте (без запуска каждого линтера вручную для всех файлов, возможно, даже придется прибегать к выполнению это внешне в терминале).

Единственный серьезный недостаток на данный момент заключается в том, что он переусердствует с запуском буквально каждого файла, включая обычно запрещенные папки, такие как node_modules .

В тот момент, когда вы ищете, как что-то сделать с vscode, но получаете 4-летнюю открытую проблему ... 😢

Сколько денег и куда мне отправить?

Тем, у кого есть проблемы с процессором или проблемы с этой функцией сканирования node_modules, убедитесь, что у вас НЕ есть общая или "рабочая область" tsconfig.json где-то вроде корня вашего репозитория, если она не включает:

"files": []

в противном случае по умолчанию включаются все файлы TypeScript, расположенные в или ниже папки, содержащей tsconfig, что, вероятно, приведет к анализу слишком большого количества файлов.

Эта функция отлично работает для меня в большом монорепозитории, использующем рабочие области пряжи и составные «проекты» машинописного текста.

Отличный совет @dinofx. Кроме того, вы можете использовать include и exclude , вместо files , согласно документации .

      "include": ["src/**/*"],
      "exclude": ["node_modules", "test/**/*"],

Это правильно, но нет необходимости исключать то, что не соответствует глобусам "include".

"files": [] более сжато для файла tsconfig.json "рабочей области" (который просто ссылается на кучу других файлов tsconfig.json). Это плохо документировано, но вам нужно назвать файлы конфигурации для пакетов и рабочей области tsconfig.json , иначе многие функции не будут работать должным образом (эти функции, поиск ссылок, рефакторинг и т. Д.).

Для общей конфигурации, расширенная, это, вероятно , лучше назвать это что - то вроде tsconfig.browser.json , tsconfig.node.json и т.д. Это именование позволяет что - либо когда - либо забот о "files" или "includes" , так что вы, скорее всего, можете их опустить.

@dinofx Проблема обхода файлов не ограничивается только Typescript. Кроме того, не все используют монорепозиторий.