Vscode: Solicitação de recurso: mostra todos os erros e avisos no projeto para todos os arquivos, não apenas os abertos

@waderyan, esta é uma solicitação de recurso para o trabalho do construtor que discutimos com a equipe de TS.

Para referência, aqui está um link para o problema - https://github.com/Microsoft/TypeScript/issues/11229

Bem, acabei de usar uma tarefa de compilação de observação com "problemMatcher": "$tsc-watch" (consulte https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchers) e todos os erros e os avisos são mostrados corretamente na visualização Problems. É um fluxo de trabalho bastante bom porque as alterações nos arquivos abertos são notadas imediatamente devido ao servidor de linguagem, mas salvar aciona a compilação incremental (com tsc --watch ) que ainda leva um tempo, mas posso controlar essa latência salvando / não salvando ainda.

qualquer HEC sobre isso? Há muitos problemas abertos para esse recurso e não tenho certeza se perdi alguma coisa ou não: sorria:

@ maxime1992 obrigado pelo acompanhamento. Isso está em nosso radar. Ainda não há um cronograma definido.

Algo que eu não percebi é que é possível fazer isso com a infraestrutura de tarefas que o VSCode tem. Tudo que você precisa fazer é colocar isso em seu tasks.json:

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

Em seguida, basta executá-lo e você obterá todos os erros em todo o projeto na visualização de problemas.

Estou um pouco perplexo porque isso não é exibido com mais destaque. É super útil e legal.

@johnfn Ótima solução, muito obrigado. Eu até adicionaria o argumento "--noEmit" se o único propósito da tarefa for mostrar os erros

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

