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-matcher 참조)와 모든 오류 및 경고가 문제 보기에 올바르게 표시됩니다. 열린 파일의 변경 사항이 언어 서버로 인해 즉시 감지되기 ​​때문에 꽤 좋은 워크플로이지만 저장하면 증분 컴파일( tsc --watch )이 트리거되므로 여전히 시간이 걸리지만 저장/저장하지 않음으로써 대기 시간을 제어할 수 있습니다. 아직.

이것에 어떤 ETA? 해당 기능에 대해 많은 문제가 열렸고 내가 놓친 것이 있는지 없는지 확실하지 않습니다. 스마일:

@maxime1992 후속

내가 깨닫지 못한 것은 VSCode에 있는 작업 인프라로 이 작업을 수행할 수 있다는 것입니다. 이것을 task.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의 Semantic History 기능(https://www.iterm2.com/documentation-one-page.html)을 사용하여 "내 단말과 VS Code 간의 펀댄스"를 방지할 수 있습니다. cmd가 파일 이름 + 줄 번호를 클릭하면 자동으로 vscode에서 해당 줄이 열립니다!

키보드 단축키로 문제 패널에서 오류가 있는 파일을 열 수 있는지 아는 사람이 있습니까? 작업을 실행한 후에도 마우스와 키보드를 계속 전환하는 것은 정말 고통스럽습니다.

Ctrl+Shift+M (또는 Cmd+Shift+M )를 사용하여 문제 패널을 열 수 있습니다. 바로 가기 키 아래에 "문제 표시"가 있습니다. 그게 무슨 뜻인가요?

아니요, 열려 있는지 여부에 관계없이 오류가 있는 다음 파일로 이동하는 바로 가기를 원합니다.

나는 그것을 할 확장을 찾고 있었지만 API는 단단히 잠겨 있고 명령은 내가 볼 수있는 방식으로 MarkerService (문제 추적)에 액세스 할 수 없습니다.

알 겠어요. 꽤 유용할 수 있습니다. 일반적으로 vscode의 Problems 영역은 개선할 기회가 많습니다.

이 문제가 발생하는 사람은 https://github.com/Microsoft/vscode/issues/34412입니까?
후속 빌드 간에 정확히 동일한 오류가 발생하면 이를 무시합니다.

디버그 작업에 tsc 를 사용하는 트릭이 항상 가능한 것은 아닙니다. 예를 들어 사용자 정의 Webpack 로더가 있는 Vue 프로젝트에서 .vue 파일을 처리할 수 있습니다( tsc 는 기본적으로 Vue 파일을 구문 분석할 수 없습니다. ).

그러나 프로젝트를 보고 VS Code 터미널로 컴파일하면 모든 오류가 발생하는 방법을 찾을 수 있습니다.

예를 들어 다음 npm 스크립트를 수행했습니다.
"live-check": "webpack --config ./build/webpack.dev.conf.js -w --display none",

그리고 "npm run live-check"를 통해 VS 터미널로 실행하고 모든 오류가 실시간으로 발생합니다.

@johnfn 의 솔루션을 사용
출력 탭에서 실행 중인 작업을 볼 수 있지만 오류가 표시되지 않습니다.

task.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 코드는 파일당 오류 수를 보여줍니다.

이것을 비활성화하려면 어떻게 해야 합니까?

// 파일 및 폴더에 대한 오류 및 경고를 표시합니다.
"problems.decorations.enabled": 참,

이것을 false로 설정하기만 하면 됩니다. ;)

2018년 2월 15일 목요일 오전 1시 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 나는 일반적으로 전체 프로젝트를 확인하기 위해 vscode로 코딩하는 동안 터미널에서 eslint-watch를 실행합니다. vscode에 모든 linting 정보를 가지고 있는 것만큼 좋지는 않지만 프로젝트의 파일에 오류가 있는지 한 눈에 확인하기에는 괜찮은 대안입니다.

누구든지 Java 파일에 대한 해결 방법이 있습니까?
열려 있는 파일의 오류뿐만 아니라 문제 패널에서 모든 파일의 모든 오류를 언제든지 보고 싶습니다.

