롤이 필요해

이 기능의 현재 사용 사례는 공백을 처리하는 단위 테스트입니다. 우리는 합당한 이유로 코드베이스에서 "후행 공백 없음" 규칙을 설정했지만 블록 수준에서 이를 압도할 수 없다는 것은 ES6 템플릿 문자열을 사용하여 후행 공백 및 캐리지 리턴을 쉽게 테스트할 수 없다는 것을 의미합니다. .

Mathjs에서 사용자 지정 번들링 _ a.k.a partial import _ 을 사용하는 사용 사례 중 하나

// tslint:disable:no-var-requires
import core from 'mathjs/core'

// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'


const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc

math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc

export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile

전체 파일에 대한 오류를 무시하고 싶습니다. ES5로 변환하고 싶지만 지금은 Babel을 사용해야 하는 ES6 JS 코드를 상속받았습니다. 파일 이름을 .ts로 바꾸고 TS로 변환하는 것이 좋을 것입니다.

@ptallett allowJs 를 사용하여 $ .js 파일을 컴파일하고 컴파일에 포함할 수 있습니다. 기본적으로 파일 상단에 // @ts-check 주석이 없거나 checkJs 를 설정하지 않는 한 .js 파일에 오류가 발생하지 않습니다.

나는 여전히 이 기능을 좋아할 것입니다. 테스트 파일에 앉아 있고 확장자가 .ts이므로 어떤 매개변수가 어디로 가는지 가져오고 쉽게 볼 수 있으며 src 파일 옆의 디렉토리로 컴파일하는 것은 제 사용 사례에 훌륭합니다. .

의도적으로 일부 매개변수를 제외하거나 함수에 원래 사용했던 것과 다른 유형을 지정하려고 하기 때문에 대부분의 줄은 이제 빨간색으로 표시되며 런타임에도 확인할 때 오류가 발생할 것으로 예상합니다.

도처에 빨간 선이 많이 없는 것이 좋을 것입니다. :)

그것에 대한 업데이트가 있습니까, 아니면 누구든지 이것을 수행하는 좋은 방법을 찾았습니까?

lodash 및 특히 lodash/fp 를 TypeScript와 함께 사용하는 것은 매우 고통스럽고, lodash 및 @types/lodash 의 최신 버전에서도 매우 애매한 오류 메시지로 끝날 수 있습니다.

다음 블록에 대한 오류를 무시하는 @ts-ignore-block 를 가질 수 있다면 _당신이 무엇을 하고 있는지 알고 있는_과 같은 사용 사례에 아주 좋을 것입니다. :-)

저는 수많은 전역 범위 변수가 있는 레거시 코드로 작업하고 있으며 모든 줄에 @ts-ignore를 작성하는 것이 지루해집니다. 이에 대한 업데이트가 있습니까?

또한 이 요청에 대한 업데이트를 찾고 있습니다. 감사 해요!

이것은 또한 내가 하고 있는 일(즉, 코드 블록에 대한 특정 검사를 비활성화해야 하는 생성된 Vue 템플릿 렌더 기능 유형 검사)에 매우 중요합니다.
이 문제와 함께 #19139는 매우 중요합니다. 특히 코드의 많은 부분에 적용할 때 특정 검사만 비활성화하기를 원할 것이기 때문입니다.

구멍 파일을 억제하면 작업 공간 설정 등에 저장하기 위해 vs 코드와 같은 편집기에 추가할 수 있습니다.

이것도 필요합니다. graphql-code-generator 를 사용하여 내 GraphQL 스키마에 대한 유형으로 전체 ts 파일을 자동 생성하고 있으며 noUnusedLocals를 트리거하는 관련 없는 가져오기가 있습니다.

/* tslint:비활성화 */

암호

/* tslint:활성화 */

// @ts-ignore-start
// @ts-ignore-end

다음과 결합 가능: https://github.com/Microsoft/TypeScript/issues/19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn 이것은 tslint가 아닙니다.

때때로 물건을 옮기고 리팩토링하는 동안 CLI 옵션을 사용하지 않고 전체 파일을 일시적으로 무시하고 싶습니다(즉, 컴파일하지 않음).

가장 빠르고 쉬운 것은 파일 맨 위에 있는 플래그입니다.

// @ts-ignore-file

@lonix1 사용 사례는 다음에서 다룹니다.

// @ts-ignore-start
// @ts-ignore-end

// @ts-ignore-end 부분을 사용할 필요가 없습니다. 많은 린트 도구가 그런 식으로 작동합니다.

@mgol 이 스레드를 탈선시키고 싶지 않습니다... 하지만 제안을 시도했습니다 - 감사합니다! - 그리고 그것은 나를 위해 작동하지 않았습니다. 나는 파일의 상단에 줄을 함께 넣고 상단에 하나를, 하단에 다른 하나를 시도했습니다.
다른 사람이 작동하도록 할 수 있습니까?

@lonix1 @Blanen 의 제안이 당신에게도 효과가 있다는 것을 의미했습니다 // @ts-ignore-start + // @ts-ignore-end 와 // @ts-ignore-file 를 구현하기 위해 TypeScript가 필요하지 않습니다. // @ts-ignore-start + // @ts-ignore-end 이면 충분합니다. 이것은 구현되지 않았기 때문에 이 문제가 여전히 열려 있습니다.

@DanielRosenwasser 이것은 빌드 중에 ts 파일이 다른 폴더에 저장될 때만 작동합니다. 프로젝트가 ts 파일 옆에 js 파일을 배치하도록 설정되면 그렇지 않습니다. 또한 js 파일이 '컴파일'됩니까(예: es5로 변환)? 레거시 코드를 전송할 때 이것은 정말 도움이 될 것입니다.

