Typescript: TS4023 : 내 보낸 변수 'X'에 외부 모듈 'a / file / path'의 이름 'Y'가 있거나 사용 중이지만 이름을 지정할 수 없습니다.

오-이것이이 질문을하기에 적합한 장소가 아니라면. 알려 주시면 다른 매체에 게시 해 드리겠습니다.

FWIW는 일반적으로 Stack Overflow에서 더 빠른 답변을 얻을 수 있지만 여기서는 필드에 잘 표현 된 질문을합니다.

여기서 문제는 --declaration 플래그를 사용하고 있지만 컴파일러가 작업을 수행 할 수있는 방법을 제공하지 않았다는 것입니다.

ModuleA.d.ts 를 내보내려고 할 때 컴파일러는 모듈의 모양을 나타내는 객체 유형 리터럴 (예 : { moduleB: { classA: *mumble?* } } )을 작성해야합니다. 그러나 classA 직접 참조하는 이름이 범위에 없으므로 "이름을 지정할 수 없음"유형이며 오류가 있습니다.

import of ClassA 를 ModuleA.ts 에 추가하면 오류가 사라집니다.

안녕 Ryan-조언 RE 스택 오버플로와 조언에 감사드립니다- ModuleA 가져 오기를 추가하면 예상대로 컴파일이 이루어집니다.

