Tslint: '유추할 수 없는 유형' 및 'typedef' 규칙이 충돌합니다.

잘 잡았습니다. 미리 알려주셔서 감사합니다. no-inferrable-types 규칙이 typedef 규칙과 충돌할 수 있다는 생각 없이 no-inferrable-types 규칙을 추가했습니다. 지금은 둘 중 하나를 끄거나 typedef 규칙의 일부 옵션만 사용하는 것이 좋습니다.

장기적으로 no-inferrable-types 를 typedef 규칙에 통합하거나 최소한 TSLint가 두 규칙을 모두 사용하는 것과 같이 충돌하는 구성을 감지하도록 할 것입니다.

나는 같은 문제에 직면 해있다.
지금은 추론할 수 없는 유형을 해제했습니다.

예, 여기에서도 마찬가지입니다. 두 규칙이 공존할 수 있는 기능을 갖고 싶습니다.
변수의 유형을 유추할 수 있는 경우 typedef 규칙이 시작되는 것을 원하지 않습니다.
즉, "추론할 수 없는 유형"이 "typedef"보다 우선해야 합니다.

+1

let id: number = 0;
for (let job: string of NAMES_PROFFESSIONS) {
     /** some code */
     id++;
}

(no-inferrable-types) RHS 식으로 유추된 LHS 유형(숫자), 유형 주석 제거

+1

"추론 가능한" 유형에 대한 정의에 생성자 할당이 포함되어 있습니까?

// BAD (this hurts my eyes to read)
let labels: Map<string, string> = new Map<string, string>();
// GOOD (type is obvious)
let labels = new Map<string, string>();

하지만 또한...

// BAD (in a diff, it's not obvious what this type is)
let labels = this.buildLabels();
// GOOD
let labels: Map<string, string> = this.buildLabels();

예, 위험합니다. 내 코드를 단순화하고 직접 초기화된 변수에 대한 유형 선언을 사용하지 않으려면 엄격하게 이 작업을 수행할 수 없으며 다음과 같은 결과가 발생합니다.

let x = 2;
let y;
let z: number;

x = 1;
y = 1;
z = 1;
x = 's'; // Type 'string' is not assignable to type 'number'
y = 's'; // It's OK
z = 's'; // Type 'string' is not assignable to type 'number'

초기화된 변수에 대해서만 유형 선언을 건너뛰도록 허용하는 것은 매우 유용한 옵션일 수 있습니다.

... 그리고 @pgonzal 이 말했듯이 원시 유형에만 해당되는 것은 아닙니다!
이것 봐, 끔찍해

const onChange: () => void = () => this.update();

:+1: 이상적으로는 (imo) "유형이 유추 가능한 경우가 아니면 항상 typedef가 필요합니다"라고 말하고 싶습니다. 지금은 불가능하다고 생각합니다.

나는 이것에 부딪혀 내 경우에 도움이되는 ignore-params 플래그를 만들었습니다. 쉽게 유추할 수 있는 경우에도 모든 메서드/함수 매개변수에 대해 typedef를 강제 적용하고 싶습니다.

사용해 보려면 PR: #1190을 참조하세요.

원본 문제가 제출된 지 오래되었습니다. 이 시점에서 권장 옵션은 no-inferrable-types 를 비활성화하고 모든 항목에 유형을 포함하는 것입니까? no-inferrable-types 및 typedef 를 모두 시도하고 활성화하고 결합하는 다른 모든 것은 해킹처럼 보이며 많은 무의미한 경고를 초래합니다. 가까운 시일 내에 더 나은 솔루션을 기대합니다.

@corydeppen 위의 @englercj 제안에 대해 8개의 엄지손가락을 치켜세웁니다. 귀하의 "해킹처럼 보입니다" 댓글에서 "결합"이 무엇을 의미하는지 명확하지 않습니다. " tslint.json 에서 함께 사용"을 의미한다면 그렇습니다. 하지만 typedef 에 대한 optional-inferrable-types 인수를 "결합"하는 것은 훌륭할 것입니다(적어도 우리 중 9명에게는).