이 기능이 필요합니다.

사용 사례:

TypeORM 은 null을 허용하거나 허용하지 않을 수 있는 열이 있는 DB 엔터티 클래스를 생성할 것으로 예상합니다. 많은 열(따라서)은 nullable이 아니므로 속성이 무조건적으로 정의된 특정 유형인 것처럼 클래스 정의를 제외하고 는 처리되어야 합니다. 그러나 Typescript에서는 모든 열을 강력한 형식으로 정의해야 합니다. 따라서 우리는 다음과 같은 많은 엔티티로 끝납니다.

@Entity('investigation')
export class InvestigationEntity {
    @PrimaryGeneratedColumn('uuid')
    // @ts-ignore TS2564
    public investigationId: string;

    @Column({ type: 'uuid' })
    // @ts-ignore TS2564
    public userId: string;

    @Column({ type: 'jsonb' })
    // @ts-ignore TS2564
    public metadata: IEncryptedJSONContainer;
}

모든 열은 필수이며 (따라서) 값을 포함해야 하지만 TypeORM이 작동하는 방식으로 인해 모든 속성은 초기화가 없는 방식으로 정의되어야 합니다. 전체 클래스(따라서/또는 파일)에 대해 이 특정 ORM 파생/특정 문제를 억제할 수 있으면 매우 편리합니다.

@haggholm public metadata!: IEncryptedJSONContainer ts-ignore 를 선호하는 이유가 있습니까?

@RyanCavanaugh 무지! 나는 문서에서 그 기능을 놓쳤다. 죄송합니다; 무시하세요.

나는 하고 싶다

// @ts-ignore-start
--strick null 검사, 하나의 특정 파일에 대해

이것이 typescript를 사용하여 비공개 필드와 메서드를 단위 테스트하는 모습입니다. 코드 무시에 전념하는 6 줄이 있습니다. 끔찍한. 내 눈을 피합니다. 블록 무시에 대한 모든 해결 방법은 대단히 감사하겠습니다.

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

글쎄, 나는 새로운 문제를 추가하려고했지만이 문제가 그것을 다룰 것이라고 생각합니다.

@ts-ignore 는 여러 줄 및 한 줄 가져오기를 다르게 처리합니다!

타이핑이 없거나 NoImplicitAny 없이 작성된 npm 모듈이 여전히 많이 있습니다.
"암시적" 오류가 발생하면 가져옵니다.

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

따라서 @ts-ignore를 사용할 수 있습니다.

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

그러나 Prettier와 같은 자동 가져오기 및 포맷터로 작업할 때 다음과 같은 일이 발생합니다.
(Prettier에서 포맷)

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

나는 그것을 고칠 수 있다:

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

또는

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

그러나 한 줄 가져오기에서 다음과 같이 보이기 시작합니다.

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

모듈에서 가져온 요소의 수에 따라 자동 가져오기 및 서식이 한 줄 가져오기와 여러 줄 가져오기 간에 변경되기 때문에 이렇게 작성해야 합니다.
가져오기 코드를 수동으로 변경하면 자동 가져오기의 목적이 실제로 무효화됩니다.

모든 단일 가져오기에 대해 ts-ignore-start 및 ts-ignore-end를 작성할 필요가 없는 것이 좋습니다.
따라서: //@ts-ignore 가져오기(다음 줄 뿐만 아니라)는 ts-ignore가 처리해야 하는 것입니다. (또는 @ts-ignore-block / @ts-ignore-import와 같은 다른 무시)

전체 파일에서 특정 오류를 억제해야 합니다.

// @ts-ignore-all TS1206

/*
... rest of the file
*/

이 스레드에서 언급된 사용 사례를 처리하기 위해 // @ts-ignore-start 및 // @ts-ignore-end 주석을 제안한 위의 사람들과 동의합니다.

이것은 현재 // @ts-ignore 지시문과 매우 유사하고 맨 위에 // @ts-ignore-start 지시문이 있는 파일의 모든 오류를 무시할 수 있기 때문에 좋습니다.

위의 여러 제안에 대한 긍정적인 사용 사례가 있습니다. 내가 제안:

현재 동작으로 @ts-ignore
@ts-ignore TSxxx [TSxxx ...] 특정 오류 억제
@ts-ignore-start 무시할 블록 시작
@ts-ignore-start TSxxx [TSxxx ...] 블록에 대한 특정 오류 억제
@ts-ignore-end 엔드 블록
@ts-ignore-all 나머지 파일에 대한 오류 억제
@ts-ignore-all TSxxx [TSxxx ...] 나머지 파일에 대한 특정 오류 억제

"특정 오류"에는 tsconfig 또는 TSxxx 오류의 사용자 정의 그룹과 유사한 명명된 그룹이 포함될 수 있습니다.

가져온 모듈을 중첩하는 무시 블록의 값이 확실하지 않습니다. 내 기본 설정은 가져온 모듈 파일 내에서 명시적인 ts-ignore 블록입니다. 그러나 타사 라이브러리를 가져올 때 이에 대한 이유가 있을 수 있으므로 여기에서 경계합니다.

원하는 .tsignore 파일

.npmignore 및 .gitignore 처럼