@kevinjreece Você pode usar o recurso de História Semântica do iTerm (https://www.iterm2.com/documentation-one-page.html) para evitar a "dança divertida entre meu terminal e o VS Code". Ao clicar cmd no nome do arquivo + número da linha, ele abre automaticamente a linha correspondente no vscode!

Alguém sabe se é possível abrir arquivos com erros / no painel Problemas com um atalho de teclado? Uma verdadeira dor para ficar alternando entre o mouse e o teclado, mesmo depois de executar a tarefa.

Você pode abrir o painel Problemas com Ctrl+Shift+M (ou Cmd+Shift+M ), em Atalhos de teclado como "Mostrar problemas" - é isso que você quer dizer?

Não, eu gostaria de um atalho para ir para o próximo arquivo que contém um erro, esteja aberto ou não.

Eu estava pensando em fazer uma extensão para fazer isso, mas a API está bem bloqueada, os comandos não têm acesso ao MarkerService (rastreia problemas) de nenhuma forma que eu possa ver.

Oh, eu vejo. Isso pode ser muito útil. Parece que a área Problems do vscode em geral tem muitas oportunidades de melhorar.

alguém com esse problema https://github.com/Microsoft/vscode/issues/34412?
se ocorrer exatamente o mesmo erro entre as compilações subsequentes, ele o ignora

O truque com tsc em uma tarefa de depuração nem sempre é possível, por exemplo, em um projeto Vue com carregadores Webpack personalizados para lidar com arquivos .vue ( tsc não pode analisar arquivos Vue fora da caixa )

Mas você pode encontrar uma maneira de ter todos os erros observando e compilando seu projeto em um terminal do VS Code.

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

E eu o inicio via "npm run live-check" em um terminal VS e tenho todos os erros em tempo real.

mesmo com a solução de @johnfn , só consigo ver erros de arquivos abertos :(.
Eu vejo a tarefa em execução na guia de saída, mas não mostra nenhum erro

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 que não consigo ver erros de arquivos fechados (tenho certeza de que há erros)?

👍

Como @apperside disse .. a tarefa só mostra erros quando o arquivo foi alterado ..

Com o novo recurso que erros são exibidos na área de trabalho na barra lateral, para este trabalho fora da caixa seria muito apreciado.

Parece que o formato da tarefa mudou um pouco nas versões mais recentes do vscode. O novo formato é:

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

Você inicia a tarefa sempre que abre o VSCode? Ou existe uma maneira de iniciá-lo automaticamente?

Acho que a versão mais recente do código VS mostra a contagem de erros por arquivo

Como posso desabilitar isso?

// Mostra erros e avisos em arquivos e pastas.
"problems.decorations.enabled": true,

Basta colocar isso como falso;)

Na quinta-feira, 15 de fevereiro de 2018 à 1h36, pabloli [email protected] escreveu:

Como posso desabilitar isso?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/13953#issuecomment-365838054 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAy0aayEHkVuxumJRuZz-mdWmBvBhdn9ks5tU9B2gaJpZM4KaH3J
.

Isso é o que estou usando

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

É inestimável, eu me pergunto se poderia ser tornado padrão ou pelo menos uma configuração.

É possível iniciar automaticamente esta tarefa em um espaço de trabalho ou projeto?

Eu uso isso:

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

Eu uso esta extensão para executar a tarefa na inicialização: https://marketplace.visualstudio.com/items?itemName=yukidoi.blade-runner

Ainda não sei como guardar os erros de um arquivo (no painel Problemas) ao fechá-lo.

Ter a opção de manter os problemas listados no painel depois de fechar um arquivo seria muito útil.

Alguém tem uma solução alternativa para esse problema? Para projetos de médio a grande porte, pode ser bastante complicado abrir todos os arquivos para garantir que não haja erros.

Existe uma maneira de abrir todos os arquivos de uma vez com um comando? Isso seria uma solução alternativa aceitável para mim.

@daarong Eu geralmente tenho eslint-watch rodando no terminal enquanto estou codificando em vscode para verificar todo o projeto. Não é tão bom quanto ter todas as informações de linting no vscode, mas é um fallback decente para ver rapidamente se algum arquivo em seu projeto contém erros.

Alguém tem uma solução alternativa para isso para arquivos java?
Quero ver todos os erros de todos os arquivos no painel de problemas a qualquer momento, não apenas os erros de arquivos abertos.

Isso é uma piada? Tenho cerca de 2.000 arquivos, devo abrir todos eles manualmente para procurar erros de lint ??

Existe uma maneira de acionar ts lint no código vs? Eu poderia usar e. tslint para exibi-lo no console.
Seria ótimo se eu pudesse acionar o VS Code para verificar todos os arquivos na pasta src em busca de erros (sintaxe e linter)
Em outras palavras: Como abrir todos os arquivos (ts) na pasta src ao mesmo tempo?

Não procure em outras pastas como node_modules. ... Apenas para o protocolo. 😄
Talvez uma opção de incluir / excluir caminho seria bom? ...

Cerca de um mês atrás, eu tinha os pequenos ícones vermelhos ao lado dos meus arquivos no visualizador da área de trabalho. Agora eles se foram e não tenho ideia de como fiz isso. Uma nova versão do VSCode mudou a maneira como ele funciona ou instalei uma extensão que o quebrou. Como fazer para voltar a funcionar? Nunca ouvi falar de tasks.json e o fato de ter funcionado antes sugere que agora é o comportamento padrão.

Veja como você pode ver todos os problemas em menos de 10 segundos.

Você usa um pequeno truque.

Abra a substituição de todos os arquivos (Ctrl + Shift + H).

Substituir ; com ;

Clique em substituir tudo. É isso. Agora, verifique os problemas.

A suposição aqui é que todos os arquivos têm pelo menos um ponto-e-vírgula. Para projetos maiores, se você receber um aviso pedindo para refinar sua pesquisa, basta inserir algo que seja comum em todos os arquivos, mas não esteja muito presente.

alguma atualização disso? Embora o atalho de Ajay funcione, parece um tanto hacky. Parece que esta é uma vitória fácil e óbvia para o VSC. Uma opção "Mostrar todos os erros / Mostrar erros para arquivos abertos" seria tudo o que é necessário.

Outro pensamento, em vez de que isso aconteça automaticamente na mudança do arquivo. Eu ficaria totalmente bem em ter um botão na barra inferior ou um comando que eu possa executar explicitamente para verificar todos os arquivos.

É correto, acho que o problema tem a ver com a coordenação do serviço de TS que verifica todos os arquivos abertos e por outro lado verifica os arquivos que estão fechados e normalmente não são verificados automaticamente, correto? Portanto, a solução fácil é garantir que o painel de problemas receba todos os problemas de TS de uma única fonte, correto?

Vendo como o problema não é resolvido pela equipe vscode (?), Uma proposta:

Não deveria ser possível resolver isso por meio de um addon ou via vscode task problem matcher? Porque então você poderia garantir o que e quando o painel de problemas seria mostrado sozinho? Então você teria apenas que desabilitar o vscode de mostrar suas coisas? Um dev vscode pode me dizer se algo assim seria viável?

No entanto, ainda acho que essas coisas básicas devem ser tratadas pelo próprio vscode. Não é como se os erros de TS se resolvessem sozinhos quando você fecha arquivos ... Basta fazer o servidor TS lidar com todos os arquivos, abertos ou não, deve fazer os truques. Deveria ser uma opção, claro, mas uma opção deveria ser.

Como isso pode não ser o mais crítico de todos os problemas a serem resolvidos primeiro? O IDE está quebrado até ser consertado.

Ok, então esta é uma solução hacky.
Use a solução de @plievone fazendo uma tarefa usar $ tsc-watch. Em seguida, obtenha um plug-in como o AutoLaunch para executar a tarefa sempre que o Visual Studio Code for aberto. (https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch)

para expandir a sugestão de @mateuscb , talvez algo no menu de contexto do explorador de arquivos seja bom, onde você pode clicar com o botão direito em uma pasta específica e fazer "encontrar problemas na pasta" seria uma boa opção, pois permitiria que usuário para decidir a relação entre escopo e velocidade.

Não faça a sugestão @ ajayRaghav37 , ele irá travar o vscode.
Droga, não vou escrever o código ts nunca mais no futuro)