이에 대한 업데이트를 받을 수 있습니까?

이것을 처리하는 가장 좋은 방법은 no-inferrable-types 를 더 이상 사용하지 않고 $#$ typedef initialized 옵션 개체를 전달하여 특정 패턴에 따라 유형을 추론할 수 있는 경우 유형 정의의 부족을 무시하는 것입니다. initialized primitives , call signatures 및 개발자로서 우리의 요구를 충족시킬 기타 패턴.

나에게 이것은 더 의미가 있습니다. 왜냐하면 그것이 함수의 유형이 무엇인지 알려주는 것이 없다면 항상 typedef가 있어야 하기 때문입니다. 예를 들어 call signatures 가 아닌 클래스에서 초기화된 properties 가 추론 가능한 유형을 가지기를 원하기 때문에 구성 가능합니다.

누군가가 이 문제를 해결할 수 있다면 좋을 것입니다. 그때까지 우리는 "읽을 수 있는 형식 선언이 충분하지 않음"과 "너무 많은 형식 선언으로 복잡함" 중에서 선택해야 합니다.

이 문제는 2015년 10월 3일부터 공개되었습니다. 그 이후로 저희 팀은 너무 많은 유형 선언으로 인해 어수선한 약 2000개의 TypeScript 소스 파일을 작성했습니다.

typedef 구성을 수락합니다. 따라서 유형이 유추 가능한 경우 유형 정의를 무시하는 또 다른 구성일 수 있습니다.

초기화되지 않는 곳에 입력하면 됩니다.

문제를 어떻게 처리해야 하는지에 대한 명확한 합의가 이루어지지 않아 진전이 없는 것으로 보입니다. 주석 예시: https://github.com/theia-ide/theia/issues/356#issuecomment -319350833

나는 우리 모두가 어떤 해결책이든 있는 그대로 두는 것보다 낫다는 데 동의한다고 생각합니다. 이 문제와 관련하여 현상 유지에 대한 변경 사항이 좋다고 생각하시면 이 댓글을 👍 부탁합니다. 이 문제를 해결하기 위해 PR을 작성할 만큼 지식이 있다면 우리 모두를 도와주세요 ❤️ .

다음과 같은 경우 PR을 수락합니다.

• typedef 에 옵션을 추가하여 no-inferrable-types 에서 유형을 제공하지 말라고 하는 경우를 무시할 수 있습니다.

typedef는 구성을 허용합니다. 따라서 유형이 유추 가능한 경우 유형 정의를 무시하기 위한 또 다른 구성일 수 있습니다. 즉, '초기화되지 않은 위치에 입력하십시오.'

typedef 규칙은 코드베이스에 명시적 유형 정의를 갖고 싶어하는 사람들을 위한 것입니다. 위의 동작이 "초기화되지 않은 모든 위치에 입력"하도록 하려면 typedef 를 비활성화하고 TypeScript 컴파일러 옵션으로 noImplictAny 를 활성화하는 것이 좋습니다.

다음 스니펫과 같이 초기화된 일부 항목에 어쨌든 typedef가 필요한 까다로운 경우도 있습니다.

interface Literal {
    field: "value"
}

const literal0 = {
    field: "value",
};
const literal1: Literal = {
    field: "value",
};

const func = (obj: Literal) => { };
func(literal0);  // Error! Type 'string' is not assignable to type '"value"'.
func(literal1);

