Vscode: Solicitud de función: muestra todos los errores y advertencias en el proyecto para todos los archivos, no solo los abiertos

@waderyan esta es una solicitud de función para el trabajo de construcción que discutimos con el equipo de TS.

Como referencia, aquí hay un enlace al problema: https://github.com/Microsoft/TypeScript/issues/11229

Bueno, solo uso una tarea de compilación de observación con "problemMatcher": "$tsc-watch" (consulte https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchers) y todos los errores y las advertencias se muestran correctamente en la vista Problemas. Es un flujo de trabajo bastante agradable porque los cambios en los archivos abiertos se notan de inmediato debido al servidor de idioma, pero guardar desencadena la compilación incremental (con tsc --watch ) que todavía lleva un tiempo, pero puedo controlar esa latencia guardando / no guardando todavía.

¿Alguna ETA sobre esto? Hay muchos problemas abiertos para esa función y no estoy seguro de si me perdí algo o no: sonríe:

@ maxime1992 gracias por el seguimiento. Esto está en nuestro radar. Aún no hay un cronograma firme.

Algo de lo que no me di cuenta es que es posible hacer esto con la infraestructura de Tareas que tiene VSCode. Todo lo que tienes que hacer es poner esto en tu tasks.json:

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

Luego, ejecútelo y obtendrá todos los errores en todo su proyecto en la vista de problemas.

Estoy un poco perplejo por qué esto no se muestra de manera más prominente. Es súper útil y genial.

@johnfn Gran solución, muchas gracias. Incluso agregaría el argumento "--noEmit" si el único propósito de la tarea es mostrar los errores

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

@kevinjreece Puede utilizar la función de historial semántico de iTerm (https://www.iterm2.com/documentation-one-page.html) para evitar el "baile divertido entre mi terminal y VS Code". Al hacer clic en cmd en el nombre del archivo + número de línea, se abre automáticamente la línea correspondiente en vscode.

¿Alguien sabe si es posible abrir archivos con errores / en el panel Problemas con un atajo de teclado? Es un verdadero dolor tener que cambiar entre el mouse y el teclado, incluso después de ejecutar la tarea.

Puede abrir el panel Problemas con Ctrl+Shift+M (o Cmd+Shift+M ), está debajo de Atajos de teclado como "Mostrar problemas". ¿Eso es lo que quiere decir?

No, me gustaría un acceso directo para ir al siguiente archivo que tiene un error, esté abierto o no.

Estaba buscando hacer una extensión para hacerlo, pero la API está bloqueada firmemente, los comandos no tienen acceso al MarkerService (rastrea problemas) de ninguna manera que pueda ver.

Oh ya veo. Eso podría resultar muy útil. Parece que el área Problems de vscode en general tiene muchas oportunidades de mejorar.

¿Alguien tiene este problema https://github.com/Microsoft/vscode/issues/34412?
si ocurre exactamente el mismo error entre compilaciones posteriores, lo ignora

El truco con tsc en una tarea de depuración no siempre es posible, por ejemplo, en un proyecto de Vue con cargadores de paquetes web personalizados para manejar archivos .vue ( tsc no puede analizar archivos de Vue de fábrica ).

Pero puede encontrar una manera de tener todos los errores observando y compilando su proyecto en una terminal de VS Code.

Por ejemplo, hice este script npm:
"live-check": "webpack --config ./build/webpack.dev.conf.js -w --display none",

Y lo lanzo a través de "npm run live-check" en un terminal VS y tengo todos los errores en tiempo real.

incluso con la solución de @johnfn , solo puedo ver errores de archivos abiertos :(.
Veo la tarea ejecutándose en la pestaña de salida, pero no muestra ningún error

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"
  ]
}

¿Por qué no puedo ver errores de archivos cerrados (estoy seguro de que hay errores)?

👍

Como dijo @apperside ... la tarea solo muestra errores cuando el archivo ha cambiado ...