여기에 약간의 컨텍스트가 있습니다. 제 목표는 실제로 외부 모듈에 대한 선언을 생성하는 것입니다. (아직 제대로 작동하지 않는다고 생각하는 부분이 있습니까? # 5039?)이 가져 오기가 완전히 필요할 수 있지만 ModuleA 에서 moduleB가 이미 내보내는 기호를 가져와야하는 것이 조금 이상합니다. 결과적으로 ModuleB 의 개체 내보내기에 추가 할 때마다 가져 오기를 ModuleA 직접 추가해야합니다.

import {moduleB} from './moduleB';
import {ClassA} from './ClassA';

또는 ModuleB (두 곳 모두에서 ClassA 에 대한 경로 지정을 줄이기 위해) :

import {moduleB, ClassA} from './moduleB';

나는 TS 컴파일러에 대해 거의 알지 못합니다. 그래서 제가 말하는 것은 완전히 비현실적 일 수 있지만 처음에는 컴파일러가 ModuleB 가 N 개의 기호가있는 객체를 내보내고 있다고 추론 할 수 있다고 생각 했으므로 ModuleA 해당 기호가 필요합니까? ModuleB 대한 가져 오기 정보가 이미 있습니다. ModuleA 사용할 수 있습니까? 또는 ClassA 대한 가져 오기가 완전히 ModuleB 내부에 있으므로 불가능하므로 ClassA 대한 유형을 추론 할 수있는 방법이 없습니다 ModuleA ?

시간을내어 답변 해 주셔서 다시 한 번 감사드립니다. 나는 지금 내 문제를 분류 했으므로 위의 내용은 주로 호기심입니다. 서두르지 않습니다.

당신이 무슨 말을하는지 정확히 모르겠습니다. 이 제안에서 ModuleA.d.ts 은 (는) 어떻게 표시되어야합니까?

컴파일러는 선언을 내보낼 때 사용자 코드에 존재하지 않는 종속성 (즉, import 문)을 추가하지 않습니다. 표시되는 오류는 컴파일러가 내 보낸 선언에 대한 유형 주석을 작성하려고하지만 할 수 없음을 의미합니다. 이것은 두 가지 이유 중 하나를 가질 수 있습니다. 이름에 액세스 할 수 없습니다. 즉 현재 모듈에서 가져 오지 않았거나 원래 선언을 숨기는 선언이 있습니다.

두 경우 모두 해결 방법은 명시 적 유형 주석을 추가하는 것입니다. 유형 주석을 추가하면 출력에서 ​​그대로 내보내집니다. 다른 옵션은 이름에 액세스 할 수 있는지 확인하는 것입니다. 즉, 모듈에 대한 가져 오기가 있고 모듈을 가져 오는 사용자에게 이것이 의미하는 바를 이해합니다.

@mhegazy가 말했습니다.

컴파일러는 선언을 내보낼 때 사용자 코드에 존재하지 않는 종속성 (즉, import 문)을 추가하지 않습니다.

문제는 코드에 항상 import 문이 필요하지는 않으며 (분명히 --declarations 없이 작동하기 때문에), 그것들을 포함하면 시끄러워서 tslint 같은 것들이 "미사용 수입". 컴파일러가 내 보낸 자바 스크립트에 종속성을 추가하는 것을 원하지 않는 이유를 알 수 있지만 선언을 내보냄으로써 종속성을 추가하는 데 어떤 문제가 있습니까?

이 제안을 추적하려면 언제든지 문제를 기록하십시오. 합리적인 것은 imports는 종속성의 선언이며 컴파일러는 사용자가 지시하지 않는 한이를 생성하지 않아야합니다.

이것은 더 깊은 결과를 가져올 수 있습니다.

moduleA -> moduleB -> moduleC -> moduleD .

moduleB 은이 문제를 해결하기 위해 import { ABC } from 'moduleA' 를 수행해야하는 것입니다.

moduleC moduleB 를 사용하고 서명을 내보낼 때 moduleB ABC 에서 moduleA 하지만 이번에는 ABC 필요하기 때문에 다시 컴파일에 실패합니다 moduleB 보내지 않았습니다.

이는 다음 중 하나를 의미합니다.

1. moduleC 요구의 하드 의존해야하기 moduleA 가져올 ABC
2. moduleB 는 가져 오기뿐만 아니라 ABC 다시 내보내고 moduleC 가져와야합니다.

moduleD 가 비슷한 일을한다면 기본적으로 전체 종속성 체인을 알아야합니다.

나는 typings 하고 있고 나를 막는 문제가 있기 때문에 이것이 사실임을 증명하기 위해 이것을 테스트 할 수 없었습니다 : https://github.com/typings/typings/issues/625 ~~

편집 : 나는 그것을 재현 할 수 있고 실제로 내 moduleD 는 가져 오기를 위해 moduleA 를 참조해야합니다.
내 예에서 :

• moduleA => redux
• moduleB => redux-thunk
• moduleC => redux-thunk 위에있는 사용자 지정 코드
• moduleD => 일부 도서관
• ABC => redux Dispatch 인터페이스

@unional에서 설명한 것과 동일한 문제가

이 문제를 다시여십시오. @unional 에 의해 설명 된 문제는 매우 현실적이므로 다시 내보내는 원래 모듈과 동일한 유형을 사용하면서 라이브러리 위에 중간 / 도우미 라이브러리를 추가하기가 매우 어렵습니다.

https://github.com/Microsoft/TypeScript/issues/9944 트랙을 발행하여 선언 방출 단계에서 가져 오기를 추가합니다.

감사!

가져 오기를 추가 할 때의 문제점은 noUnusedLocals 하면 컴파일러가 사용되지 않는 유형에 대해 불평한다는 것입니다. 명시 적 유형 주석을 추가 할 수 있지만 추론을 얻지 못합니다. 예:

class Whatever {
  fetch(uri: string): Promise<void> { }
  ensureFetched = MemoizedFunction<(uri: string) => Promise<void>> = memoize((uri: string) => this.fetch(uri))
}

ensureFetched 대한 유형 주석을 생략하고 싶습니다.

https://github.com/styled-components/styled-components/issues/973

이에 대한 해결 방법을 찾았습니다.
tsconfig에서 : include: [ ..., "node_modules/@your_scope/your_library" ]
행운을 빕니다.

@ salim7 이렇게하면 컴파일 시간이 느려지고 (이미 컴파일 된 라이브러리를 다시 컴파일하기 때문에) 대상 라이브러리와 함께 엄격 성 설정의 최소 공통 분모를 사용해야합니다.

@mhegazy 문제는 다음 시나리오에서 재현되었습니다.

import * as Foo from "./Foo";

export class Bar {
    baz = new Foo.Baz(); // Compiler forgot "Foo." prefix in the type, and throws this error, because "Baz" without perfix is not imported.
    getBaz() { // All the same
       return new Foo.Baz();
    }
}

솔루션은 명시 적 유형을 지정하는 것입니다.

import * as Foo from "./Foo";

export class Bar {
    baz: Foo.Baz = new Foo.Baz(); // ok
    getBaz(): Foo.Baz { // ok
       return new Foo.Baz();
    }
}

위의 샘플을 사용하여 재현 할 수 없습니다. 새 버그를 신고하고 문제를 재현 할 수 있도록 더 많은 컨텍스트를 제공하세요.

@PFight 감사합니다! 그것은 나를위한 것이었다!

다음을 사용할 때 방금이 문제에 직면했습니다.

export { IMyInterface } from './file'
````

The solution was to do this:
```ts
import { IMyInterface } from './file'
export { IMyInterface }

그러나 이것은 정말로 필요한 것은 아닙니다.

noUnusedLocals 를 다루는 방법을 알아 낸 사람이 있습니까?

@yordis // @ts-ignore

@ pelotom 네 이것은 완전히 내 잘못입니다.

나는 한 가지를 생각하고 다른 것을 썼습니다.

Typescript가 noUnusedLocals 와 선언 사이의 문제를 해결 했습니까?

저에게 완전히 고통스러워지는 현재의 해결 방법은

import {SomeInterface} from "./SomeFile";

const _dummySomeInterface : undefined|SomeInterface = undefined;
_dummySomeInterface;

//Code that implicitly uses SomeInterface

noUnusedLocals 를 피하고 가능한 경우 제네릭 인터페이스에 대한 유형 추론도 허용합니다.