지금 농담하는 거지? 약 2,000개의 파일이 있습니다. 보푸라기 오류를 검색하기 위해 수동으로 모든 파일을 열어야 합니까???

vs 코드에서 ts lint를 트리거하는 방법이 있습니까? 나는 전자를 사용할 수 있습니다. tslint 를 사용하여 콘솔에 표시합니다.
VS Code가 src 폴더의 모든 파일에서 오류(구문 및 린터)를 검색하도록 트리거할 수 있다면 좋을 것입니다.
즉, src 폴더의 모든 파일(ts)을 동시에 여는 방법은 무엇입니까?

node_modules와 같은 다른 폴더에서 검색하지 마십시오. ... 프로토콜에 대해서만. 😄
포함/제외 경로 옵션이 좋을까요? ...

약 한 달 전에 작업 공간 뷰어에서 내 파일 옆에 작은 빨간색 아이콘이 있었습니다. 이제 그들은 사라졌고 내가 어떻게 했는지 모르겠습니다. 새 버전의 VSCode가 작동 방식을 변경했거나 이를 중단시킨 확장을 설치했습니다. 다시 작동시키는 방법? 나는 task.json에 대해 들어본 적도 없고 이전에 작동했다는 사실이 이것이 이제 기본 동작임을 시사합니다.

다음은 10초 이내에 모든 문제를 볼 수 있는 방법입니다.

당신은 약간의 트릭을 사용합니다.

파일에서 모두 바꾸기 열기(Ctrl + Shift + H).

바꾸다 ; 와 함께 ;

모두 바꾸기를 누르십시오. 그게 다야 이제 문제를 확인하십시오.

여기에서 모든 파일에는 적어도 하나의 세미콜론이 있다고 가정합니다. 더 큰 프로젝트의 경우 검색을 세분화하라는 경고가 표시되면 모든 파일에 공통적이지만 많이 나타나지 않는 항목을 입력하십시오.

이에 대한 업데이트가 있습니까? Ajay의 단축키는 작동하지만 다소 해킹된 느낌입니다. 이것은 VSC의 명백하고 쉬운 승리인 것 같습니다. "모든 오류 표시/열린 파일에 대한 오류 표시" 스위치만 있으면 됩니다.

파일 변경 시 자동으로 발생하는 대신 또 다른 생각입니다. 하단 표시줄에 버튼이 있거나 모든 파일을 검사하는 명시적으로 실행할 수 있는 명령이 있으면 완전히 괜찮을 것입니다.

맞아요, 문제는 열려있는 모든 파일을 검사하는 TS 서비스를 조정하는 것과 관련이 있고 다른 한편으로 닫혀 있고 일반적으로 자동으로 검사되지 않는 파일을 검사하는 것과 관련이 있다고 생각합니다. 맞습니까? 따라서 쉬운 솔루션은 문제 창에서 단일 소스에서 모든 TS 문제를 수신하도록 하는 것입니다. 맞습니까?

vscode 팀(?)이 문제를 해결하지 못하는 것을 보고 제안:

애드온이나 vscode 작업 문제 매처를 통해 이 문제를 해결할 수 없습니까? 그러면 문제 창이 무엇을 언제 표시하는지 스스로 확인할 수 있기 때문입니까? 그런 다음 어떻게든 vscode가 해당 내용을 표시하지 못하도록 비활성화해야 합니까? vscode 개발자가 이와 같은 작업이 가능한지 말해 줄 수 있습니까?

그러나 나는 여전히 이 기본적인 것들을 vscode 자체에서 처리해야 한다고 생각합니다. 파일을 닫을 때 TS 오류가 저절로 해결되는 것과는 다릅니다... TS 서버가 모든 파일을 열거나 열지 않고 처리하도록 하면 트릭을 수행해야 합니다. 물론 선택사항이지만 선택사항이어야 합니다.

이것이 가장 먼저 해결해야 할 모든 문제 중 가장 중요하지 않을 수 있습니까? IDE는 수정될 때까지 중단됩니다.