Con la nueva característica de que los errores se muestran en el espacio de trabajo en la barra lateral, se agradecería mucho que se trabajara desde el primer momento.

Parece que el formato de la tarea cambió un poco en las últimas versiones de vscode. El nuevo formato es:

        {
            "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"
        }

¿Inicia la tarea cada vez que abre VSCode? ¿O hay alguna forma de iniciarlo automáticamente?

Supongo que la última versión del código VS muestra el recuento de errores por archivo

¿Cómo puedo desactivar esto?

// Muestra errores y advertencias en archivos y carpetas.
"issues.decorations.enabled": verdadero,

Simplemente ponga esto en falso;)

El jueves 15 de febrero de 2018 a la 1:36 a.m., pabloli [email protected] escribió:

¿Cómo puedo desactivar esto?

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/13953#issuecomment-365838054 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAy0aayEHkVuxumJRuZz-mdWmBvBhdn9ks5tU9B2gaJpZM4KaH3J
.

Esto es lo que estoy usando

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

Es invaluable, me pregunto si podría ser predeterminado o al menos una configuración.

¿Es posible iniciar automáticamente esta tarea en un espacio de trabajo o proyecto?

Yo uso esto:

{
    "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"
        }
    ]
}

Utilizo esta extensión para ejecutar la tarea en el inicio: https://marketplace.visualstudio.com/items?itemName=yukidoi.blade-runner

Sigo sin saber cómo mantener los errores de un archivo (en el panel Problemas) al cerrarlo.

Sería muy útil tener una opción para mantener los problemas enumerados en el panel después de cerrar un archivo.

¿Alguien tiene una solución para este problema? Para proyectos medianos a grandes, puede resultar bastante engorroso abrir todos los archivos para asegurarse de que no haya errores.

¿Hay alguna forma de abrir todos los archivos a la vez con un comando? Esa sería una solución aceptable para mí.

@daarong Por lo general, tengo eslint-watch ejecutándose en la terminal mientras estoy codificando en vscode para verificar todo el proyecto. No es tan bueno como tener toda la información de pelusa en vscode, pero es una alternativa decente para ver de un vistazo si algún archivo de su proyecto tiene errores.

¿Alguien tiene una solución para esto para los archivos java?
Quiero ver todos los errores de todos los archivos en el panel de problemas en cualquier momento, no solo los errores de los archivos abiertos.

¿Esto es una broma? Tengo alrededor de 2.000 archivos, ¿debo abrirlos todos manualmente para buscar errores de pelusa?

¿Hay alguna forma de activar ts lint en vs code? Podría usar e. tslint para mostrarlo en la consola.
Sería genial si pudiera activar VS Code para escanear todos los archivos en la carpeta src en busca de errores (sintaxis y linter)
En otras palabras: ¿Cómo abrir todos los archivos (ts) en la carpeta src al mismo tiempo?

No busque en otras carpetas como node_modules. ... Solo por el protocolo. 😄
¿Quizás una opción de ruta de inclusión / exclusión sería buena? ...

Hace aproximadamente un mes tenía los pequeños iconos rojos junto a mis archivos en el visor del espacio de trabajo. Ahora se han ido y no tengo ni idea de cómo lo hice. O una nueva versión de VSCode cambió la forma en que funciona o instalé una extensión que lo rompió. ¿Cómo hacer que vuelva a funcionar? Ni siquiera he oído hablar de tasks.json y el hecho de que funcionara antes me sugiere que ahora es el comportamiento predeterminado.

Así es como puede ver todos los problemas en menos de 10 segundos.

Usas un pequeño truco.

Abrir reemplazar todo en archivos (Ctrl + Shift + H).

Reemplazar ; con ;

Presiona reemplazar todo. Eso es todo. Ahora, consulte Problemas.

El supuesto aquí es que todos los archivos tienen al menos un punto y coma. Para proyectos más grandes, si recibe una advertencia que le pide que refine su búsqueda, simplemente ingrese algo que sea común en todos los archivos, pero que no esté muy presente.