또한 이 문제를 해결하는 동안 no-unnecessary-type-annotation (https://github.com/ajafff/tslint-consistent-codestyle/blob/)와 같은 훌륭한 타사 규칙이 있을 수 있음을 언급하고 싶었습니다. 예를 들어 master/docs/no-unnecessary-type-annotation.md). 원하는 동작을 제공하는 다른 타사 규칙을 알고 있는 사람이 있는 경우 여기에 게시해 주시면 공식적으로 권장하거나 타당한 경우 핵심에 채택할 수 있습니다.

@JKillian 추천 감사합니다. 실제로 제가 원했던 것 같아요. any 유형을 피하는 것에 대한 아주 좋은 게시물이 있습니다. "naked any"를 사용하지 말고 대신 "any interface"를 만드십시오.

에 대한:

interface Literal {
    field: "value"
}

const literal0 = {
    field: "value",
};
const literal1: Literal = {
    field: "value",
};

const func = (obj: Literal) => { };
func(literal0);  // Error! Type 'string' is not assignable to type '"value"'.
func(literal1);

나는 이것이 어떻게 바람직하지 않은 행동이나 까다로운 경우인지 알 수 없습니다. obj 값이 value 인 $#$ field $#$ 속성이 있는지 확인하고 제약 조건처럼 보이는 속성으로 literal0 를 초기화하는 경우에도 , 다른 문자열로 수정할 수 있습니다.

좋은 사용 사례는 아니지만 대부분의 경우 리터럴을 사용하는 경우 기본이 아닌 해당 리터럴을 원할 것입니다.

다음 구성이 있습니다.
json "no-inferrable-types": true, "typedef": [true, "call-signature", "parameter"],
그리고 이 코드:
javascript private static readonly DEVICE_UID: string = 'device_uid'; private static readonly DEVICE_PLATFORM: string = 'browser'; private static readonly AGENT_DEFAULT_ICON = 'http://localhost:3000/icon.png';

두 개의 첫 번째 선언에서 오류가 발생하지 않는 이유는 무엇입니까?

@sandrocsimas 흥미롭지 만 주제가 아닌 것 같습니다. AFAICT 해당 문제는 이 문제와 관련이 없습니다. 다른 문제를 시작하는 것이 좋습니다(fwiw!).

@estaub 네, 그렇게 하겠습니다. typedef 규칙이 없어도 동일한 동작이 발생합니다.

@sandrocsimas 는 읽기 전용 속성이고 이러한 Typescript는 해당 유형을 리터럴로 유추하기 때문입니다. 그것을 문자열로 입력하면 문자열이 있어야 함을 의미합니다. 반드시 해당 리터럴 값을 가질 필요는 없으며 값이 정적으로 변경되어서는 안 됩니다.

'typedef-except-inferrable' 규칙이 있으면 좋을 것입니다.

@JKillian 이 말했듯이 @FiretronP75 는 TSC의 noImplicitAny 옵션일 뿐입니다.

@michaeljota 감사합니다. 컴파일러의 noImplicitAny 옵션이 추론할 수 있는 예외를 제공한다는 것을 몰랐습니다. 그래도 컴파일을 중단하는 대신 경고를 만드는 옵션과 tslint 주석 플래그를 갖는 옵션을 위해 tslint에 있으면 좋을 것입니다.

이것이 원하는 이유를 알지만 no-unused-variables 를 예로 들면 TSC에서 다루는 사용 사례가 TSLint 팀에서 지원되지 않을 것이라고 생각합니다. 나는 그것이 _컴파일러 오류_와 같은 _린터 오류_가 아니라는 것을 알고 있지만 결국 둘 다 더 나은 코드를 작성하는 것에 관한 것입니다. TSC 오류가 있는 경우에도 코드를 컴파일하고 실행할 수 있는 Webpack 또는 Parcel과 같은 솔루션이 있는 요즘에는 이것이 실제 문제로 보이지 않습니다.

최신 버전에서는 해결되었나요?

나는 이것이 로드맵에 아직 없다고 생각한다. TSC에서 noImplicitAny 사용을 고려해야 합니다.

☠️ TSLint의 시간이 왔습니다! ☠️

TSLint는 #4534에 따른 대부분의 기능 요청을 더 이상 수락하지 않습니다. ESLint 로 TypeScript 코드를 린트하는 새롭고 빛나는 방법은 typescript-eslint.io 를 참조하세요. ✨

여러분과 함께 즐거운 오픈소싱이었습니다!

🤖 삐삐! 👉 TSLint는 더 이상 사용되지 않습니다 👈 _(#4534)_ 그리고 typescript-eslint 로 전환 해야 합니다! 🤖

🔒 이 이슈는 더 이상의 불필요한 토론을 방지하기 위해 잠그고 있습니다. 감사합니다! 👋