Alguma atualização ou ideia de quando isso será colocado no pipeline? Seria ótimo ter esse recurso pronto para uso.

ES-Lint introduziu uma nova tarefa no VS Code. Você deve habilitá-lo nas configurações do espaço de trabalho.

"eslint.provideLintTask": true

Basta ir ao menu do terminal e selecionar executar tarefa e, em seguida, escolher

eslint: pasta inteira do lint.

Você também pode corrigir automaticamente a maioria dos problemas executando o seguinte comando no terminal:

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

Referência: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

Enquanto ainda aguardamos o scanner de problemas no VS Code, esta é uma alternativa boa o suficiente se você usar o eslint.

Recurso muito necessário para projetos maiores. Alguma atualização?

@ ajayRaghav37 , parece que o eslint não é capaz de detectar erros de digitação, apenas regras de lint:

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

+1

Suba isso. Eu também acho que deveria ser possível desabilitar a verificação e linting do TS embutido e apenas usar os resultados da tarefa de compilação.

+1

Agora corro tsc --noEmit -w para resolver este problema.

Mas acho que seria melhor compartilhar ts-server com VSCode.

Mas por que não foi implementado por tanto tempo?

Alguém aqui está familiarizado com o servidor de linguagem TS? A API LSP não tem uma maneira de comunicar isso ao IDE? Isso é uma preocupação de desempenho? Claramente, as pessoas estão apaixonadas pela falta desse recurso (eu sou), então acho que haveria interesse na ajuda da comunidade para ultrapassar a linha de chegada.

Mas isso se o problema aqui for apenas a falta de mão de obra na equipe do VS Code.