¿Algún avance en esto? Aunque el atajo de Ajay funciona, se siente bastante extraño. Parece que esta es una victoria obvia y fácil para VSC. Un interruptor "Mostrar todos los errores / Mostrar errores para archivos abiertos" sería todo lo que se requiere.

Otro pensamiento, en lugar de que esto suceda automáticamente en el cambio de archivo. Estaría totalmente de acuerdo con tener un botón en la barra inferior o un comando que pueda ejecutar explícitamente que verifique todos los archivos.

Es correcto, creo que el problema tiene que ver con la coordinación del servicio TS que verifica todos los archivos abiertos y, por otro lado, verifica los archivos que están cerrados y normalmente no se verifican automáticamente, ¿es correcto? Entonces, la solución fácil es asegurarse de que el panel de problemas reciba todos los problemas de TS de una sola fuente, ¿es correcto?

Viendo como el problema no es resuelto por el equipo de vscode (?), Una propuesta:

¿No debería ser posible resolver esto a través de un complemento o mediante el comparador de problemas de tareas vscode? ¿Porque entonces podría asegurarse de qué y cuándo se muestra el panel de problemas por su cuenta? Entonces, ¿tendría que deshabilitar de alguna manera vscode para que no muestre sus cosas? ¿Puede un desarrollador de vscode decirme si algo como esto sería viable?

Sin embargo, sigo pensando que estas cosas básicas deberían ser manejadas por vscode en sí. No es que los errores de TS se resuelvan por sí mismos cuando cierra archivos ... Simplemente haga que el servidor de TS maneje todos los archivos, abiertos o no, debería hacer los trucos. Debería ser una opción, por supuesto, pero debería ser una opción.

¿Cómo es posible que este no sea el más crítico de todos los problemas a resolver primero? El IDE se rompe hasta que se repara.

Bien, esta es una solución hacky.
Use la solución de @plievone haciendo que una tarea use $ tsc-watch. Luego, obtenga un complemento como AutoLaunch para ejecutar la tarea cada vez que se abre Visual Studio Code. (https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch)

Para expandir la sugerencia de @mateuscb , tal vez algo en el menú contextual del explorador de archivos sería bueno, donde podría hacer clic derecho en una carpeta en particular y "encontrar problemas en la carpeta" sería una buena opción, ya que permitiría la usuario para decidir la compensación entre alcance y velocidad.

No hagas la sugerencia de @ ajayRaghav37 , se bloqueará vscode.
Maldita sea, no volveré a escribir el código ts nunca más en el futuro)

¿Alguna actualización o idea de cuándo se pondrá en proceso? Sería genial tener esta función lista para usar.

ES-Lint ha introducido una nueva tarea en VS Code. Tienes que habilitarlo en la configuración del espacio de trabajo.

"eslint.provideLintTask": true

Simplemente vaya al menú del terminal y seleccione ejecutar tarea, luego elija

eslint: lint carpeta completa.

También puede solucionar automáticamente la mayoría de los problemas ejecutando el siguiente comando en la terminal:

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

Referencia: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

Si bien todavía esperamos el escáner de problemas en VS Code, esta es una alternativa suficientemente buena si usa eslint.

De hecho, característica muy necesaria para proyectos más grandes. ¿Alguna actualización?

@ ajayRaghav37 , parece que eslint no puede detectar errores de escritura, solo reglas de linting:

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

+1

Hasta esto. También creo que debería ser posible deshabilitar la verificación y el borrado de TS incorporados y simplemente usar los resultados de la tarea de compilación.

+1

Ahora ejecuto tsc --noEmit -w para resolver este problema.

Pero creo que sería mejor compartir un ts-server con VSCode.

Pero, ¿por qué no se ha implementado durante tanto tiempo?

¿Alguien está familiarizado con el servidor de idiomas TS? ¿La API de LSP carece de una forma de comunicar esto al IDE? ¿Es esto un problema de rendimiento? Claramente, a la gente le apasiona la falta de esta función (yo lo soy), así que creo que habría interés en la ayuda de la comunidad para que esto pase de la línea de meta.