좋아, 이것은 해키 솔루션입니다.
작업이 $tsc-watch를 사용하도록 하여 @plievone 의 솔루션을 사용합니다. 그런 다음 Visual Studio Code가 열릴 때마다 작업을 실행하는 AutoLaunch와 같은 플러그인을 가져옵니다. (https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch)

@mateuscb 의 제안을 확장하려면 파일 탐색기의 컨텍스트 메뉴에서 특정 폴더를 마우스 오른쪽 버튼으로 클릭하고 "폴더에서 문제 찾기"를 수행하는 것이 좋습니다. 사용자는 범위 대 속도 간의 균형을 결정합니다.

@ajayRaghav37 제안을 수행하지 마십시오. vscode가 중단됩니다.
젠장, 앞으로 다시는 ts 코드를 작성하지 않을 것입니다)

이것이 언제 파이프라인에 포함될 것인지에 대한 업데이트나 아이디어가 있습니까? 이 기능을 즉시 사용할 수 있으면 좋을 것입니다.

ES-Lint는 VS Code에 새로운 작업을 도입했습니다. 작업 공간 설정에서 활성화해야 합니다.

"eslint.provideLintTask": true

터미널 메뉴로 이동하여 작업 실행을 선택한 다음

eslint: 전체 폴더를 린트합니다.

터미널에서 다음 명령을 실행하여 대부분의 문제를 자동으로 수정할 수도 있습니다.

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

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

우리는 여전히 VS Code에서 문제 스캐너를 기다리고 있지만 eslint를 사용하는 경우 이것은 충분히 좋은 대안입니다.

실제로 더 큰 프로젝트에 필요한 기능입니다. 업데이트가 있습니까?

@ajayRaghav37 , eslint가 타이핑 오류를 잡을 수 없는 것처럼 보입니다. 단지 linting 규칙일 뿐입니다:

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

+1

이 위로. 또한 내장 TS 검사 및 린트를 비활성화하고 빌드 작업의 결과만 사용하는 것이 가능해야 한다고 생각합니다.

+1

이제 이 문제를 해결하기 위해 tsc --noEmit -w 를 실행합니다.

하지만 VSCode와 ts-server 를 공유하는 것이 더 좋을 것이라고 생각합니다.

그런데 왜 그렇게 오랫동안 시행되지 않았습니까?

여기 TS 언어 서버에 대해 잘 아는 사람이 있습니까? LSP API에 이것을 IDE에 전달할 방법이 없습니까? 이것이 성능 문제입니까? 분명히 사람들은 이 기능의 부족에 대해 열정적이므로(저는) 이 기능이 결승선을 통과하는 데 커뮤니티 도움에 관심이 있을 것이라고 생각합니다.

그러나 여기서 문제가 VS Code 팀의 인력 부족인 경우입니다.

문제가 다른 경우(VS Code 아키텍처에 대한 더 큰 영향, LSP 변경 필요, 불명확한 성능 영향, UX 고려 사항) 이 사실을 아는 것은 겉보기에 간단해 보이는 이 기능이 왜 그렇게 많은 시간이 걸리는지 설명하는 데 도움이 될 것입니다.

이 문제에 대한 책임이 Visual Studio Code 팀이 아니라 TypeScript 팀에 있다는 점에 대한 다양한 의견이 있습니다. 그러나 이것은 VS Code에 내장된 '@ts-check' 기능에도 문제가 있습니다. 'tsc' 명령을 실행하는 작업을 사용하기 위해 이 게시물에서 언급한 해결 방법은 tsc가 설치되어 있지 않기 때문에 작동하지 않습니다(저는 @ts-check 및 jsdoc만 사용하고 있습니다).

이전에는 오류를 찾기 위해 프로젝트의 모든 파일을 클릭하곤 했습니다. 그것은 지루한 일이었지만 적어도 파일을 닫았을 때 사이드 바에서 문제가 사라지지 않았습니다. 지난 몇 달 간의 업데이트 중 하나 이후에 이 문제가 도입되었습니다: #73153.