Se o problema for diferente (maior impacto na arquitetura do VS Code, uma mudança no LSP necessária, impacto no desempenho incerto, considerações de UX), saber disso ajudaria a explicar por que esse recurso aparentemente simples leva tanto tempo.

Vejo vários comentários neste problema sobre como a responsabilidade disso é da equipe do TypeScript e não da equipe do Visual Studio Code. Mas este também é um problema com a funcionalidade embutida '@ ts-check' do VS Code. As soluções alternativas mencionadas neste artigo para usar uma tarefa executando o comando 'tsc' não funcionam para mim porque não tenho o tsc instalado (estou usando apenas @ ts-check e jsdoc).

Antes, eu costumava clicar em todos os arquivos do meu projeto para encontrar os erros. Isso foi entediante, mas pelo menos os problemas não desapareceram da barra lateral depois que fechei o arquivo. Após uma das atualizações dos últimos meses, este problema foi introduzido: # 73153.

Como isso pode não ser o mais crítico de todos os problemas a serem resolvidos primeiro? O IDE está quebrado até ser consertado.

Eu concordo.

Quando?

A solução 'aceita' acima funciona, mas alguns dos campos estão obsoletos.

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

Funciona para mim.

Consulte também https://code.visualstudio.com/docs/editor/tasks para criar um arquivo tasks.json se você ainda não tiver um

É possível desativar o servidor TS integrado do VS Code ao executar tsc como uma tarefa de compilação como esta? A razão de eu perguntar é porque, caso contrário, obteremos dois conjuntos de erros: os do servidor TS integrado e os da tarefa, e às vezes eles estão fora de sincronia.

O IDE está quebrado e inutilizável para trabalhar em projetos Typescript. Portanto, tenho que manter a versão 1.28.2 e desabilitar as atualizações.

Estranho, mas funcionou de alguma forma antes. O que aconteceu? E quando vai funcionar de novo? Já se passou um ano e não há sinais de mudança ...

Outubro de 2019 e ainda está em liberdade.

3 anos para um recurso que outros IDE oferecem .... NNNNICCCEEEEEEEEEEEEEE

3 anos para um recurso que outros IDE oferecem .... NNNNICCCEEEEEEEEEEEEEE

Lembre-se de que o VSCode não é um IDE. É algo entre o Editor e o IDE.
Enfim, espero que eles façam isso

3 anos para um recurso que outros IDE oferecem .... NNNNICCCEEEEEEEEEEEEEE

Lembre-se de que o VSCode não é um IDE. É algo entre o Editor e o IDE.
Enfim, espero que eles façam isso

Quem se importa. No entanto, não consigo nem mesmo colocar a maldita tarefa em execução para verificar os arquivos ts.

O guia fornecido parece aprender uma linguagem de programação totalmente nova.
Nós trabalhamos e produzimos, não tenho tempo a perder aprendendo todo o webpack (e ferramentas semelhantes) vagão de besteira para colocar um script que verifica meus arquivos ts em um IDE (I CALL IT IDE ok?) Que não faz Ele ainda suporta a linguagem que os mesmos criadores do IDE criaram corretamente ....

que besteira

que besteira

Para um pouco de perspectiva:

A Microsoft fez alguns softwares e os distribuiu gratuitamente.
Este software é útil para milhões de pessoas que são gratas por ele.
A Microsoft não o está forçando a usar este software.

Você está zangado com eles por lhe darem algo de graça porque não é tão perfeito quanto teoricamente poderia ser.

Além disso, ele usa a mesma linguagem de "IDE", e o IDE é de código aberto e aceita solicitações de pull ...

Já estou observando isso há muito tempo, ainda esperando uma maneira melhor de rastrear erros e avisos, e tenho usado desde o lançamento público.

Dito isso, o VS Code é, na minha opinião, sem dúvida, o melhor IDE para desenvolvimento JS / TS - diabos, pode até ser o melhor produto MS, perdendo apenas para o Github. Definitivamente houve melhorias nos recursos e no desempenho, e a quantidade de extensões me deixa muito feliz. Sim, os documentos poderiam ser melhores, mas você pode dizer isso sobre toda documentação de tecnologia que existe.