Pero eso es si el problema aquí es solo la falta de mano de obra en el equipo de VS Code.

Si el problema es diferente (mayor impacto en la arquitectura de VS Code, un cambio en LSP requerido, impacto de rendimiento poco claro, consideraciones de UX), saber esto ayudaría a explicar por qué esta característica aparentemente sencilla lleva tanto tiempo.

Veo varios comentarios en este número sobre cómo la responsabilidad de esto recae en el equipo de TypeScript y no en el equipo de Visual Studio Code. Pero esto también es un problema con la funcionalidad '@ ts-check' incorporada de VS Code. Las soluciones alternativas mencionadas en esta publicación para usar una tarea que ejecuta el comando 'tsc' no me funcionan porque no tengo tsc instalado (solo estoy usando @ ts-check y jsdoc).

Antes, solía hacer clic en cada archivo de mi proyecto para encontrar los errores. Eso fue tedioso, pero al menos los problemas no desaparecieron de la barra lateral una vez que cerré el archivo. Después de una de las actualizaciones de los últimos meses, se presentó este problema: # 73153.

¿Cómo es posible que este no sea el más crítico de todos los problemas a resolver primero? El IDE se rompe hasta que se repara.

Estoy de acuerdo.

¿Cuándo?

La solución 'aceptada' anterior funciona, pero algunos de los campos están obsoletos.

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

Funciona para mi.

Consulte también https://code.visualstudio.com/docs/editor/tasks para crear un archivo tasks.json si aún no tiene uno

¿Es posible deshabilitar el servidor TS integrado de VS Code cuando se ejecuta tsc como una tarea de compilación como esta? La razón por la que pregunto es porque, de lo contrario, obtenemos dos conjuntos de errores: los del servidor TS integrado y los de la tarea, y a veces no están sincronizados.

El IDE está roto e inutilizable para trabajar en proyectos de TypeScript. Así que tengo que ceñirme a la versión 1.28.2 y desactivar las actualizaciones.

Extraño, pero funcionó de alguna manera antes. ¿Qué ha pasado? ¿Y cuándo volverá a funcionar? Ya pasó un año y no hay señales de cambio ...

Octubre de 2019 y todavía está suelto.

3 años para una función que ofrecen otros IDE .... NNNNICCCEEEEEEEEEEEEEE

3 años para una función que ofrecen otros IDE .... NNNNICCCEEEEEEEEEEEEEE

Recuerde que VSCode no es un IDE. Es algo entre Editor e IDE.
De todos modos, espero que lo hagan

3 años para una función que ofrecen otros IDE .... NNNNICCCEEEEEEEEEEEEEE

Recuerde que VSCode no es un IDE. Es algo entre Editor e IDE.
De todos modos, espero que lo hagan

A quién le importa. Sin embargo, ni siquiera puedo poner en marcha la maldita tarea para comprobar los archivos ts.

La guía provista parece aprender un puto lenguaje de programación completamente nuevo.
Trabajamos y producimos, no tengo tiempo que perder aprendiendo todas las tonterías de paquetes web (y herramientas similares) para poner un script que verifique mis archivos ts en un IDE (LO LLAMO IDE, ¿ok?) Que no lo hace ' Incluso admite el lenguaje que los mismos creadores del IDE crearon correctamente ...

que mierda

que mierda

Para un poco de perspectiva:

Microsoft creó un software y lo regaló de forma gratuita.
Este software es útil para millones de personas que lo agradecen.
Microsoft no le obliga a utilizar este software.

Estás enojado con ellos por darte algo gratis porque no es tan perfecto como teóricamente podría ser.

Además, usa el mismo lenguaje de "IDE", y el IDE es de código abierto y acepta solicitudes de extracción ...

He estado viendo esto durante mucho tiempo, todavía esperando una mejor manera de rastrear errores y advertencias, y lo he estado usando desde el lanzamiento público.