이것이 가장 먼저 해결해야 할 모든 문제 중 가장 중요하지 않을 수 있습니까? IDE는 수정될 때까지 중단됩니다.

나는 동의한다.

언제?

위의 '허용된' 솔루션이 작동하지만 일부 필드는 더 이상 사용되지 않습니다.

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

나를 위해 작동합니다.

또한 아직 작업이 없는 경우 tasks.json 파일을 만드는 방법은 https://code.visualstudio.com/docs/editor/tasks 를 참조

이와 같은 빌드 작업으로 tsc 를 실행할 때 VS Code의 내장 TS 서버를 비활성화할 수 있습니까? 내가 묻는 이유는 그렇지 않으면 내장 TS 서버의 오류와 작업의 오류, 때로는 동기화되지 않는 두 가지 오류 세트가 발생하기 때문입니다.

IDE가 손상되어 Typescript 프로젝트 작업에 사용할 수 없습니다. 그래서 버전 1.28.2를 고수하고 업데이트를 비활성화해야 합니다.

이상하지만 이전에는 어떻게든 작동했습니다. 무슨 일이야? 그리고 언제 다시 작동합니까? 벌써 1년이 지났는데 변화의 기미가 보이지 않는군요...

2019년 10월이며 이것은 여전히 ​​대량입니다.

다른 IDE가 제공하는 기능에 대해 3년.... NNNNICCCEEEEEEEEEEEEEE

다른 IDE가 제공하는 기능에 대해 3년.... NNNNICCCEEEEEEEEEEEEEE

VSCode는 IDE가 아님을 기억하십시오. 그것은 Editor와 IDE 사이에 있는 것입니다.
어쨌든, 나는 그들이 그것을하기를 바랍니다

다른 IDE가 제공하는 기능에 대해 3년.... NNNNICCCEEEEEEEEEEEEEE

VSCode는 IDE가 아님을 기억하십시오. 그것은 Editor와 IDE 사이에 있는 것입니다.
어쨌든, 나는 그들이 그것을하기를 바랍니다

무슨 상관이야. 그러나 ts 파일을 확인하기 위해 빌어먹을 작업을 시작하고 실행할 수도 없습니다.

제공된 가이드는 완전히 새로운 빌어먹을 프로그래밍 언어를 배우는 것처럼 보입니다.
우리는 일하고 생산합니다. 나는 ts 파일을 IDE에서 검사하는 스크립트를 올리기 위해 모든 웹팩(및 이와 유사한 도구)을 배우는 데 낭비할 시간이 없습니다. t는 IDE의 동일한 작성자가 올바르게 만든 언어도 지원합니다....

무슨 헛소리

무슨 헛소리

약간의 관점:

Microsoft는 일부 소프트웨어를 만들어 무료로 제공했습니다.
이 소프트웨어는 감사하는 수백만 명의 사람들에게 도움이 됩니다.
Microsoft는 귀하에게 이 소프트웨어를 사용하도록 강요하지 않습니다.

당신은 그들이 이론적으로 할 수 있는 것만큼 완벽하지 않기 때문에 당신에게 무언가를 무료로 제공하는 것에 대해 화를 냅니다.

또한 그는 동일한 "IDE"의 언어를 사용하고 IDE는 오픈 소스이며 pull 요청을 수락합니다...

나는 이것을 오랫동안 지켜보았고 여전히 오류 및 경고를 추적하는 더 나은 방법을 기다리고 있으며 공개 출시 이후 사용하고 있습니다.

즉, VS Code는 의심할 여지 없이 JS/TS 개발을 위한 최고의 IDE입니다. 심지어 Github에 이어 두 번째로 최고의 MS 제품일 수도 있습니다. 기능과 성능이 확실히 개선되었으며 확장 기능의 엄청난 양은 저를 매우 기쁘게 합니다. 예, 문서가 더 나을 수 있지만 모든 기술 문서에 대해 그렇게 말할 수 있습니다.

VS Code 팀은 더 나은 도구와 통합을 제공하기 위해 끊임없이 노력하고 있다고 확신합니다.