Tenho certeza de que a equipe do VS Code está constantemente trabalhando duro para trazer melhores ferramentas e integrações.

E acredito que ainda podemos pedir novos recursos ou continuar aprimorando este de uma maneira educada.

Adicionando à solução alternativa - Parece que agora há uma tarefa pré-configurada para monitorar a saída de tsc -w. Em um Mac, Terminal -> Configurar Tarefas ... -> tsc: watch - tsconfig.json. Em seguida, pressione ctrl + shift + B e execute a tarefa.

Três anos depois ... Alguma notícia?

No meio da refatoração em grande escala. Não percebi que, ao fechar todos os arquivos afetados, não verei mais todos os erros :-(

3 anos e ainda aberto: dançarina:

3 anos e ainda aberto

Oba, downvotes aleatórios de idiotas.

Enfim, esse é um problema chato, vamos !!! Você percebe que alguém tem centenas de arquivos em um projeto de negócio sério, certo?
Como devemos controlá-los mentalmente?

É uma das funções básicas para as quais as pessoas usam IDEs ...

E agora parece que está se propagando também para o estúdio visual e sua inteligência de vez em quando

A propósito da tarefa, as coisas parecem pelo menos atenuá-la, e para os arquivos ts parece que também estão disponíveis alguns scripts de controle. Não sei se eles são instalados por todas as extensões angular / typescript do gerenciador de extensão no vscode, mas se vc pesquisar na barra de pesquisa de tarefas (que é mostrada [aqui]) (https://code.visualstudio.com / docs / editor / tasks) você pode pesquisar algo como o relógio ou algo parecido que faz o truque toda vez que você compila (parece que faz isso junto com o processo de compilação normal, que é outra tarefa também)

Acho a guia de problemas inútil por causa disso, então nunca a uso. Em vez disso, executo algum comando no terminal que realmente me dá o que preciso. Por exemplo, se eu executar todos os erros do compilador para o projeto, executo tsc -w . Eu quero ver todos os problemas em meu projeto ou nenhum. Eu não me importo se um arquivo está aberto ou não. É irrelevante.

Bem, se é tão importante para alguém ver os erros apenas para arquivos abertos na guia Problems , deixe estar.

Mas você poderia criar outra guia, digamos Build Output assim como no Visual Studio.

Essa guia mostraria erros e avisos do compilador como um texto simples de uma linha e um clique duplo nele abriria o arquivo e colocaria o cursor bem na linha com o erro.

Além disso, os atalhos F4 / Shift-F4 seriam ótimos para pular para o erro seguinte / anterior (mas isso não é tão importante)

Limpe esta guia completamente e preencha-a novamente após cada compilação. Isso seria o suficiente.

Ou talvez alguém possa criar uma extensão para isso?

Estou usando uma extensão "Abrir arquivos correspondentes" para abrir todos os arquivos .ts. É um pouco pesado em termos de desempenho, mas pelo menos dá conta do recado.

Eu acho que é porque o servidor de linguagem typescript é de thread único e não se comporta como o compilador C #
Ainda estou esperando por esse recurso, porque às vezes eu abrindo arquivo e tento achar o tipo pelo nome usando o comando palete com #, e nada acontece 😞

Para aqueles que desejam viver no limite, a próxima versão interna do VS Code apresenta uma configuração "typescript.tsserver.experimental.enableProjectDiagnostics" que permite relatórios de erros em todo o projeto experimental

Observe que isso não está pronto para produção! Ele conhece problemas de desempenho para projetos maiores e pode quebrar sua inteligência

Se você tiver um problema ao usar esta configuração, abra um novo problema

Para aqueles que desejam viver no limite, a próxima versão interna do VS Code apresenta uma configuração "typescript.tsserver.experimental.enableProjectDiagnostics" que permite relatórios de erros em todo o projeto experimental

Observe que isso não está pronto para produção! Ele conhece problemas de desempenho para projetos maiores e pode quebrar sua inteligência

Se você tiver um problema ao usar esta configuração, abra um novo problema

bom trabalho ~

Onde podemos verificar o andamento desse recurso? Estou aguardando ansiosamente sua adição à edição padrão do código VS quando estiver pronto.

Para aqueles que desejam viver no limite, a próxima versão interna do VS Code apresenta uma configuração "typescript.tsserver.experimental.enableProjectDiagnostics" que permite relatórios de erros em todo o projeto experimental

Observe que isso não está pronto para produção! Ele conhece problemas de desempenho para projetos maiores e pode quebrar sua inteligência

Se você tiver um problema ao usar esta configuração, abra um novo problema

Obrigado a todos os colaboradores do Visual Studio Code por seu trabalho incrível.

Para aqueles que desejam viver no limite, a próxima versão interna do VS Code apresenta uma configuração "typescript.tsserver.experimental.enableProjectDiagnostics" que permite relatórios de erros em todo o projeto experimental

Como isso funciona com outros linters?

Tive um problema em que sempre que eu habilito "typescript.tsserver.experimental.enableProjectDiagnostics" , o linter Typescript acaba entrando em uma toca de coelho, atravessando node_modules e desenterrando centenas de erros de arquivos de distribuição, mesmo quando "exclude" em tsconfig.json contém "node_modules" . Não consigo descobrir como depurar isso.

Eu também obtenho o mesmo efeito que @vdh - meu VSCode analisa toda a minha pasta node_modules e executa eslint em cada arquivo.

Minha configuração eslint / editor é:

    "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 a primeira coisa a fazer é realmente ignorar qualquer arquivo com node_modules em seu caminho, pelo menos para ações ao salvar.

Este é um recurso muito apreciado.
Obtive o mesmo comportamento de @vdh .
"Resolvido" por enquanto adicionando os filtros

!*node_modules, !*.vscode

para a visualização do terminal. (apenas visualmente diferente). Caso alguém esteja interessado em brincar com isso.

@ blackfan23 parece um pouco com varrer a poeira para debaixo de um tapete: D

@Martaver aprovado . Algo como:

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

seria ideal. É uma merda ver mais de 1k problemas em um projeto quando na verdade há 0.

@ blackfan23 Isso não é uma opção, devido a todo o excesso de rotatividade da CPU causado pela queda livre para node_modules

@vdh Eu defini skipLibCheck como true em tsconfig e a guia "problems" parou de mostrar erros de node_modules.

No entanto, com base neste thread stackoverflow , ativar essa opção degrada a verificação de tipo. Agradeço se alguém da equipe de código ou de digitação do VS puder esclarecer os prós e os contras de ativar essa opção.

@mjbvz
Funciona bem! obrigado!
Podemos executar "Corrigir tudo" para esses erros com um comando?

E quanto a outras linguagens, não datilografadas? Por exemplo, eu tenho centenas de arquivos PHP no projeto e posso ver problemas relatados pela extensão Intellephense para arquivos individuais, mas o que eu realmente quero é executar um diagnóstico para todo o espaço de trabalho.

Sim, isso também causa problemas em que o ESLint está fazendo a mesma queda livre em node_modules ("ESLint: Falha ao carregar configuração", pois ele rastreia os diretórios lá). Realmente precisa haver uma lista negra ou algo assim, em vez de tentar consertar esse bug por linter.

Excluir os node_modules seria uma solução no1 :)

Isso parece funcionar muito bem, mas - sua millage pode variar e, claro, nenhuma garantia:

Dado que você tem o typescript 3.9.2 em seu package.json e selecionou essa versão do seu espaço de trabalho no 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 ou yarn
2. Reiniciar VSCode

= lucro?

@mjbvz Tentei habilitar isso e vejo um uso de CPU muito alto no processo "Code Helper (Renderer)" em comparação com quando o desativo. Parece provável que isso esteja relacionado ("Renderer" no nome do processo sugere que não, mas eu o alternei algumas vezes). O projeto não é grande (é https://github.com/Dart-Code/Dart-Code).

Não dura para sempre, mas estimula meus ventiladores do MacBook o suficiente para que eu provavelmente os mantenha desligados em vez de ligados.

Houve alguma investigação até agora sobre por que "typescript.tsserver.experimental.enableProjectDiagnostics" sempre mergulha em todos os arquivos dentro de node_modules , apesar de nossas várias tentativas fracassadas de definir as configurações do linter para evitar node_modules ?

É decepcionante, porque esse recurso potencialmente incrível é completamente eliminado pela excessiva rotatividade da CPU causada pela iteração de arquivos e diretórios indesejados ... 😢

Tenho visto os mesmos problemas @vdh mencionados acima com erros de TypeScript de node_modules aparecendo no painel PROBLEMS - não tive certeza se deveria relatar um bug ou se é apenas algum erro- problema de configuração que eu causei.

Tentei várias configurações de tsconfig.json como:

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

Ainda não descobri se existe um padrão para ver o problema ou não. Algumas coisas que eu suspeito que podem estar / estavam acontecendo:

• Parecia ir e vir aleatoriamente, às vezes reiniciar o vscode ajudou um pouco, mas voltaria mais tarde.
• Pareceu afetar alguns projetos mais do que outros.
• Não estou vendo o problema agora, talvez uma atualização recente tenha corrigido algo. Ainda estou executando a edição Insiders.

Não estou totalmente certo sobre os pontos acima, pode ser apenas eu estar confuso. Apenas adicionando outra anedota possivelmente relevante. Se alguns de nós ainda estão vendo o problema nas versões atuais, pode valer a pena preencher um novo problema. Ainda não fiz isso, pois não tenho certeza de nada.

Eu tive o mesmo problema e minha solução em # 90430 foi usar typescript-tslint-plugin .

@enko TSLint foi preterido em favor do ESLint desde 2019 , defender um plugin para um linter preterido não é uma boa solução para esse problema.

Tive que desabilitar typescript.tsserver.experimental.enableProjectDiagnostics porque fez

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

extremamente lento (2 minutos para salvar um único arquivo).

Eu também notei erros aleatórios de TS de node_modules, que estavam aparecendo / desaparecendo.

Na verdade, há uma solução alternativa se você definir seu applyTo corretamente nas tarefas.

Uma tarefa de trabalho completa que observará os problemas de compilação e relatório para o painel Problemas, mesmo para arquivos não exibidos

{
  "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 Por favor, edite seu comentário para dizer como esta tarefa se relaciona diretamente com enableProjectDiagnostics , ou então reformule que é uma sugestão como uma _solução_ temporária, não uma correção. A distinção entre soluções alternativas e correções reais é importante fazer ao comentar sobre os encadeamentos do problema.

@vdh Muito justo, editado. Embora eu também não ache que esse problema em particular fosse cerca de enableProjectDiagnostics ; o problema em questão era que não podemos visualizar os problemas em todo o projeto, mesmo para arquivos que não estão sendo visualizados no momento.

Com relação ao problema com os erros indesejados node_modules , criei um novo problema para discutir especificamente isso: https://github.com/microsoft/vscode/issues/103539

@vhd / @martaver / @ blackfan23 / @SupremeTechnopriest / @patroza / @jgoux / outra pessoa ... Se você pudesse adicionar mais pistas sobre esse problema, esperamos que isso ajude a resolver o problema.

O mesmo problema que @jgoux , não funciona com "source.fixAll.eslint": true - o eslint começa a verificar todos os arquivos do projeto, não apenas os arquivos abertos, e verifica novamente o projeto inteiro a cada alteração. VSCode simplesmente trava. Não tenho ideia de por que ele modifica o comportamento padrão do ESLint, mas isso é realmente um bloqueador

"typescript.tsserver.experimental.enableProjectDiagnostics" realmente deveria ser corrigido e melhorado. Isso tornaria a digitação muito mais poderosa do que já é.

A solução postada por @ samesfahani-tuplehealth funciona muito bem. Isso é crucial para mim quando movo um tipo importado de um arquivo para outro e preciso encontrar todos os lugares em que as importações quebraram. Não estou vendo um alto uso da CPU, mas se for esse o caso, você pode simplesmente executá-lo quando precisar.

@phatmann Essa é uma solução alternativa , _não_ uma solução. Ignorar o recurso e usar _outro recurso totalmente diferente_ em vez disso _não_ é uma maneira de corrigir os problemas de desempenho. Eu odeio ser persistente sobre isso, mas prefiro não ter muito barulho que desvie a atenção do conserto desse ótimo (mas experimental) recurso. Pode se tornar algo incrivelmente útil se receber a atenção que merece.

@Vdh você está certo, é claro. (E, de fato, uma versão mais simples da tarefa, a tarefa tsk: watch embutida, funciona igualmente bem para a solução alternativa). Minha confusão é a seguinte: a solução alternativa é tão eficaz e eficiente que não sinto necessidade do recurso real mencionado neste problema. Estou esquecendo de algo?

@phatmann Se eu quisesse executar uma tarefa de observação do Typescript, já poderia fazer isso. Não se trata apenas de executar verificações de TS. Ele executa todas as verificações do VSCode em cada arquivo de projeto. Texto datilografado, ESLint, CSpell, etc ... É realmente poderoso e útil saber que mesmo se eu esquecer de abrir um arquivo, posso encontrar erros em todo o projeto (sem executar cada linter manualmente em todos os arquivos, talvez até mesmo tendo que recorrer a externamente no terminal).

A única grande falha agora é que ele exagera ao atropelar literalmente todos os arquivos, incluindo pastas normalmente proibidas como node_modules .

Aquele momento em que você pesquisa como fazer algo com o vscode, mas o que você obtém é um problema aberto de 4 anos ... 😢

Quanto dinheiro e para onde envio?

Para aqueles que têm problemas de CPU ou problemas com este recurso de varredura de node_modules, certifique-se de NÃO ter um "espaço de trabalho" compartilhado ou "espaço de trabalho" tsconfig.json algum lugar como a raiz do seu repositório, a menos que inclua:

"files": []

caso contrário, o padrão é incluir todos os arquivos TypeScript localizados na ou abaixo da pasta que contém o tsconfig, o que provavelmente fará com que ele analise muitos arquivos.

Este recurso está funcionando bem para mim em um grande monorepo usando espaços de trabalho yarn e "projetos" de texto datilografado composto.

Ótimo conselho @dinofx. Além disso, você pode usar include e exclude , em vez de files , de acordo com os documentos .

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

Correto, mas não há necessidade de excluir algo que não corresponda aos globs "include".

"files": [] é mais sucinto para um arquivo tsconfig.json de "espaço de trabalho" (aquele que apenas faz referência a vários outros arquivos tsconfig.json). Não está bem documentado, mas você precisa nomear os arquivos de configuração dos pacotes e da área de trabalho tsconfig.json , ou muitos recursos não funcionarão corretamente (esses recursos, encontrar referências, refatorar, etc).

Para uma configuração compartilhada que é estendida, é provavelmente melhor nomeá-la com algo como tsconfig.browser.json , tsconfig.node.json , etc. Essa nomenclatura evita que qualquer coisa se importe com "files" ou "includes" , então você provavelmente pode omiti-los.

@dinofx O problema de travessia de arquivo não se restringe apenas ao Typescript. Além disso, nem todo mundo usa um monorepo.