무시 블록이 있어야 합니다. 나는 puppeteer 프레임 워크에 갇혔습니다. puppeteer에는 페이지에서 임의의 스크립트 블록을 실행할 수 있는 "평가" 방법이 있습니다. 이 임의의 스크립트 블록은 페이지에서 사용할 수 있는 함수에 대한 참조를 포함할 수 있습니다. 즉, 함수 참조는 런타임에 사용할 수 있습니다.

// @ts-ignore-start
// @ts-ignore-end

이것은 레거시 코드 덩어리로 작업할 때 매우 편리하여 사람들이 TypeScript로 전환하는 것을 덜 고통스럽게 만듭니다.

에 대한

// @ts-ignore-start
// @ts-ignore-end

이전에 이 제안을 했고 구문을 변경하고 싶습니다.
시작-중지 또는 시작-종료로 설정
start 및 end (동사)는 반의어가 아니며 타이프스크립트에 들어가면 영원히 귀찮게 됩니다.

내겐 멋진 일이야

// @ts-ignore-begin
// @ts-ignore-end

매우 필요한 기능입니다.

이것이 여전히 불가능한 이유는 무엇입니까? :-(

나도 차단 무시가 필요해

+1

+1

이것에 대한 어떤 업데이트?

🙏🏻

그리고 eslint를 사용하여 평소와 동일하게 하면?

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

위에서 언급한 대로: 예를 들어 사용되지 않은 vars가 발생할 수 있는 TS 코드(예: swagger 사용)를 생성하는 즉시 이 기능이 필요합니다.

+1

//@ts-ignore-file 없이는 TS로 마이그레이션할 수 없습니다.

그래서 아무도 눈치채지 못한다는 것은 사실이 아니다.

@RyanCavanaugh 커뮤니티에는 분명히 이것이 필요합니다. 이것이 해결되지 않은 이유가 있습니까? 감사 해요!

Typescript가 울고 내 렌더링을 차단하지 않고도 실행 가능한지 확인하기 위해 작동하는 솔루션을 가지고 놀 수 없기 때문에 지금은 이것으로 어려움을 겪고 있습니다.

현재 이 기능이 필요합니다.

우리는 관심이 없는 일부 함수에 대한 노드 유형이 있는 공개 라이브러리를 가져오고 있습니다. 따라서 단일 가져오기에 // @ts-ignore를 사용하는 것이 좋을 것입니다. skipLibCheck 를 사용하여 무시하는 대신 모든 라이브러리.

처음에는 // @ts-ignore-file 아이디어를 좋아했지만 // @ts-ignore는 일관성을 위해 더 잘 작동할 것입니다.

그래서.... typescript 파일에서 //@ts-nocheck 를 지원하는 #33383을 열었습니다. 이제 우리는 _TypeScript_ 컴파일러 팀이기 때문에 실제로 이해하지 못합니다. (가능성이 있는 문제를 수정하지 않고, 와아아아!!?!?) - typescript의 //@ts-ignore 도 팔이 꼬였기 때문에 문제가 되었습니다. 약간, 그래서 우리는... 더 이상의 억제 메커니즘을 추가하기를... 주저하고 있습니다. 그래서 여러분이 정말로 그런 광범위한 억제 메커니즘이 필요하다고 느낀다면 거기에 가서 👍

@weswigham , 이것은 아마도 가장 중요한 기능은 아닐 것입니다. 개발 중에 유용할 수 있습니다. 몇 줄의 코드에 임시로 주석을 추가하는 것처럼 개발하고 다른 곳에서 문제를 격리하려고 시도하는 동안 도움이 될 수 있습니다. 그러나 이 방법이 실제로 런타임 버그를 일으키는 방법을 찾지 못하도록 경고를 받고 싶습니다. 개발용으로만 이 기능을 활성화할 수도 있지만 빌드 시 오류가 발생합니다.

이 문제에는 여전히 "추가 피드백 대기 중"이라는 레이블이 붙어 있으므로 다음과 같은 내용이 더 있습니다.

새로운 아키텍처 방향을 빠르게 프로토타이핑할 때 TypeScript의 안내에 따라 새로운 아키텍처가 작동하는지 확인하고 싶습니다. 그러나 실험하는 동안 일시적으로 단위 테스트 파일의 유형 오류를 무시하고 싶습니다.

각 파일의 상단에 일종의 @ts-ignore- 주석을 추가하는 것은 충분히 쉬울 것입니다.

나는 @kumar303 의 필요성을 두 번째로: 단위 테스트에서 주어진 블록/파일에 대한 일부 검사를 끄는 것이 유익합니다. 왜냐하면 그러한 경우를 다룰 주장이 될 것이기 때문입니다.

@weswigham 컴파일러 플래그 뒤에 넣을 수 있습니다.

컴파일러 플래그 뒤에 넣을 수 있습니다.

필요 없음 - 3.7 베타 버전입니다.

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham 훌륭합니다. 감사합니다! 여기서 강력한 사용 사례는 파일에서 유형 검사를 일시적으로 무시하는 것이므로 @ts-nocheck 제거를 잊었을 때 실패하는 린트 규칙도 제공하는 것이 좋습니다.

.jsx 파일에서는 정적 graphQL 쿼리가 작동하지만 .tsx 파일에서는 작동하지 않는 gatsby에 문제가 있습니다. 이 제안이 더 수용 가능한 해결 방법이 될 수 있다고 생각합니다. (여기 https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5에서 발행)

이봐!
제안된 솔루션이 구현되었습니까?

// @ts-ignore-start
// @ts-무시 종료

매우 유익할 것이라고 생각합니다. 나는 그것에 대해 신경 쓰지 않을 것입니다.

3.7에서 전체 파일의 모든 오류를 억제하기 위해 //@ts-nocheck 에 대한 지원을 추가했습니다. 줄 수준 및 파일 수준 억제가 큰 소란 없이 _대부분의_ 요구 사항을 포함할 수 있다고 생각합니다. 체크를 해제해야 하는 체크된 파일 내에 충분히 큰 블록이 있는 경우, 전체 파일에 대한 체크를 비활성화하거나, 불쾌한 경우 체크되지 않은 청크를 자체 파일로 추출하고 해당 파일에 대한 체크를 비활성화하거나, 실패하면, 실제 문제가 있는 각 줄을 억제하시겠습니까? ts-ignore 는 단일 문제를 무시해야 하는 반면 ts-nocheck 는 단일 파일을 무시해야 합니다. 범위 기반 억제는 실제로 어떤 식으로든 특정 단위에 매핑되지 않으므로 어떻게 든 더 나빠 보입니다 (단일 문제 또는 억제하는 근본 원인에 매핑 할 수 없기 때문에). 적어도 오류 코드 특정 억제가 없으면 범위 기반 억제가 특히 편하지 않습니다.

나는 적어도 파일 상단에 단일 억제( //@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless ) 또는 개별 나쁜 것(tm)에 대한 개별 억제( //@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat )를 선호합니다. 나는 평생 동안 "여러 연속적인 쓰기 기본적으로 TypeScript에서 억제 기능을 사용해서는 안 된다고 생각하기 때문에 저는 이에 대해 _제로_ 공감합니다. 유형 문제인 경우 이를 캐스트할 수 있습니다(그래서 any , 캐스트 및 약식 모듈 선언이 존재함). 구문 문제라면 모든 것이 끔찍하고 어쨌든 깨질 것이므로 억제는 아무 작업도 수행하지 않습니다(억제 작업은 구문 분석 오류에 영향을 미치지 않음).

//@ts-nocheck 감사합니다. 그러나 이것은 코드 블록 검사를 비활성화하는 문제를 해결하지 못합니다.

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

// @ts-nocheck

흥미로운 사용 사례가 있습니다.

우리는 도토리를 사용하여 명령문을 DDL로 컴파일하는 Typescript로 ORM을 구축하거나 소유하고 있습니다.

Where 쿼리를 수행하려면 범위 변수를 전달해야 합니다.

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

이것은 단순히 Property 'id' does not exist on type 'xxx' 때문에 작동하지 않습니다.

@ts-ignore-start 로 래핑하면 다음과 같이 잘 작동합니다.

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

그러나 형식이 지정되고 줄 바꿈을 추가하기 시작하면:

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

더 이상 작동하지 않습니다.

이것은 단순히 다음과 같은 이유로 작동하지 않습니다.

그것이 바로 유형 수준 오류의 종류입니다. 정말로 그것을 억제하고 싶다면 액세스에 대해 as any 캐스트(또는 jsdoc에서는 /** <strong i="8">@type</strong> {any} */(expr) )가 있어야 합니다.

//@ts-nocheck 는 내 ts angular 프로젝트에서 작동하지 않지만 //@ts-ignore 는 작동합니다. 마이크로소프트를 위한 이번 호는 2017년에 시작되었습니다. 2017년! 와...

3년이 지난 지금 해결책이 없습니다. JavaScript 개발자가 typescript로 점프하고 싶어하지 않는다는 것은 놀라운 일이 아닙니다.

// @ts-ignore-start
// @ts-ignore-end

다음과 결합 가능: #19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn 이것은 tslint가 아닙니다.

이를 구현할 계획이 있습니까?

// @ts-nocheck
현재 유일한 옵션입니다 :(

여기에서 고려하기 위해 추가할 또 다른 사용 사례...

저는 몇 가지 기본적인 제어 흐름과 조건을 허용하는 사내 마크업 언어에서 많은 TypeScript 코드를 생성하는 코드입니다. 코드 생성 동작을 제어하는 ​​동안 코드 생성기에 전달되는 입력은 제어하지 않습니다(최종 사용자에게 달려 있음).

결과적으로 생성된 코드에는 쉽게 연결할 수 없는 코드가 있거나 열거형 상수에 대해 값을 테스트하는 중첩 코드가 있을 수 있으므로 TS2367의 경우 해당 블록 내부에 다른 열거형 상수에 대한 해당 변수의 또 다른 검사가 포함될 수 있습니다. 예를 들어:

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

손으로 작성한 코드를 사용하면 이 패턴을 쉽게 수정하고 피할 수 있습니다. 그러나 코드 생성에서는 불가능한 값을 불필요하게 테스트하는 입력을 제공하지 않는 것은 내 사용자(개발자, 유형을 알고 있습니다!)의 몫입니다.

형식 검사를 완전히 비활성화하고 싶지는 않지만 이 오류로 인해 코드 생성 코드를 사용할 수 있는 다른 메커니즘이 없습니다. 이상적으로는 모든 코드 생성 파일에 대해 이 오류 하나를 표시하지 않고 다른 모든 유형 검사는 유지합니다.

그대로 모든 유형 검사를 끄는 것 외에는 해결책이 없습니다. 어느 시점에서 TypeScript와 일반 JavaScript에서 많은 가치를 얻지 못하고 있습니다.

진심이야? 이것은 여전히 ​​미해결 문제이며 TS4에서 구현되지 않습니까? 🤦🏽

@ivnnv TS 3.9에서 // @ts-expect-error 를 사용할 수 있습니다. 여기를 참조하세요.

@ndraiman @ts-expect-error 개별 라인에 대해서는 작동하지만 블록 에는 작동하지 않으므로 "블록을 무시"하려면 많은 라인을 배치해야 합니다.

다음은 몇 가지 추가 피드백입니다.

또 무엇이 필요합니까? 이 기능을 사용하려면 커뮤니티에서 무엇을 해야 합니까?

이에 대한 가장 좋은 사용 사례는 만드는 모든 단일 유형에 any 를 쓰는 것의 대안입니다. 당신은 미학에 대해 동정심이 없을 수도 있지만(분명히 기분과 생산성에 영향을 미칠 것입니다), 일반적인 기대와 일치하는 대안이 있다는 것만으로도 받아들이는 것이 어렵지 않을 것입니다.

사람들은 받아들일 수 있는 것과 그렇지 않은 것에 대해 서로 다른 견해를 가지고 있습니다.

어떤 사람들에게는 너무 시간이 많이 걸리고 코드 포팅과 같은 일상적인 작업을 수행하는 동안 사람들이 가질 수 있는 흐름 상태를 제한합니다.
무시된 코드 블록을 가질 수 없고 대신 any 캐스트로 쓰레기를 버려야 한다는 것이 짜증나고 이상합니다. 이는 종종 가독성에 해로운 영향을 미칩니다(적절한 유형이 있을 때까지). 계속해서 새로운 주석을 작성해야 하거나 주의를 산만하게 만드는 데 탐닉하는 것은 _누군가가 코드 블록을 무시하는 이점을 보지 못한다는 이유로 _ 제 관점에서는 옳지 않습니다.

예시:

하나는 JS에서 TS로 프로젝트를 이식하고 다른 프로젝트는 타사에서 개발하고 있습니다.

이식된 프로젝트에서 따르는 구문 및 규칙은 예를 들어 es2015와 같이 이전이거나 더 명확한 구문과 더 적은 코드를 위해 더 이상 사용되지 않을 수 있습니다.

이 프로젝트를 이식할 때 일부 코드는 TypeScript로 이식하기가 매우 쉽습니다. 그럼에도 불구하고 필연적으로 더 많은 컨텍스트가 필요하거나 해당 유형을 생성하기 위해 한동안 생각해야 하는 임의의 동작을 가진 부울 및 함수를 통해 반쯤 생각하게 됩니다.

파일을 수정하는 동안 파일의 기능이나 코드 블록을 검사하지 않는 것은 정말 멋진 일입니다. 코드 블록을 무시하면 자신이 알고 있는 영역으로 빠르게 이동할 수 있고 나중에 사용할 특정 부분을 저장할 수 있습니다.

JavaScript를 TypeScript로 이식해야 할 때의 내 워크플로(코드는 하위 수준임):

1. .js에서 .ts 파일로 코드를 복사합니다.
2. TS가 용도별로 모든 유형을 유추할 수 있는지 확인
3. 사용법에서 유형을 수동으로 이해
4. 오류가 내 존재의 골칫거리임을 깨달아
5. 오류를 주석 처리하여 파일의 줄 수를 때때로 x3 ESLlint + TS로 향상시키십시오(많을수록 좋습니까?)
6. 나머지 파일을 신중하게 편집하고 더 많은 유형을 추가하면서 상단에 // @ts-check 를 제거하고 추가하십시오.

블록을 무시할 수 있다면:

1. .js에서 .ts로 코드 복사
2. TS가 용도별로 모든 유형을 유추할 수 있는지 확인
3. 사용법에서 유형을 수동으로 이해
4. // @ts-ignore-enable ... // @ts-ignore-disable 개별 기능 및 번거로운 코드 블록
5. 블록에 접근하여 유형을 추가할 때 주석 해제

가장 합리적으로 보이는 것을 스스로 결정하십시오. 더 많은 ESLint 규칙이 있는 프로젝트에 JS를 이식할 때도 마찬가지이며 대부분의 항목을 리팩토링해야 합니다.

ESLint에서 가능한 것처럼 하고 TypeScript에서 /* eslint:disable */ ... /* eslint:enable */ 를 사용할 수 있기를 바랍니다.

추신: 이 댓글을 확인했을 때 저와 다른 많은 사람들이 2017년부터 찾던 경험을 얻기 위해 20분 이상을 보냈다는 것을 깨달았습니다. 곧 3년이 지난 공개 문제에 대해 논평하기 위해서입니다.

@wswigham @RyanCavanaugh

알림:+1:

맏아들을 주는 대가로

@agusterodin 당신의 희생이 악당들의 눈길을 끈다.....

좋아, 나는 단지 간단한 PR을 제공하는 것을 제외하고는 실제로 아무 일도 일어나지 않는다 :)

그러나 개인적으로 TS 팀의 의견에 적극 동의합니다. 이 기능은 악의적이므로 @ts-ignore-enable (또는 @ts-ignore-start 사용하지 말고 항상 @ts-ignore 사용을 피해야 합니다. , 무엇이든).
하지만 가끔은 속담에 drinking posion to satisfie thirst 가 있습니다. 나쁜 선택이라는 것을 알고 있지만 꼭 필요한 경우입니다.

편집: 설명 및 예제를 추가합니다.
이 PR ts-ignore-enable 및 ts-ignore-disable 두 개의 지시문을 추가합니다.

1. ts-ignore-enable만 사용하면 나머지 부분은 모두 무시됩니다.

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. 동일한 지시문을 여러 번 추가할 수 있지만 한 번만 작동합니다.

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. // @ts-ignore-disable 는 단독으로 사용할 수 있으며 아무 일도 일어나지 않습니다.

2. @ts-expect-error 는 무시된 영역에서 작동하지 않습니다.

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. 지역 레이블이 없으며 주석일 뿐입니다.

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

완벽한 세상에서는 유형 안전성을 무시할 필요가 없겠죠? :땀_미소:
예를 들어, 내가 원하는 대로 입력하거나 입력하지 않은 가끔 SO 답변과 같은 환상적인 작업을 복사할 때 필요합니다. 대부분 내 설정을 따르는 내 유형 안전 코드에 있습니다. 나는 매우 엄격한 설정을 사용하고 종종 그 때문에 함수나 일부 논리를 다시 작성해야 합니다. 그 코드 블록을 계속 무시하고 싶기 때문이 아닙니다. 그것은 말이 되지 않습니다.

코드 블록을 무시하는 것은 편리하며, 블록의 모든 라인을 @ts-ignore 할 수 있다는 사실을 감안할 때 완벽하게 합리적으로 보입니다.

I'll just ignore this because it's easier 로 가는 사람들에게 이것이 미칠 수 있는 영향을 이해합니다. 내가 보기에 drink poison to satisfy their thirst 를 무시하는 블록 범위를 사용할 수 있는 사람은 이미 @ts-ignore 로 독 한 방울을 마시고 있습니다.

이제 .ts @ts-nocheck 를 수행할 수 있으므로 $ .ts @ts-check 를 허용하여 유형 검사기를 켜거나 끌 수 있습니다.

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

이것은 "코드 블록"이 무엇인지 정의할 필요가 없습니다. -에서 모든 행까지 유형 검사를 시작 및 중지할 수 있습니다.

업데이트 내가 잘못했습니다. 수정 사항은 https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095를 참조하세요.

styled-components 를 사용하는 앱을 TypeScript로 마이그레이션하려고 할 때 (어떤 이유로) 템플릿 문자열 위에 @ts-ignore 를 사용할 수 없는 문제가 발생했습니다. ignore-block으로 해결할 수 있습니다.

무시하려고 했던 TS 오류의 예:

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

추가 참고 사항: TS 프로젝트에서 캐스트할 수 없으며 모든 유형을 허용하지 않습니다. 그렇다면 추천은?

@weswigham 미학의 맥락에서 흐름 상태 및 생산성에 대한 귀하의 생각은 무엇입니까? 당신은 피눈물에 대해 동정심이 없는 것 같습니다. 그러나 생산성, 코드 이식 및 내가 설명한 프로세스에 대한 개념이 있습니까? 내 의견을 고려한 후에도 더 생산적이라는 맥락에서 여전히 어떤 이점도 _전혀__ 느끼지 못합니까? 또한 블록 범위를 무시해야 하는 실제 상황에 대해서도 설명했습니다. 또한 이 기능이 ESLint 및 우리가 기대하는 기능과 어떻게 비교되지 않습니까?

중단이 적을수록 생산성이 증가하고 효율성이 향상된다는 것이 과학적으로 입증되었습니다 . 블록 범위 무시는 코드를 이식할 때 더 적은 중단을 가능하게 합니다. TS 팀은 "기본적으로 TypeScript에서 억제 기능을 사용해서는 안 된다고 생각합니다."라는 사실을 깨닫지 못합니까? 는 살아 있고 숨쉬는 TypeScript에 기반한 의견이며 현실 세계에서는 사람들이 더 많은 유형 안전성 및 기타 린트 규칙을 사용하여 제대로 작성된 코드를 다른 코드베이스로 이식해야 한다는 의견입니다. 이러한 상황에서는 파일이나 줄을 무시할 수 있지만 방금 가져온 코드 블록은 무시할 수 없다는 것은 의미가 없습니다.

내가 보기엔 현실을 무시하고 유토피아를 향해 가고 있는 것 같다. @sandersn 당신은 내 요점을 다루지 않았고 사건의 새로운 토론에 대해 이전 답변을 보류했습니다. 또한 팀에서 달리 결정하지 않는 한 구현해서는 안 된다고 명시합니다. 이 경우 문제를 종료하시겠습니까?

팀은 결정을 내리거나 명확하게 원하는 기능을 구현해야 합니다.

문제를 림보 상태로 두는 것은 의미가 없습니다.

당신이 필요로 하는 완결성을 제공할 수 없어 유감이지만 현실은 "아마도 나중에"라는 대답이 당신이 함께 살아가는 법을 배워야 한다는 것입니다. 주어진 기능은 내일 제품에 서두를 수 없으며, 우리의 설계 매개변수에 속하는 기능에 대해 인체 공학적인 방식으로 제품에 추가할 수 있는 능력을 놓고 경쟁하는 수천 개의 제안이 현재 열려 있습니다. 유용하고 안정적이며 진보적입니다.

우리는 현재 피드백, 현재 솔루션 및 해결 방법의 상태, 이러한 시나리오의 우세, 도구 및 기타 수백 가지 요소를 기반으로 우선 순위를 지정합니다. 현재 우선순위가 높지 않은 것이 나중에 우선순위가 높을 수 있습니다. 그것이 "아마도 나중에"의 성격이며 이것이 이 제안이 어디에 있는지를 정확하게 표현한다고 생각합니다. 현재 여기에서 결정은 피드백을 계속 모니터링하고 우리가 다음에 추가할 수 있는 다른 기능보다 더 높은 우선 순위로 이 기능을 필요로 할 수 있는 사람들이 무엇을 겪고 있는지 이해하는 것입니다.

여기의 어조는 솔직히 적대적인 경향이 있고 개인적으로 말하고 최후 통첩을 향해 밀어붙이는 것은 이것이 대안에 비해 복잡성을 능가하는 가치를 추가하는 부분을 이해하는 데 도움이 되는 건설적인 대화에 도움이 되지 않습니다.

최후통첩을 해서 죄송합니다. 나는 PR을 향한 활동을 보고 꽤 짜증이 났지만 문제에 대해서는 아무 것도 없었습니다. 내 이전 의견이 건설적인 방식으로 기여하지 않는다는 데 동의합니다.

이 문제가 기다려야 할 수도 있다는 점을 인정할 수 있습니다. 몇 가지 피드백을 제공하고 해결에 더 가까워지기 위해 필요한 다른 피드백이 무엇인지 물었지만 응답을 받지 못했습니다. 그것이 아무리 성가시더라도 내 다소 건설적이지 않은 의견은 내가 팀으로부터 _일부__ 응답을 받기 위해 해야 했던 일인 것 같습니다.

몇 년이 지난 700건이 넘는 긍정적인 반응이 있는 문제에 대한 실제 진행은 아직 이루어지지 않은 것 같습니다. 더 빨라져야 한다고는 생각하지 않지만, 멤버들의 개인적인 의견 이 있기 때문에 팀이 이 기능을 탐색하는 데 관심이 없는 것 같습니다. 나는 이 모든 것을 완전히 이해합니다. 하지만 여기에서 내가 하려는 것은 그게 아닙니다. 대화를 좀 하고 싶은데 무시당합니다.

내 피드백이 고려되고 그 성격을 감안할 때 응답되었음을 알고 싶습니다. 짧은 시간에 활성화된 활성 PR에서 볼 수 있듯이 기능 집합에 큰 혼란이 있는 것은 아닙니다. 모든 준비가 완료되었으며 사람들은 차단 무시 기능으로 이 문제를 해결하는 데 계속 긍정적으로 반응하고 있습니다. 저는 커뮤니티가 이 기능을 사용하기 위해 무엇을 해야 하는지 물었습니다. 나는 팀에서 제기된 몇 가지 요점에 강력하게 동의하지 않으며 이에 대해 반대하여 PR을 했고 '마음이 바뀌지 않는 한' 아무것도 바뀌지 않을 것이라는 의견이 제공되었습니다.

거기에서 내 좌절감이 드러납니다. 나와 다른 사람들의 피드백을 완전히 무시하고 팀 구성원의 결정에 변경 사항이 없기 때문에 준비된 기능을 무시하고 싶습니다.

팀의 누군가가 _합의에 따라_ 달리 결정하지 않는 한 이 문제에 대한 변경 사항이 표시되지 않는 것 같습니다. 커뮤니티에서 더 많은 피드백이 필요하지 않습니까? 그래서 제가 최후통첩을 잘못했습니다.

나는 @weswigham 의 요점에 대해 몇 가지 주장을 하고 몇 가지 예를 제공했으며 솔직히 여전히 그것에 대한 어떤 종류의 응답을 기다리고 있습니다. 도움이 되는 것처럼 보이는 유일한 것은 눈에 띄게 화를 내고 건설적이지 않다는 것뿐이었습니다.

여기에서 어떻게 이동합니까? 팀은 어떤 피드백을 원할까요? "우리는 현재 피드백, 현재 솔루션 및 해결 방법의 상태, 이러한 시나리오의 우세함, 도구 및 기타 수백 가지 요소를 기반으로 우선 순위를 지정합니다." 뒤에 숨겨진 개인적인 문제처럼 보입니다. 여러 사람들이 팀에서 _전혀_ 응답하지 않고 피드백을 제공하려고 시도했기 때문입니다.

나는 우리가 주제에서 사람들의 의견을 빼면 이것이 높은 우선순위가 아닐 수도 있다는 것을 이해한다는 것을 반복하고 싶습니다. 동시에 이 기능을 구현할 준비가 되었으며 주장이 제기되었습니다. 지금 필요한 것은 팀이 결정/대응을 하고(아무것도 구현하지 않아도 됨) 공개하는 것입니다. 그것이 필요한 것이 아니라면 TypeScript의 _모든_ 기능이나 문제, 특히 이 문제에 대한 우선순위를 높이는 데 무엇이 도움이 되는지, 또는 어떻게 도움이 되는지 알려주십시오.

여러 줄( @ts-ignore-start+@ts-ignore-end ) 또는 인라인(예 /* @ts-ignore */ ) @ts-ignore 의 또 다른 사용 사례입니다.
환경:

• "noUnusedParameters": true
• ESLint require-jsdoc 규칙을 활성화했습니다.
• 다음과 유사한 코드(간단한 예):

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * <strong i="16">@param</strong> data
     *      Data that should be prepared.
     * <strong i="17">@param</strong> settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

설명된 상황에 대해 TypeScript는 'settings' is declared but its value is never read.(6133) 경고를 표시합니다.
문서 주석 끝에 @ts-ignore 를 추가하여 경고를 표시하지 않을 수 있습니다.

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

그러나 그 후에 ESLint는 Missing JSDoc comment 에 대해 불평할 것입니다.
따라서 솔루션은 다음과 같습니다.

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

어색하고 추한 것.

@RyanCavanaugh @weswigham @sandersn

이것이 커뮤니티에서 TypeScript 팀과 더 논의하기를 원하는 사항임을 월간 알림입니다. 많은 지원이 있으며 현재 누락된 것은 팀의 응답입니다. 많은 생각을 하고 있으며 TypeScript를 발전시키는 것이 쉬운 일이 아니라는 것을 알게 되었습니다. 시간이 걸립니다. 이 제안을 더 발전시키고 더 직접적인 조치를 취할 수 있는 방법에 대한 응답이 없기 때문에 정기적으로 이와 같은 알림을 보내도록 하겠습니다. 나는 결정이 내려질 때까지 포기하지 않고, 댓글이 영향을 미치는 것 같습니다(대부분 !@#일 때).

몇 년이 지난 후 원래 이 기능이 없다는 사실에 놀랐지만 개인적으로 조금 다시 생각했습니다... @ts-ignore 의 엄청난 무리가 있을 때 이미 뭔가 문제가 있다는 것을 알 수 있습니다. 코드를 사용하고 유형을 개선하는 데 시간을 할애하십시오. 우리 모두는 때때로 꽤 게으르고 전반적으로 속도를 원하지만 현재는 여러 @ts-ignore 를 많은 코드 묶음에 복사하여 붙여넣는 것보다 몇 가지 적절한 유형을 파악하는 것이 더 쉬운 경우가 많습니다. 이러한 불편함의 균형이 깨지면 우리 중 많은 사람들이 @ts-ignore-enable을 편리하게 남용하게 되어 여기저기서 모든 작은 오픈 소스 프로젝트의 전반적인 품질이 저하될 수 있습니다.

Btw, 우리는 이 문제에 대해 많은 👍 반응이 있음을 알지만 - 훨씬 더 많은 사람들이 침묵하는 동안 이 기능 없이 완전히 괜찮게 느낄 수 있기 때문에 편향될 수 있습니다. 왜냐하면 그들이 여기에 없기 때문입니다.

@JerryGreen 내 이전 의견을 참조하여 똑같은 말을 했습니다. 또한 사람들은 이미 무시 기능으로 이 작업을 수행하고 있습니다. _none_ 이 있어야 한다고 주장하면서 약간의 독을 구현할 이유가 없습니다.

@ts-ignore 기능을 제거하거나 완전한 기능으로 만드십시오. 이를 수행하기 위한 많은 주장이 있으며, 잘못된 코드를 작성하는 사람들은 블록 무시 기능만큼 나쁜 @ts-ignore 를 계속 사용합니다. 블록 무시가 시각적으로 덜 방해가 된다는 점을 제외하고는 완전히 동일합니다.

커뮤니티는 여전히 TypeScript 팀의 응답이 필요합니다.

@JerryGreen 내 이전 의견을 참조하여 똑같은 말을 했습니다. 또한 사람들은 이미 무시 기능으로 이 작업을 수행하고 있습니다. _none_ 이 있어야 한다고 주장하면서 약간의 독을 구현할 이유가 없습니다.

@ts-ignore 기능을 제거하거나 완전한 기능으로 만드십시오. 이를 수행하기 위한 많은 주장이 있으며, 잘못된 코드를 작성하는 사람들은 블록 무시 기능만큼 나쁜 @ts-ignore 를 계속 사용합니다. 블록 무시가 시각적으로 덜 방해가 된다는 점을 제외하고는 완전히 동일합니다.

커뮤니티는 여전히 TypeScript 팀의 응답이 필요합니다.

일부 특수 시나리오는 여전히 @ TS 무시를 사용해야 합니다. 예를 들어 CDN 가져오기는 node_에 의존하지 않습니다. 모듈 시나리오에 TS 파일이 없습니다.

@L-Hknu 명확히 해 주셔서 감사합니다. 사람들은 어쨌든 ESLint와 함께 무시를 사용하기 때문에 그것을 사용합니다.

무시 기능은 기능에 필요한 경우 이외의 컨텍스트에서는 허용되지 않습니다. 코드를 무시하는 데 사용해도 괜찮다는 뜻입니다.

대부분의 시간에 같은 방식으로 사용되기 때문에 블록 무시가 없어야 하는 이유를 여전히 알 수 없습니다.

일부 오픈 소스 코드의 경우 유형으로 변환하는 것을 포기했습니다. 나는 그것이 필요하지 않지만 많은 사람들이 타이핑으로 문 안으로 발을 들여놓을 것이라고 생각합니다. 또한 블록 주석과 모든 행 주석의 미학이 얼마나 다른지를 고려할 때 많은 사람들이 더 효율적으로 전환에 기여할 가능성이 높습니다.

이 구현의 가장 큰 사용 사례는 typescript 지원이 없는 타사 패키지에 대한 것이며 일부 사용은 무시해야 합니다.

@L-Hknu 명확히 해 주셔서 감사합니다. 사람들은 어쨌든 ESLint와 함께 무시를 사용하기 때문에 그것을 사용합니다.

무시 기능은 기능에 필요한 경우 이외의 컨텍스트에서는 허용되지 않습니다. 코드를 무시하는 데 사용해도 괜찮다는 뜻입니다.

대부분의 시간에 같은 방식으로 사용되기 때문에 블록 무시가 없어야 하는 이유를 여전히 알 수 없습니다.

일부 오픈 소스 코드의 경우 유형으로 변환하는 것을 포기했습니다. 나는 그것이 필요하지 않지만 많은 사람들이 타이핑으로 문 안으로 발을 들여놓을 것이라고 생각합니다. 또한 블록 주석과 모든 행 주석의 미학이 얼마나 다른지를 고려할 때 많은 사람들이 더 효율적으로 전환에 기여할 가능성이 높습니다.

다 된듯
#40267