그리고 나는 우리가 여전히 새로운 기능을 요구하거나 정중하게 이 기능을 계속 올릴 수 있다고 믿습니다.

해결 방법에 추가 - 이제 tsc -w의 출력을 모니터링하기 위해 미리 구성된 작업이 있는 것 같습니다. Mac에서 터미널 -> 작업 구성... -> tsc: watch - tsconfig.json. 그런 다음 ctrl+shift+B를 누르고 작업을 실행합니다.

3년 후... 소식이 있나요?

대규모 리팩토링 중. 영향을 받는 모든 파일을 닫으면 더 이상 모든 오류가 표시되지 않는다는 것을 깨닫지 못했습니다.

3년 아직 열려있습니다 :댄서:

3년, 아직 열려있다

예, 바보의 무작위 downvotes.

그나저나 이건 짜증나는 문제야!!! 심각한 비즈니스 프로젝트에 수백 개의 파일이 있다는 것을 알고 계셨습니까?
마음으로 어떻게 그들을 추적해야합니까?

사람들이 IDE를 사용하는 기본 기능 중 하나입니다.....

그리고 이제는 Visual Studio와 Intellisense에도 때때로 전파되는 것 같습니다.

Btw 작업은 최소한 이를 완화하는 것으로 보이며 ts 파일의 경우 일부 제어 스크립트도 사용할 수 있는 것 같습니다. vscode의 확장 관리자에서 모든 angular/typescript 확장으로 설치되는지 여부는 모르겠지만 작업 검색 표시줄([여기]에 표시됨)(https://code.visualstudio.com)에서 검색하면 /docs/editor/tasks) 컴파일할 때마다 트릭을 수행하는 시계 또는 이와 유사한 것을 검색할 수 있습니다(다른 작업인 일반 컴파일 프로세스와 함께 수행하는 것으로 보임).

나는 이것 때문에 문제 탭이 쓸모없다고 생각해서 절대 사용하지 않는다. 대신 터미널에서 실제로 필요한 것을 제공하는 몇 가지 명령을 실행합니다. 예를 들어 프로젝트에 대한 모든 컴파일러 오류가 있는 경우 tsc -w 합니다. 내 프로젝트의 모든 문제를 보고 싶거나 전혀 보고 싶지 않습니다. 나는 파일이 열리든 말든 상관하지 않습니다. 그것은 관련이 없습니다.

글쎄, 누군가가 Problems 탭에서 열린 파일에 대해서만 오류를 보는 것이 그렇게 중요하다면 그대로 두십시오.

그러나 Visual Studio에서와 같이 Build Output 와 같이 다른 탭을 만들 수 있습니까?

이 탭은 컴파일러의 오류 및 경고를 간단한 한 줄 텍스트로 표시하고 이를 두 번 클릭하면 파일이 열리고 오류가 있는 줄에 바로 캐럿이 배치됩니다.

또한 F4 / Shift-F4 바로 가기는 다음/이전 오류로 이동하는 것이 좋습니다(그러나 이것은 그렇게 중요하지 않습니다).

이 탭을 완전히 지우고 편집할 때마다 다시 채우십시오. 그것으로 충분할 것입니다.

아니면 누군가가 이에 대한 확장을 만들 수 있습니까?

모든 .ts 파일을 열려면 "일치하는 파일 열기" 확장자를 사용하고 있습니다. 성능이 약간 무겁지만 적어도 작업을 완료합니다.

typescript 언어 서버가 단일 스레드이고 C#의 컴파일러처럼 작동하지 않기 때문이라고 생각합니다.
가끔 파일을 열고 # 명령 팔레트를 사용하여 이름으로 유형을 찾으려고 하는데 아무 일도 일어나지 않기 때문에 여전히 이 기능을 기다리고 있습니다. 😞

엣지에서 살고 싶은 사람들을 위해 다음 VS Code 내부자 빌드는 실험적인 프로젝트 전체의 오류 보고를 가능하게 하는 "typescript.tsserver.experimental.enableProjectDiagnostics" 설정을 도입합니다.

이것은 생산 준비가 되지 않았다는 점에 유의하십시오! 대규모 프로젝트에 대한 성능 문제가 알려져 있으며 인텔리센스가 손상될 수 있습니다.

이 설정을 사용하는 동안 문제가 발생하면 새 문제를 열어주세요.

엣지에서 살고 싶은 사람들을 위해 다음 VS Code 내부자 빌드는 실험적인 프로젝트 전체의 오류 보고를 가능하게 하는 "typescript.tsserver.experimental.enableProjectDiagnostics" 설정을 도입합니다.

이것은 생산 준비가 되지 않았다는 점에 유의하십시오! 대규모 프로젝트에 대한 성능 문제가 알려져 있으며 인텔리센스가 손상될 수 있습니다.

이 설정을 사용하는 동안 문제가 발생하면 새 문제를 열어주세요.

잘했어~

이 기능의 진행 상황을 어디에서 확인할 수 있습니까? 준비가 되면 VS 코드의 표준 버전에 추가되기를 간절히 기다리고 있습니다.

엣지에서 살고 싶은 사람들을 위해 다음 VS Code 내부자 빌드는 실험적인 프로젝트 전체의 오류 보고를 가능하게 하는 "typescript.tsserver.experimental.enableProjectDiagnostics" 설정을 도입합니다.

이것은 생산 준비가 되지 않았다는 점에 유의하십시오! 대규모 프로젝트에 대한 성능 문제가 알려져 있으며 인텔리센스가 손상될 수 있습니다.

이 설정을 사용하는 동안 문제가 발생하면 새 문제를 열어주세요.

놀라운 작업을 위해 Visual Studio Code에 기여한 모든 분들께 감사드립니다.

엣지에서 살고 싶은 사람들을 위해 다음 VS Code 내부자 빌드는 실험적인 프로젝트 전체의 오류 보고를 가능하게 하는 "typescript.tsserver.experimental.enableProjectDiagnostics" 설정을 도입합니다.

이것은 다른 린터와 어떻게 작동합니까?

내가 언제 내가 활성화 문제 했어 "typescript.tsserver.experimental.enableProjectDiagnostics" , 타이프 스크립트의 린터은 결국 통과의 토끼 구멍 아래로 이동 node_modules , 배포 파일과에서 오류의 수백을 굴착하는 경우에도 "exclude" tsconfig.json 에는 "node_modules" 됩니다. 이것을 디버깅하는 방법을 잘 모르겠습니다.

또한 @vdh 와 동일한 효과를

내 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/**"
]

이상적일 것입니다. 실제로 0이 있는 프로젝트에서 1,000개 이상의 문제를 보는 것은 끔찍합니다.

@blackfan23 node_modules 급락으로 인한 과도한 CPU 변동으로 인해 옵션이 아닙니다.

@vdh tsconfig에서 skipLibCheck 를 true로 설정하고 "문제" 탭이 node_modules의 오류 표시를 중지했습니다.

그러나 이 stackoverflow 스레드를 기반으로 이 옵션을 켜면 유형 검사가 저하됩니다. VS 코드 또는 타이프스크립트 팀의 누군가가 이 옵션을 켤 때의 장단점을 설명할 수 있다면 감사합니다.

@mjbvz
잘 작동합니다! 감사 해요!
하나의 명령으로 이러한 오류에 대해 "모두 수정"을 실행할 수 있습니까?

Typescript가 아닌 다른 언어는 어떻습니까? 예를 들어, 프로젝트에 수백 개의 PHP 파일이 있고 개별 파일에 대해 Intellephense 확장에서 보고된 문제를 볼 수 있지만 실제로 원하는 것은 전체 작업 공간에 대해 진단을 실행하는 것입니다.

예, 이것은 또한 ESLint가 node_modules ("ESLint: 구성을 로드하지 못했습니다"가 거기에 있는 디렉토리를 트롤링할 때)로 같은 급강하를 하는 문제를 일으킵니다. 이 버그를 린터별로 패치하려고 하는 대신 블랙리스트 또는 무언가가 필요합니다.

node_modules를 제외하는 것은 no1 수정 사항이 될 것입니다 :)

이것은 부팅이 가능한 것처럼 보이지만 - 귀하의 마일리지는 다를 수 있으며 물론 보증은 없습니다.

package.json에 typescript 3.9.2가 있고 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 나는 이것을 활성화하려고 시도했고 나는 그것을 끌 때와 비교하여 "코드 도우미(렌더러)" 프로세스에서 꽤 높은 CPU 사용량을 봅니다. 이것이 관련이 있는 것 같습니까(프로세스 이름의 "렌더러"는 그렇지 않다고 제안하지만 몇 번 토글했습니다). 프로젝트는 크지 않습니다(https://github.com/Dart-Code/Dart-Code).

영원히 지속되지는 않지만 MacBook 팬을 충분히 회전시켜 지금 당장은 켜기보다는 꺼 놓을 것입니다.

지금까지에 어떤 조사가 된 이유 "typescript.tsserver.experimental.enableProjectDiagnostics" 항상 모든에 다이빙 내부의 파일 node_modules , 린터의 CONFIGS 설정에서 우리의 다양한 시도가 실패에도 불구하고 피하기 위해 node_modules ?

이 잠재적으로 멋진 기능은 원치 않는 파일 및 디렉터리를 반복하여 발생하는 과도한 CPU 변동으로 인해 완전히 죽기 때문에 실망스럽습니다... 😢

PROBLEMS 패널에 나타나는 node_modules TypeScript 오류와 함께 위에서 언급한 @vdh 와 동일한 문제를 PROBLEMS 내가 일으킨 구성 문제.

다음과 같은 다양한 tsconfig.json 설정을 시도했습니다.

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

문제가 보이는지 아닌지에 패턴이 있는지 잘 모르겠습니다. 내가 의심되는 몇 가지 일이 일어나고 있었을 수 있습니다.

• 무작위로 왔다가 사라지는 것처럼 보였고 때로는 vscode를 다시 시작하는 것이 잠시 도움이 되었지만 나중에 다시 나타납니다.
• 일부 프로젝트에 다른 프로젝트보다 더 많은 영향을 미치는 것으로 나타났습니다.
• 지금은 문제가 표시되지 않는데 최근 업데이트로 문제가 해결되었을 수 있습니까? 나는 여전히 Insiders 에디션을 실행하고 있습니다.

위의 요점에 대해 완전히 확신하지 못해서 혼란스러울 수 있습니다. 관련이 있을 수 있는 또 다른 일화를 추가하는 것뿐입니다. 현재 버전에서 여전히 문제를 보고 있는 사람이 몇 명 있다면 새 문제를 제출할 가치가 있습니다. 아직 해보지 않아서 확실하지 않습니다.

나는 같은 문제가 있었고 #90430의 해결책은 typescript-tslint-plugin 을 사용하는 것이었습니다.

@enko TSLint는 2019년부터 ESLint 를 위해 더 이상 사용되지 않으며 사용되지 않는 linter에 대한 플러그인을 옹호하는 것은 이 문제에 대한 좋은 솔루션이 아닙니다.

typescript.tsserver.experimental.enableProjectDiagnostics 를 비활성화해야 했습니다.

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

매우 느림( 단일 파일을 저장하는 데 2분).

또한 나타나거나 사라지는 node_modules에서 임의의 TS 오류를 발견했습니다.

작업에서 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 / @patroza / @jgoux / other ... 해당 문제에 대한 단서를 더 추가할 수 있다면 이 문제를 해결하는 데 도움이 될 수 있습니다.

@jgoux 와 같은 문제는 "source.fixAll.eslint": true 에서는 작동하지 않습니다. - eslint는 열려 있는 파일뿐만 아니라 프로젝트의 모든 파일을 확인하기 시작하고 모든 단일 변경에 대해 전체 프로젝트를 다시 확인합니다. VSCode가 멈춥니다. 기본 ESLint 동작을 수정하는 이유를 모르지만 실제로는 차단입니다.

"typescript.tsserver.experimental.enableProjectDiagnostics"는 실제로 수정 및 개선되어야 합니다. 이것은 타이프스크립트를 이미 있는 것보다 훨씬 더 강력하게 만들 것입니다.

@samesfahani-tuplehealth가 게시한 솔루션은 매우 잘 작동합니다. 이것은 가져온 유형을 한 파일에서 다른 파일로 이동하고 가져오기가 중단된 모든 위치를 찾아야 할 때 중요합니다. CPU 사용률이 높지는 않지만 필요할 때 실행할 수 있습니다.

@phatmann 그건 해결 방법이지 , _아닌_ 입니다. 기능을 무시하고 _완전히 다른 기능_을 대신 사용하는 것은 성능 문제를 해결하는 방법이 _아닙니다_. 나는 이것에 대해 끈질긴 것을 싫어하지만 이 훌륭하지만 실험적인 기능을 수정하는 데 관심을 끄는 많은 소음을 원하지 않습니다. 가치가 있는 관심을 받으면 매우 유용한 것이 될 수 있습니다.

@Vdh 물론 맞습니다. (실제로 작업의 더 간단한 버전인 내장 tsk:watch 작업은 해결 방법에 대해 똑같이 잘 작동합니다). 내 혼란은 다음과 같습니다. 해결 방법이 너무 효과적이고 효율적이어서 이 문제에서 언급된 실제 기능이 필요하지 않다고 생각합니다. 내가 뭔가를 놓치고 있습니까?

@phatmann Typescript 감시 작업을 실행하고 싶다면 이미 실행할 수 있습니다. 이것은 단지 TS 검사를 실행에 대한 없습니다. 그것은 모든 프로젝트 파일을 VSCode의 모든 검사를 실행합니다. Typescript, ESLint, CSpell 등... 파일을 여는 것을 잊었더라도 전체 프로젝트에서 오류를 찾을 수 있다는 사실은 정말 강력하고 유용합니다(모든 파일에서 수동으로 각 린터를 실행하지 않고도 터미널에서 외부로).

현재 유일한 주요 결함은 node_modules 와 같이 일반적으로 금지된 폴더를 포함하여 말 그대로 모든 파일을 지나치게 실행한다는 것입니다.

vscode로 어떻게 해야할지 검색했지만 얻은 것은 4년 미해결 문제... 😢

돈은 얼마이고 어디로 보내야 합니까?

node_modules를 스캔하는 이 기능에 CPU 문제나 문제가 있는 경우 다음을 포함 tsconfig.json 이 없는지 확인하십시오.

"files": []

그렇지 않으면 기본값은 tsconfig가 포함된 폴더 또는 그 아래에 있는 모든 TypeScript 파일을 포함하는 것이므로 너무 많은 파일을 분석할 수 있습니다.

이 기능은 원사 작업 공간과 복합 유형 스크립트 "프로젝트"를 사용하는 대규모 모노레포에서 잘 작동합니다.

훌륭한 조언 @dinofx. 또한 문서에 따라 files 대신 include 및 exclude 사용할 수 있습니다.

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

맞습니다. 하지만 "포함" 글로브와 일치하지 않는 것을 제외할 필요는 없습니다.

"files": [] 는 "작업 공간" tsconfig.json 파일(많은 다른 tsconfig.json 파일을 참조하는 파일)에 대해 더 간결합니다. 잘 문서화되어 있지는 않지만 패키지 및 작업 공간에 대한 구성 파일의 이름을 tsconfig.json . 그렇지 않으면 많은 기능이 제대로 작동하지 않습니다(이 기능, 참조 찾기, 리팩토링 등).

확장된 공유 구성의 경우 tsconfig.browser.json , tsconfig.node.json 등과 같은 이름을 지정하는 것이 좋습니다. 그 이름은 "files" 또는 "includes" 이므로 생략할 수 있습니다.

@dinofx 파일 순회 문제는 Typescript에만 국한되지 않습니다. 또한 모든 사람이 모노레포를 사용하는 것은 아닙니다.