Dicho esto, VS Code es, en mi opinión, sin duda el mejor IDE para el desarrollo de JS / TS; diablos, incluso podría ser el mejor producto de MS, solo superado por Github. Definitivamente ha habido mejoras en las funciones y el rendimiento, y la gran cantidad de extensiones me hace muy feliz. Sí, los documentos podrían ser mejores, pero puedes decir eso sobre cada documentación técnica que existe.

Estoy seguro de que el equipo de VS Code trabaja constantemente para brindar mejores herramientas e integraciones.

Y creo que todavía podemos pedir nuevas funciones o seguir mejorando esta de una manera educada.

Agregando a la solución alternativa: parece que ahora hay una tarea preconfigurada para monitorear la salida de tsc -w. En una Mac, Terminal -> Configurar tareas ... -> tsc: watch - tsconfig.json. Luego presione ctrl + shift + B y ejecute la tarea.

Tres años después ... ¿Alguna novedad?

En medio de una refactorización a gran escala. No me di cuenta de que al cerrar todos los archivos afectados ya no veré todos los errores :-(

3 años y aún abierto: bailarina:

3 años y sigue abierto

Sí, votos negativos aleatorios de idiotas.

De todos modos, este es un problema molesto, ¡¡¡vamos !!! Te das cuenta de que uno tiene cientos de archivos en un proyecto empresarial serio, ¿verdad?
¿Cómo se supone que debemos seguirles la pista, mentalmente?

Es una de las funciones básicas para las que la gente usa IDE .....

Y ahora parece que se está propagando también a Visual Studio y su intellisense de vez en cuando.

Por cierto, la tarea parece al menos mitigarla, y para los archivos ts parece que también hay algunos scripts de control disponibles. No sé si se instalan con todas las extensiones angulares / mecanografiadas del administrador de extensiones en vscode, pero si busca en la barra de búsqueda de tareas (que se muestra [aquí]) (https://code.visualstudio.com / docs / editor / tasks) puede buscar algo como el reloj o algo así que haga el truco cada vez que compila (parece que lo hace junto con el proceso de compilación normal, que también es otra tarea)

La pestaña de problemas me parece inútil debido a esto, así que nunca la uso. En su lugar, ejecuto algún comando en la terminal que realmente me da lo que necesito. Por ejemplo, si tengo todos los errores del compilador para el proyecto, ejecuto tsc -w . O quiero ver todos los problemas en mi proyecto o ninguno. No me importa si un archivo está abierto o no. Es irrelevante.

Bueno, si es tan importante que alguien vea errores solo para archivos abiertos en la pestaña Problems , déjelo ser.

Pero, ¿podría crear otra pestaña, digamos Build Output como en Visual Studio?

Esta pestaña mostraría errores y advertencias del compilador como un simple texto de una línea y un doble clic en él abriría el archivo y colocaría el signo de intercalación en la línea con el error.

También los atajos de F4 / Shift-F4 serían geniales para saltar al error siguiente / anterior (pero esto no es tan crucial)

Simplemente borre esta pestaña por completo y vuelva a llenarla después de cada compilación. Eso sería suficiente.

¿O tal vez alguien podría crear una extensión para esto?

Estoy usando una extensión "Abrir archivos coincidentes" para abrir todos los archivos .ts. Tiene un poco de rendimiento, pero al menos hace el trabajo.

Creo que se debe a que el servidor de lenguaje mecanografiado es de un solo subproceso y no se comporta como el compilador de C #
Todavía estoy esperando esta función, porque a veces abro un archivo y trato de encontrar el tipo por nombre usando el comando palete con #, y no sucede nada 😞

Para aquellos que desean vivir al límite, la próxima compilación de información privilegiada de VS Code presenta una configuración "typescript.tsserver.experimental.enableProjectDiagnostics" que permite la generación de informes de errores en todo el proyecto experimental

¡Tenga en cuenta que esto no está listo para producción! Tiene problemas de rendimiento conocidos para proyectos más grandes y puede romper su intellisense

Si tiene algún problema al usar esta configuración, abra un nuevo problema

Para aquellos que desean vivir al límite, la próxima compilación de información privilegiada de VS Code presenta una configuración "typescript.tsserver.experimental.enableProjectDiagnostics" que permite la generación de informes de errores en todo el proyecto experimental

¡Tenga en cuenta que esto no está listo para producción! Tiene problemas de rendimiento conocidos para proyectos más grandes y puede romper su intellisense

Si tiene algún problema al usar esta configuración, abra un nuevo problema

buen trabajo ~

¿Dónde podríamos comprobar el progreso de esta función? Estoy esperando ansiosamente su adición a la edición estándar del código VS cuando esté listo.

Para aquellos que desean vivir al límite, la próxima compilación de información privilegiada de VS Code presenta una configuración "typescript.tsserver.experimental.enableProjectDiagnostics" que permite la generación de informes de errores en todo el proyecto experimental

¡Tenga en cuenta que esto no está listo para producción! Tiene problemas de rendimiento conocidos para proyectos más grandes y puede romper su intellisense

Si tiene algún problema al usar esta configuración, abra un nuevo problema

Gracias a todos los colaboradores de Visual Studio Code por su increíble trabajo.

Para aquellos que desean vivir al límite, la próxima compilación de información privilegiada de VS Code presenta una configuración "typescript.tsserver.experimental.enableProjectDiagnostics" que permite la generación de informes de errores en todo el proyecto experimental

¿Cómo funciona esto con otros linters?

Tuve un problema en el que cada vez que habilito "typescript.tsserver.experimental.enableProjectDiagnostics" , el linter de TypeScript finalmente se cae en un agujero de conejo al atravesar node_modules y desenterrar cientos de errores de los archivos de distribución, incluso cuando "exclude" en tsconfig.json contiene "node_modules" . No puedo entender cómo depurar esto.

También obtengo el mismo efecto que @vdh : mi VSCode analiza toda la carpeta node_modules y ejecuta eslint en cada archivo.

Mi configuración de eslint / editor es:

    "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

Parece que la primera orden del día realmente debería ser que cualquier archivo con node_modules en su ruta debe ignorarse, al menos para las acciones de guardado.

Esta es una característica muy apreciada.
Obtuve el mismo comportamiento que @vdh .
"Resuelto" por ahora agregando los filtros

!*node_modules, !*.vscode

a la vista terminal. (solo visualmente diferente). En caso de que alguien esté interesado en jugar con esto.

@ blackfan23 parece un poco como barrer el polvo debajo de una alfombra: D

@Martaver estuvo de acuerdo. Algo como:

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

sería ideal. Es una mierda ver más de 1000 problemas en un proyecto cuando en realidad hay 0.

@ blackfan23 Esa no es una opción, debido a todo el exceso de rotación de CPU causado por la caída en picada en node_modules

@vdh Configuré skipLibCheck en verdadero en tsconfig y la pestaña "problemas" dejó de mostrar errores de node_modules.

Sin embargo, según este hilo de stackoverflow , activar esta opción degrada la verificación de tipos. Aprecie si alguien del equipo de código VS o mecanografiado puede arrojar algo de luz sobre los pros y los contras de activar esta opción.

@mjbvz
¡Funciona genial! ¡Gracias!
¿Podemos ejecutar "Reparar todo" para estos errores con un solo comando?

¿Qué pasa con otros idiomas, no Typecript? Por ejemplo, tengo cientos de archivos PHP en el proyecto y puedo ver problemas informados por la extensión Intellephense para archivos individuales, pero lo que realmente quiero es ejecutar un diagnóstico para todo el espacio de trabajo.

Sí, esto también causa problemas en los que ESLint está haciendo el mismo descenso en node_modules ("ESLint: No se pudo cargar la configuración" mientras rastrea los directorios allí). Realmente es necesario que haya una lista negra o algo así en lugar de intentar corregir este error por linter.

Excluir los node_modules sería una solución no1 :)

Esto parece funcionar muy bien, pero su millaje puede variar y, por supuesto, no hay garantía:

Dado que tiene mecanografiado 3.9.2 en su package.json, y ha seleccionado esa versión de su espacio de trabajo en 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 o yarn
2. Reiniciar VSCode

= beneficio?

@mjbvz Intenté habilitar esto, y veo un uso de CPU bastante alto del proceso "Code Helper (Renderer)" en comparación con cuando lo apago. ¿Parece probable que esto esté relacionado? ("Renderer" en el nombre del proceso sugiere que no, pero lo cambié varias veces). El proyecto no es enorme (es https://github.com/Dart-Code/Dart-Code).

No dura para siempre, pero hace girar los ventiladores de mi MacBook lo suficiente como para que en este momento probablemente lo deje apagado en lugar de encendido.

¿Ha habido alguna investigación hasta ahora sobre por qué "typescript.tsserver.experimental.enableProjectDiagnostics" siempre se sumerge en todos los archivos dentro de node_modules , a pesar de nuestros varios intentos fallidos de establecer configuraciones de linter para evitar node_modules ?

Es decepcionante, porque esta característica potencialmente asombrosa es completamente eliminada por la rotación excesiva de la CPU causada por la iteración de archivos y directorios no deseados ... 😢

He estado viendo los mismos problemas @vdh mencionados anteriormente con errores de TypeScript de node_modules aparecen en el panel PROBLEMS ; no estaba seguro de si informar un error o si es solo un error. problema de configuración que he causado.

Probé varias configuraciones de tsconfig.json como:

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

No he descubierto si hay un patrón para ver el problema o no. Algunas cosas que sospecho podrían estar pasando:

• Parecía ir y venir al azar, a veces reiniciar vscode ayudó un poco, pero volvería más tarde.
• Pareció afectar a algunos proyectos más que a otros.
• No veo el problema en este momento, así que tal vez una actualización reciente solucionó algo. Todavía estoy ejecutando la edición Insiders.

No estoy del todo seguro acerca de los puntos anteriores, podría ser que yo esté confundido. Solo agrego otra anécdota posiblemente relevante. Si algunos de nosotros seguimos viendo el problema en las versiones actuales, puede valer la pena presentar un nuevo problema. Todavía no he hecho eso, ya que no estoy muy seguro de nada de eso.

Tuve el mismo problema y mi solución en # 90430 fue usar typescript-tslint-plugin .

@enko TSLint se ha desaprobado a favor de ESLint desde 2019 , y abogar por un complemento para un linter obsoleto no es una buena solución para este problema.

Tuve que deshabilitar typescript.tsserver.experimental.enableProjectDiagnostics porque hizo

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

extremadamente lento (2 minutos para guardar un solo archivo).

También noté errores de TS aleatorios de node_modules, que aparecían / ​​desaparecían.

En realidad, existe una solución alternativa si configura su applyTo correctamente en las tareas.

A continuación, se muestra una tarea de trabajo completa que observará la compilación y notificará problemas en el panel Problemas, incluso para archivos que actualmente no están a la vista :

{
  "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 Edite su comentario para decir cómo esta tarea se relaciona directamente con enableProjectDiagnostics , o vuelva a redactar que es una sugerencia como una _ solución temporal_ temporal, no una solución. La distinción entre soluciones alternativas y soluciones reales reales es importante cuando se comentan los hilos de problemas.

@vdh Bastante justo, editado. Aunque no creo que este problema en particular fue alrededor de enableProjectDiagnostics tampoco; el problema en cuestión era que no podemos ver los problemas en todo el proyecto, incluso para los archivos que no están actualmente a la vista.

Con respecto al problema con los errores node_modules no deseados, he creado un nuevo problema para discutirlo específicamente: https://github.com/microsoft/vscode/issues/103539

@vhd / @martaver / @ blackfan23 / @SupremeTechnopriest / @patroza / @jgoux / cualquier otra persona ... Si pudiera agregar más pistas adicionales sobre ese problema, con suerte podría ayudar a resolverlo.

El mismo problema que @jgoux , no funciona con "source.fixAll.eslint": true : eslint comienza a verificar todos los archivos del proyecto, no solo los archivos abiertos, y vuelve a verificar todo el proyecto en cada cambio. VSCode simplemente se cuelga. No tengo idea de por qué modifica el comportamiento predeterminado de ESLint, pero eso es realmente un bloqueador

"typescript.tsserver.experimental.enableProjectDiagnostics" realmente debería corregirse y mejorarse. Haría que el mecanografiado sea mucho más poderoso de lo que ya es.

La solución publicada por @ samesfahani-tuplehealth funciona muy bien. Esto es crucial para mí cuando muevo un tipo importado de un archivo a otro y necesito encontrar todos los lugares donde se rompieron las importaciones. No veo un uso elevado de la CPU, pero si es así, puede ejecutarlo cuando lo necesite.

@phatmann Esa es una solución alternativa , _no_ una solución. Omitir la función y utilizar _otra función completamente diferente_ en su lugar _no_ es una forma de solucionar los problemas de rendimiento. Odio ser persistente con esto, pero prefiero no tener un montón de ruido que desvíe la atención de arreglar esta gran característica (pero experimental). Podría convertirse en algo increíblemente útil si recibe la atención que se merece.

@Vdh tienes razón, por supuesto. (Y, de hecho, una versión más simple de la tarea, la tarea integrada tsk: watch, funciona igualmente bien para la solución alternativa). Mi confusión es la siguiente: la solución es tan eficaz y eficiente que no siento la necesidad de la función real a la que se hace referencia en este número. ¿Me estoy perdiendo de algo?

@phatmann Si quisiera ejecutar una tarea de vigilancia de TypeScript, ya podría hacerlo. No se trata solo de ejecutar comprobaciones de TS. Ejecuta todas las comprobaciones de VSCode en cada archivo de proyecto. Mecanografiado, ESLint, CSpell, etc. Es realmente poderoso y útil saber que incluso si olvidé abrir un archivo, puedo encontrar errores en todo el proyecto (sin ejecutar cada linter manualmente en todos los archivos, tal vez incluso tener que recurrir a hacer externamente en la terminal).

El único defecto importante en este momento es que se excede al ejecutar literalmente todos los archivos, incluidas las carpetas normalmente prohibidas como node_modules .

Ese momento en el que buscas cómo hacer algo con vscode pero lo que obtienes es un problema abierto de 4 años ... 😢

¿Cuánto dinero y a dónde envío?

Para aquellos que tienen problemas con la CPU o problemas con esta función escaneando node_modules, asegúrese de NO tener un "espacio de trabajo" compartido o tsconfig.json algún lugar como la raíz de su repositorio a menos que incluya:

"files": []

de lo contrario, el valor predeterminado es incluir todos los archivos de TypeScript ubicados en o debajo de la carpeta que contiene el tsconfig, lo que probablemente hará que se analicen demasiados archivos.

Esta característica funciona bien para mí en una gran monorepo utilizando espacios de trabajo de hilo y "proyectos" de mecanografiado compuesto.

Buen consejo @dinofx. Además, puede usar include y exclude , en lugar de files , según los documentos .

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

Eso es correcto, pero no es necesario excluir algo que no coincida con los globos "incluir".

"files": [] es más sucinto para un archivo tsconfig.json de "espacio de trabajo" (uno que solo hace referencia a un montón de otros archivos tsconfig.json). No está bien documentado, pero debe nombrar los archivos de configuración para los paquetes y el espacio tsconfig.json trabajo

Para una configuración compartida que se extiende, probablemente sea mejor nombrarla como tsconfig.browser.json , tsconfig.node.json , etc. Ese nombre evita que algo se preocupe por el "files" o "includes" , por lo que probablemente pueda omitirlos.

@dinofx El problema del