[위 문제 설명 에서 package.json의 typescript.main으로 이동]

:+1:
http://nodejs.org/api/modules.html#modules_folders_as_modules 는 Node.js의 매우 인기 있는 규칙이라고 생각합니다.

다른 예.

./테스트/인덱스.ts

export function hello() { return "Hello, world"; }

./메인.ts

import test = require("./test/");
console.log(test.hello()); // print "Hello, world"

[위 문제 설명 에서 package.json의 typescript.definition으로 이동]

한 가지 해결책은 더 나은 도구로 해결하는 것입니다. 예를 들어 import foo = require('foo') 는 로컬 node_module+package.json(foo는 ts 프로젝트임) 또는 DT 정의(foo는 라이브러리 작성자가 ts def를 유지하기를 원하지 않는 js 프로젝트임)를 찾는 힌트를 제공합니다. .

참고로; 실제로 TSD에서 이와 유사한 것을 테스트하고 있습니다. npm(또는 bower) 패키지에 번들로 제공되는 정의를 노출하고 연결하는 방법입니다.

0.6용 내 dev 버전에 있으며 typescript 요소를 package.json(또는 bower.json)에 추가하고 하위 요소 definition 와 함께 작동합니다. source 도 있을 것입니다.

{
    ...
    "main": "./index.js",
    "typescript": {
        "definition": "./foo.d.ts"
    }
    ...
},

그런 다음 현재 tsd link 인 TSD에서 명령을 실행할 수 있으며 node_modules(또는 bower 또는 기타)의 모든 package.json 파일을 스캔하고 정의된 경우 해당 속성을 찾고 중앙 tsd.d.ts 에 대한 참조를 추가합니다. 프로젝트에

예: 여기 에서 정의하고 여기 에서 사용

@Bartvds 꽤 멋지네요. npm 패키지에 .d.ts를 포함하는 첫 번째 단계가 될 수 있습니다. "typescript"에 "definition"이 있는 package.json 구조가 마음에 듭니다. 훨씬 더 체계적입니다.

TypeScript 컴파일러 자체가 자동으로 읽을 수 있다면 매우 멋질 것입니다.

토론을 위해 이것을 태그 지정 -- 여기에서 다양한 시나리오를 이해하기 위해 더 똑똑한 외부 모듈 해결에 대해 이야기해야 합니다. 이것은 이전에 제기되었으며 1.0에서 몇 가지 조정을 했습니다.

또한 #207에 대해 논의하십시오 - '색인' 아래에서 살펴보기

:+1:

선언 생성을 사용하는 경우 @chanon tsMain 는 필요하지 않습니다.

네, 이 문제는 브라우저에서도 매우 중요합니다. 많은 프로젝트에서 browserify/packify를 사용하므로 노드 호환 디렉토리 레이아웃이 사용됩니다.

:+1:

이 영역에서 이미 codeplex repo에 몇 가지 작업이 있었습니다. 하나는 leebyron에 의해, 다른 하나는 kayahr 에 의해 풀 리퀘스트되었습니다 .

그 중 하나를 새 저장소에 이식하려고 했으나 관련 코드가 많이 재배열된 것 같습니다.

이것을 TypeScript 컴파일러에 추가하는 방법에 대한 제안을 작성했습니다. 여기에는 typings 디렉토리를 찾는 것도 포함됩니다. 이는 자체 typescript 정의를 유지하지 않는 자바스크립트 모듈로 작업할 때 중요하기 때문입니다. 불행히도 tsd 를 사용하여 이 모든 작업을 투명하게 하려면 /// <reference d 파일이 주변 외부 선언이어야 하므로 약간의 작업이 필요합니다. 이것을 브랜치에서 구현하고 이를 사용하는 몇 가지 예제 모듈을 제공하는 방법을 살펴보겠습니다.

합리적으로 보입니다. 충돌하는 유형 종속성이 있는 모듈을 포함합니까? 내 말은 앱이 A와 B를 가져오고 B도 A에 의존하는 경우입니다. 외부 선언의 복사본이 두 개 있으면 중복 유형 오류에 빠지기 쉽습니다.

그렇지 않습니다. 다른 외부 모듈 이름으로 해석되어야 하므로 다른 모듈에서 동일한 이름의 독립 유형을 선언해야 합니다. 구조적 유형 검사는 다른 모듈이 문제 없이 상호 작용할 수 있도록 해야 합니다.

이것이 해결하려는 현재 tsd 정의의 주요 문제 중 하나입니다. 외부 앰비언트 모듈을 정의하면 이름이 동일하지만 유형이 약간 다른 여러 버전의 라이브러리를 처리할 방법이 없습니다. .

@joewood 또한 A의 다른 버전 간에 문제가 있을 것입니다.

├── [email protected]
└── [email protected]
    └── [email protected]

이름은 같지만 유형이 약간 다른 여러 버전의 라이브러리를 처리할 방법이 없습니다.

동일한 솔루션을 듣고 관심이 있습니다. TypeScript에는 앰비언트 선언에 대한 global 수준 변수 범위가 있습니다.

버전이 일치하더라도 현재 두 개의 서로 다르지만 일치하는 주변 선언 파일에 문제가 있어 중복 기호 오류가 발생합니다. 로컬로 정의된 /// reference 지시문은 어떻게든 단일 파일로 다시 확인해야 합니다. 또는 유형 ID에 경로가 포함되어야 하며 구조적 유형 지정은 버전 불일치 등을 처리합니다.

@joewood 네, 가능한 한 /// reference 를 피하고 올바른 정의를 로드하도록 require 를 변경하여 대부분의 경우 수정되기를 바랍니다. 외부 모듈은 앰비언트 선언 대신 절대 경로로 식별되므로 다른 경로와 다른 버전에서 동일한 이름을 여러 개 로드하는 것이 가능해야 합니다.

네, 이것이 가능하면 /// 참조를 피하고 올바른 정의를 로드하기 위해 require를 변경하여 대부분의 경우 수정되기를 바랍니다.

:+1:

:+1: @Nemo157 과 토론에 참여해주신 모든 분들께 감사드립니다.

package.json 추가 사항을 병합하고 @Nemo157 의 제안에 링크하도록 주요 문제 텍스트를 업데이트했습니다.

:+1:

나는 모듈을 만드는 모든 다양한 방법이 작동한다는 것을 보여주기 위해 예제 모듈 세트를 만드는 것과 함께 내 제안의 초기 구현 을 수행했습니다. 다른 하위 모듈에서 동일한 라이브러리의 다른 버전을 사용하는 것을 포함합니다.

:+1:

index.ts :+1이 있는 모듈로서의 폴더:

:+1:

:+1:

:+1:

:+1:

:+1: :+1: :+1:

:+1: :+1: :+1: :+1:

이것을 우리 레이더에 다시 부딪히기 위해 논평합니다.

@Bartvds 의 제안으로 좋은 성공을 거두었습니다.

그런 다음 현재 tsd 링크인 TSD에서 명령을 실행할 수 있으며 node_modules(또는 bower 또는 기타)의 모든 package.json 파일을 스캔하고 정의된 경우 해당 속성을 찾고 중앙 tsd.d.ts 번들에 대한 참조를 추가합니다. 당신의 프로젝트에서.

package.json typescript 를 지원하는 것을 고려하십시오. 커뮤니티가 그렇게 되었기 때문입니다.

TypeScript가 node.js 커뮤니티에서 널리 사용되려면 tsc가 node_modules 폴더를 인식해야 합니다. 저는 현재 개발 프로젝트(npm-workspace 사용)의 일부인 모듈에 대한 심볼릭 링크를 사용하고 있으며 현재 두 가지 옵션이 있습니다.

• 잘못된 것처럼 보이는 node_modules에서 직접 가져오기: import Foo = require("node_modules/mymodule/Foo");
• 선언 파일을 생성하도록 tsc를 가져온 다음 문자열 모듈 이름을 전환하는 수동으로 유지 관리되는 모듈 선언 파일을 사용하여 함께 연결합니다.

tsc가 import 선언에서 외부 모듈 이름을 확인한 다음 경로 확인 중에 node.js 런타임과 동일한 방식으로 node_modules 를 적용할 수 있습니까? 컴파일러 옵션으로 이를 켜거나 끌 수도 있습니다.

:+1: :+1: :+1:

tsc가 가져오기 선언에서 외부 모듈 이름을 확인한 다음 경로 확인 중에 node.js 런타임과 동일한 방식으로 node_modules를 적용할 수 있습니까?

이것이 _해야 하는_ 방법입니다. 해당 이름을 가진 파일을 찾기 위해 디렉토리 트리를 찾는 현재 방식은 JS 실행 컨텍스트와 유사하지 않습니다.

이것은 잠시 동안 내 목록에 있었습니다. 다음 릴리스에서 이것을 얻으려고 할 것입니다.

우리( Booktrack )는 모든 웹 개발에 TypeScript를 사용하며 node.js 개발자와 비슷한 문제에 직면해 있습니다. 웹 개발자의 목소리가 노드 개발자의 목소리만큼 크지 않기 때문에 목소리를 냅니다.

솔루션(최악에서 우리에게 가장 좋은 순서):

1. node_modules 에 대한 하드 코딩된 조회를 통한 최상위 외부 모듈 이름 확인
2. 최상위 외부 모듈 이름 확인을 제어할 수 없음
3. node_modules 디렉토리에 대한 최상위 외부 모듈 이름의 선택적 확인을 제어하는 ​​컴파일러 플래그
4. 주어진 경로에 대한 최상위 외부 모듈 이름의 선택적 해석을 제어하는 ​​컴파일러 "모듈 검색 경로" 매개변수
5. 모든(최상위 수준이 아닌) 외부 모듈 이름을 해석하는 JS 플러그인을 컴파일러에 제공하기 위한 컴파일러 "모듈 해석기" 매개변수
6. 외부 모듈 이름 확인을 제어할 수 있도록 언어 서비스에 대한 적절한 후크

옵션 1은 끔찍합니다. 저는 옵션 2를 선호합니다.

옵션 5와 6은 requirejs 또는 webpack 플러그인으로 작업할 때 발견되는 것과 같은 import 문을 이국적인 용도로 사용할 수 있습니다. 기본 아이디어: 컴파일러는 모든 외부 모듈 이름 조회(최상위 수준뿐만 아니라)를 제3자(플러그인 또는 콜백)에 위임합니다. 컴파일 중인 모듈에 대한 경로와 외부 모듈 이름이 제공된 대리자는 파일 시스템 경로 또는 지정된 모듈 이름에 대한 유형 정보를 컴파일러에 반환합니다.

옵션 4가 구현되면 기쁘고 옵션 6이 구현되면 기쁩니다. 옵션 4와 옵션 6이 모두 구현되면 달입니다.

모듈 검색 루트에 대한 --basePath는 어떻습니까? 모든 모듈 가져오기는 해당 경로를 기준으로 합니다. 이것은 AMD에만 적용됩니다.

노드 문제가 훨씬 간단하다고 생각합니다. 구현하기만 하면 됩니다. :)

우리는 실제로 오래전에 @Nemo157 에서 구현(및 테스트)을 받았습니다. https://github.com/Microsoft/TypeScript/issues/247#issuecomment -57422329

@mark-buer 및 @mhegazy 에 동의하십시오. 옵션 4는 검색 경로가 간단해야 합니다. 언어 서비스(옵션 6)에서 보다 정교한 솔루션이 장기적으로 필요합니다.

_추가할 가치가 있음_: 일반적인 유형 참조 #1125에 대한 중복 기호 문제로 인해 npm에서 TypeScript 재사용 문제가 해결되지 않습니다. 우리는 정말로 피해야 합니다 ///.tsconfig 파일을 사용하고 #17에서 제안한 대로 패키지를 단일 외부 유형 모듈로 번들링하여 이 문제를 올바르게 수정합니다.

typescript 컴파일러가 node_modules 폴더를 인식하도록 하기 위한 또 다른 투표입니다.

CommonJS 모듈의 경우 typescript는 이상적으로 require.resolve가 수행하는 것과 동일한 파일 이름 확인을 따라야 합니다(이 페이지의 psuedocode에 설명된 대로: http://nodejs.org/api/modules.html#modules_all_together.

이 기능은 typescript 컴파일러를 browserify와 같은 다른 노드 패키저에 통합할 수 있도록 하는 데 중요합니다. @Nemo157 의 패치는 잘 작동하지만 대부분이 최신 버전의 typescript로 이동하고 더 이상 그의 코드와 호환되지 않기 때문에 기존 패키저로 쉽게 테스트할 수 없습니다.

node_modules 디렉토리는 소스에 대해 상대적이어야 합니까?

Atom-TypeScript는 이제 typescript.definition 를 즉시 지원합니다. 세부 정보 : https://github.com/Microsoft/TypeScript/issues/2829

또한 atom-typescript :rose: 다시 #2829를 참조하여 이러한 패키지를 쉽게 만들 수 있습니다.

한정

외부 라이브러리에 의존하지 않는 패키지를 공유하면 _완벽하게_ 작동합니다. 그렇다면 모듈 충돌 해결 알고리즘이 필요합니다.

저는 이 경우에 대한 제안을 받을 수 있지만 제 계획은 다음과 같습니다.

• 우리는 TypeScript에 외부 reference 주석을 제공하지 않는 d.ts 를 읽을 때 몇 가지 똑똑한 일을 합니다(예: 여기에서 node.d.ts https://github.com/TypeStrong/atom-typescript-examples /blob/master/node/node_modules/example-typescript-b/definition/sample-bdts) 대신 Typing에 있는 경우 자체 .d.ts 를 가리킵니다.

2.0에서도 계속 유지될까요? 이것은 Node.js 채택을 위한 일종의 중요한 기능인 것 같습니다. 이는 현재 확실히 Typed 등을 사용하더라도 고통스럽습니다.

이것은 Node.js 채택을 위한 일종의 중요한 기능인 것 같습니다. 이는 현재 확실히 Typed 등을 사용하더라도 고통스럽습니다.

@LPGhatguy https://github.com/Microsoft/TypeScript/issues/2338을 참조하세요. @vladima 가 작업 중이지만 아직 이정표가 할당되지 않았다고 생각합니다 :rose:

@LPGhatguy 우리는 다음 릴리스에서 이것을 얻으려고 노력하고 있습니다. 곧.

@mhegazy 1.6을 의미합니까? 그것은 굉장할 것입니다!

#2338과 관련이 있습니까?

TypeScript 1.6의 경우 예(적어도 이것이 우리가 하려는 것입니다), #2338의 경우 예; #3147 및 #4154를 포함하여 이 주변에 몇 가지 다른 변경 사항과 문제가 있습니다.

그렇다면 이정표로 TypeScript 2.0으로 태그가 지정된 이유는 무엇입니까?

@heycalmdown 덕분에 이정표를 제거했습니다. 우리는 일반적으로 제안에 이정표에 태그를 지정하지 않습니다. 이 문제에 대한 업데이트가 일주일 이내에 이루어지기를 바랍니다. 계속 지켜봐 주세요.

나는 이것을 따르기 위해 ES6 모듈 지원을 요청하면서 차임하고 싶습니다(내 생각에는?)

에 대한 입력

import mylib = require('mylib');
mylib.foo(mylib.bar);

와 동일하게 행동해야 합니다

import { foo, bar } from 'mylib';
foo(bar);

나는 이것을 따르기 위해 ES6 모듈 지원을 요청하면서 차임하고 싶습니다.

@DavidSouther _ 자동으로_ 그렇게 될 것입니다. 둘 사이의 조회는 일관성이 있습니다.

이것은 #4154에 의해 처리됩니다.

야간을 사용하는 경우 내일부터 노드 모듈을 가져오는 것이 "정상적으로 작동"할 것으로 예상해야 합니까?

의문:
파일 이름을 지정하는 것이 일반적인 규칙이라고 생각합니다.
commonJS의 "색인" 및
AMD의 "메인"
짧은 경로를 위해.
맨 위에 있는 질문에서 작성자가 가져옵니다.
/node_modules/concator/index.ts
import concator = require('concator');

저를 용서해 주십시오. 현재 인덱스 해상도도 지원되는지 확인하고 있으며 AMD의 index.ts 또는 main.ts에 대한 해상도가 필요합니까?
나는 또한 @basarat 에 핑을 보내 그것이 https://github.com/TypeStrong/atom-typescript 에서 지원되는지 여부를 알고 있습니다. 왜냐하면 이제 위에서 언급한 index.ts를 요구할 수 없기 때문입니다.

@sebilasse , 오늘 typescript@next 를 사용하는 경우 --module commonjs 와 함께 작동해야 합니다.

import concator = require('concator'); // resolves to node_modules/concator/index.ts

이전 릴리스에서 AMD 해상도가 변경되지 않았습니다.

@DavidSouther 오늘 typescript@next 에 있어야 합니다. 시도해 보고 요금이 어떻게 되는지 알려주세요.

@mhegazy @basarat :+1: 알겠습니다. 그러나 main.ts 또는 index.ts에 대한 AMD 해상도에 대해 어떻게 생각하십니까? 미래에 일관되어야 하지 않을까요?

@sebilasse , AMD의 경우 #2338(섹션: RequireJS/ES6 모듈 로더)에서 @vladima 가 언급한 대로 작업을 수행해야 한다고 생각합니다.

아주 좋아요!! \영형/

@mhegazy 여전히 예상대로 작동하지 않습니다.

내 "이상적인" 사용 사례와 함께 https://github.com/DavidSouther/typescript-example-using-node 를 구성했습니다. tslib는 단일 함수를 내보내는 간단한 라이브러리입니다. tsclient는 tslib와 Node 패키지의 readline 에 의존합니다. 설정 스크립트는 설치, 연결 및 실행이 편리합니다. 나는 실행을 포함하고 인라인 주석으로 예기치 않은 부분에 주석을 달았습니다.

% ./setup
...
> [email protected] build ~/ts-node/tslib
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
...
> [email protected] build /Users/southerd/devel/tmp/ts-node/tsclient
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
# Expect this to find tslib, but fail type checking.
# See tsclient/app.ts for details
src/app.ts(4,21): error TS2307: Cannot find module 'tslib'.

+ node ./dist/app.js # This works as expected!
What would you ask? What is the meaning of life?
42
+ set +x

또한 tsclient(VSCode 버전 0.7.0(0.7.0))에서 tslib 가져오기에 대한 언어 지원을 받지 못하지만 어떤 TSC를 사용하는지 또는 이를 변경하는 방법을 완전히 확신할 수 없습니다.

@DavidSouther TypeScript 컴파일러는 package.json의 'typings' 필드를 확인하여 '.d.ts' 파일을 찾습니다. 이 변경 으로 합법적인 오류처럼 보이는 src/app.ts(13,7): error TS2322: Type 'string' is not assignable to type 'number'. 가 표시됩니다.

아, 그 문서를 놓쳤나 봅니다. 여전히 두 번째 문제가 있습니다. VSCode tsc 버전을 어떻게 변경합니까?

"typescript.tsdk" 설정을 통해 VSCode에 맞춤형 TypeScript SDK 위치를 제공할 수 있습니다. tsserver.js 및 표준 '.d.ts' 파일이 포함된 폴더를 가리켜야 합니다. TypeScript가 npm 패키지로 설치된 경우 다음과 같습니다.

// Place your settings in this file to overwrite the default settings
{   
    "typescript.tsdk": "C:\\Sources\\bugs\\node\\typescript-example-using-node\\tslib\\node_modules\\typescript\\lib"       
}

샘플이 작동하는 사람이 있습니까? 나는 이것을 가지고 놀려고 오후 내내 노력했지만, 나는 항상 결국

error TS2307: Cannot find module

현재 코드는 node_modules/my-module/에 있습니다. 그리고 모든 내보내기를 처리하는 index.ts를 정의하고 typescript.main 아래의 package.json에서 참조했습니다. 소비자 프로젝트에서 'my-module'에서 {AClass} 가져오기를 시도했습니다. 그리고 import my-module = require('my-module'); 둘 다 typescript 1.7.0-dev.20150901에서 동일한 오류로 이어집니다.

--module commonjs 를 사용하여 상대적이지 않은 이름을 가진 모듈을 확인할 때 컴파일러는 node_modules\name\index.d.ts 의 이름과 일치하는 .d.ts 를 찾거나 package.json 를 찾습니다. typings 속성에 대해 가리키는 .d.ts를 로드합니다.

설명에서 index.ts 로 설정하는 것처럼 보이지만 실제로 종속성을 컴파일하고 싶지 않고 입력 내용을 소비하기를 원하므로 대신 index.d.ts 로 설정해야 합니다.

구현을 반영하기 위해 노드 모듈 확인 알고리즘의 단계를 업데이트했습니다. https://github.com/Microsoft/TypeScript/issues/2338

@DavidSouther 분명히 똑같은 문제가 있습니다. node_modules에서 의존성으로 컴파일하면 모듈을 해결할 수없고 오류가 출력되지만 여전히 js를 생성하고 실행하면 실행됩니다. 제가 모르는 설정 때문일 수도 있습니다. 내 d.ts는 대부분 비어 있습니다. 많은 .ts 파일에 정의된 내 모듈의 모든 클래스를 가져오고 다시 내보내는 일을 처리하는 index.ts가 있습니다. 그런 다음 내 d.ts 파일은 이 index.ts를 참조하고 다음과 같이 index.ts에서 모든 것을 내보냅니다.

/// <reference path="index.ts" />

declare module 'my_module' {
    export * from 'index';
}

또한 어떻게 든 여전히 node_modules에서 ts를 컴파일하므로 컴파일 후 삭제하려면 깨끗한 작업을 추가해야 합니다. 프로세스를 요약하는 기능에 대한 설명이 어딘가에 있습니까?

편집: 작동하게 되었지만 매우 해키하고 여전히 오류를 출력합니다. dts-generator를 사용하여 d.ts를 만든 다음 다음과 같이 클래스를 가져왔습니다.

import MyClass from '../../node_modules/my_module/dist/MyClass';

'my_module/MyClass'에서 MyClass 가져오기를 사용하면 오류 없이 컴파일되지만 런타임에 'my_module/MyClass' 모듈을 찾을 수 없다는 오류가 발생합니다. 위의 솔루션을 사용하면 컴파일된 .js를 직접 가리키고 컴파일 시간에 모듈을 찾을 수 없다는 오류를 출력하더라도 런타임에 어떻게든 작동합니다.

여전히 하위 모듈에서 가져오는 데 문제가 있습니다(예: npm install angular2, import { Inject, Binding } from 'angular2/di' . 오늘 밤 포함된 테스트 케이스를 얻기 위해 노력할 것입니다.

angular가 이미 TypeScript 컴파일러에서 예상하는 방식으로 타이핑을 번들로 제공한다고 생각하지 마십시오.

그것은 사실일 가능성이 높습니다. 나는 그들과 함께 일하고 그것이 어디에서 끝나는지 볼 것입니다.

이 기능은 typescript 1.1에서 잘 작동합니다(예: https://github.com/Nemo157/typescript_w_node_modules_example ).

하지만 typescript 1.5.3에서 실패했는데 변경된 사항이 있습니까?

------ 업데이트 ---------

1.6에 출시되는걸로 알고있습니다 감사합니다

1.6.2에서만 이 "반작용"을 얻을 수 있습니다.

먼저 dist 디렉토리에 my-lib.d.ts 가 있는 라이브러리를 패키징하고 package.json 파일 typings 속성(예: "typings" : "dist/my-lib.d.ts" )

그런 다음 다음을 사용하여 Test.ts TypeScript 파일에서 이 라이브러리를 가져옵니다.

import { MyObject } from "my-lib"

MyObject 가 제대로 임포트되고 js 코드가 트랜스파일 시 방출됩니다.
Visual Studio Code는 MyObject 에서도 완성 기능을 제공합니다.

그러나 다음과 같은 컴파일러 경고가 나타납니다.
Test.ts(10,60): error TS2306: File '[]/node_modules/my-lib/dist/my-lib.d.ts' is not a module.

Visual Studio Code는 실제로 가져오기를 하드 오류로 표시합니다.

노드 패키지에서 가져온 모듈은 "주변 모듈 선언"이 아니라 "외부 모듈"이어야 합니다. 즉, declare module "foo" {.. } 선언이 아니라 파일의 최상위 가져오기 또는 내보내기 선언입니다.

따라서 "my-lib" 패키지가 typescript로 작성되었다면 --declarations 로 빌드하고 타이핑을 메인 모듈의 .d.ts 파일로 설정하십시오. 그렇지 않고 타이핑이 직접 작성했거나 확실히 타이핑한 것이라면 외부 모듈로 변경하거나 #4665가 해결될 때까지 기다려야 합니다(곧).

이 제한의 이유는 나중에 패키지 사용자에게 전역 범위 오염 및 충돌을 일으킬 수 있기 때문입니다. 이것에 대한 긴 논의가 #4665에 있습니다.

다음은 향후 검색을 위한 몇 가지 문서입니다. https://github.com/Microsoft/TypeScript/wiki/Typepings-for-npm-packages

@mhegazy Javascript와 TypeScript 코드 모두에서 사용할 수 있는 Typescript로 작성된 commonjs 라이브러리 빌드를 자동화하려는 저의 탐구에 정말 도움이 된 빠른 답변에 감사드립니다.
import/export 구문 및 해상도는 최근에 너무 빠르게 이동하여 지금 당장은 누락된 것으로 생각되는 것이 빌드 방법에 대한 결정적인 가이드입니다.

나는 그것을 작동 시켰습니다 ... 한 가지주의 사항 (따라서 다른 질문)

다음은 설정의 단순화된 보기입니다.

라이브러리는 2개의 typescript 파일 A.ts 및 B.ts에 있는 3개의 객체 A1, A2 및 B로 구성됩니다. 뭔가

출처

A.ts

class A1{}
class A2{}
export { A1, A2 }

B.ts

class B{}
export { B }

노출하려는 것은 index.ts 에 수집됩니다.

export * from './A'
export * from './B'

짓다
빌드는 grunt의 도움으로 수행되며 --module commonjs 및 --declaration 플래그가 tsc 에 설정됩니다. 1.6.2
빌드의 최종 결과는 다음과 같은 트리입니다.

    package.json
    dist/
        js/
             A.js
             B.js
             index.js
        typings/
             A.d.ts
             B.d.ts
             index.d.ts

package.json 에는 다음 두 항목이 포함됩니다.

"main": "dist/js/index.js",
"typings": "dist/typings/index.d.ts"

TypeScript 1.6.2에서 이 라이브러리를 간단한 import {A1, A2, B} from "mylib" 와 함께 사용하면 절대적으로 잘 작동합니다. 다중 레벨 종속성(즉, 서로를 가져오는 라이브러리)도 잘 작동합니다.

문제가 발생하는 곳은 라이브러리가 TypeScript 라이브러리가 _아닌_ 다른 라이브러리에 의존할 때입니다.
라이브러리가 Node.js에 의존한다고 가정해 보겠습니다.
소스 파일 중 하나에는 NodeJS 입력에 대한 참조가 있습니다.
///<reference path="../typings/node/node.d.ts"/>

변환 시 <reference > 명령어는 해당 선언 파일에서 종료됩니다. 문제는 node.d.ts 에 대한 경로가 잘못되었거나 존재하지 않을 가능성이 있다는 것입니다.
이에 대해 권장되는 방법이 있습니까?

_참고_: index.ts 에는 <reference > 명령어를 포함할 이유가 없고 1.6에서는 index.ts 파일을 사용하여 라이브러리의 흥미로운 부분을 노출하면 이 문제가 완화됩니다. .2, 컴파일러는 Adts가 참조 명령어에 잘못된 경로를 가지고 있는 것을 신경 쓰지 않는 것 같습니다.

@bgrieder tsconfig.json 를 사용하여 Phosphor에서 이것을 처리합니다.
https://github.com/phosphorjs/phosphor-widget/blob/master/src/tsconfig.json

컴파일된 파일에 필요한 외부 입력을 추가하기만 하면 됩니다. 이는 외부 유형 중 하나라도 공개 인터페이스의 일부인 경우 코드 소비자가 빌드의 일부로 이러한 외부 유형을 제공해야 함을 의미합니다. _괜찮아요_. 이러한 정의를 번들로 제공하고 소비자가 사용하는 다른 lib가 동일한 정의를 번들로 제공한다면 중복 기호 충돌이 발생합니다.

@sccolbert 네!
<reference ...> 명령을 제거하면 모든 IDE에서 자동 완성이 중단될까 걱정했지만 아니요. 최소한 Visual Studio Code 0.8.0은 tsconfig.json 에서 해당 정의를 선택할 만큼 똑똑한 것 같습니다.

reference 로 완료했습니다. 훌륭한 !

@sccolbert

그 안에 일반 Node.js 프로젝트와 *.d.ts를 사용하는 경우 tsconfig 솔루션이 어떻게 도움이 됩니까?

@heycalmdown $# tsconfig 의 files 필드에 d.ts 를 추가하면 다음과 같은 예가 있습니다.

https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/tsconfig.json#L11
https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/index.ts#L10

여기서 import 대신 require 를 사용해야 한다는 점에 유의하세요. 단지 expect.js용 d.ts 파일이 내부적으로 작성되는 방식 때문입니다.

알겠습니다. 귀하의 리포지토리는 일종의 좋은 예처럼 보입니다.

이것이 TypeScript 1.6.2에서 실제로 구현되었습니까?

그렇다면 누군가 내가 여기서 무엇을 잘못하고 있는지 말해 줄 수 있습니까?:
https://github.com/chanon/typescript_module_example

아마도 es6 가져오기 구문을 원할 것입니다.

2015년 11월 4일 수요일 오전 6시 10분에 chanon [email protected] 이 작성했습니다.

이것이 TypeScript 1.6.2에서 실제로 구현되었습니까?

그렇다면 누군가 내가 여기서 무엇을 잘못하고 있는지 말해 줄 수 있습니까?:
https://github.com/chanon/typescript_module_example

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/247#issuecomment -153688004
.

방금 es6 가져오기 구문을 사용하도록 업데이트했는데 여전히 동일한 오류가 발생합니다(모듈을 찾을 수 없음).

$ node_modules package.json d.ts 파일을 가리키는 typings 키가 있어야 하며 $ typescript 키를 가리키는 것이 _아닌 .ts 파일을 지금 가지고 있습니다.

우리는 PhosphorJS에서 독점적으로(TS 1.6.2에서) 노드 모듈 확인을 사용하며 잘 작동합니다. 다음은 예입니다. https://github.com/phosphorjs/phosphor-widget/blob/f908341cb1d46ada8ad8149e695a75e7ea2fde57/package.json#L6

@sccolbert 에게 감사드립니다. 그러나 이 문제의 맨 위에 있는 제 초기 제안은 작성된 노드 모듈 패키지의 기본 TypeScript 진입점을 가리키는 typescript.main 속성을 package.json 에 허용하는 것이었습니다. 타입스크립트에서.

이렇게 하면 d.ts 타이핑 파일 없이 TypeScript 코드에서 TypeScript 모듈을 가져올 수 있습니다(생성할 필요도 없음).

@chanon 저는 코드를 실행하기 위해 무엇을 해야 하는지 지적한 것뿐입니다.

@sccolbert 감사합니다.

아는 사람이 이 특정 기능을 요청하는 다른 문제를 만들어야 하는지 알려줄 수 있습니까?

모듈 해결 로직과 관련된 주요 문제는 폐쇄된 #2338과 매우 복잡해 보이는 SystemJS 스타일 경로 해결을 지원하는 것으로 보이는 #5039인 것 같습니다.

그런데 이번 호에서 처음 요청한 것처럼 단순한 CommonJS 스타일 임포트가 잊혀진 것 같습니까? 적어도 typescript.main과 폴더에 대한 부분은 모듈로?

모듈과 모듈 소비자가 이미 TypeScript로 작성된 경우 d.ts 파일이 필요하고 갖고 싶어하는지 이해하지 못합니다.

실제로 상대적으로 ex.TypeScript 파일을 가져오는 것과 크게 다르지 않습니다 .

다음을 수행하는 대신:
import * as lib from '../relative/path/to/typescriptFile.ts'

또는:
import * as lib from '../../node_modules/myModule/index.ts'

TSC가 일반 node_modules 경로 확인을 사용하여 가져올 typescript 파일을 찾을 수 있도록 하십시오. 그리고 최소한 폴더를 모듈로 가져올 수 있도록(index.ts 포함) 두 번째 예에서 다음과 같이 할 수 있습니다.

import * as lib from 'myModule'

아니면 "당신은 정말로 당신의 의존성을 컴파일하고 싶지 않고, 당신은 단지 그들의 타이핑을 소비하기를 원합니다" 때문입니까?

@chanon 당신이 설명하는 행동은 지금 마스터에 있는 것입니다. typescript@next 시도해 주시겠습니까?

#2338의 원래 구현은 .d.ts인지 확인하기 위해 몇 가지 추가 검사를 추가했으며 이는 주로 귀하가 언급한 이유입니다. 패키지 사용자가 모든 컴파일러 호출에서 "소스"를 컴파일하고 컴파일러 옵션에 따라 다른 출력을 얻는 것을 원하지 않고 입력만 공유하고 싶습니다.

그러나 두 패키지를 모두 빌드하는 경우 반복하는 동안 그렇게 하고 싶을 수 있습니다. 제한은 #5278에서 제거되었습니다.

자세한 내용은 npm 패키지를 통한 타이핑 공유에 대한 위키 페이지를 참조하십시오. https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

@mhegazy에 대한 설명 감사합니다! 시도해 보겠습니다.

@mhegazy 방금 typescript@next 시도했는데 예상대로 작동합니다!

대단하다!!

그리고 이 문제와 관련 문제에 참여해 주신 모든 분들께 감사드립니다 :+1:

이 기능이 실제로 구현된 방식을 설명하기 위해 위의 문제 텍스트에 업데이트를 추가했습니다.

지뢰밭에 들어갈 위험이 있는 상황에서 package.json에 typings 속성이 _없는_ 평범한 npm 모듈에서 이것이 어떻게 작동할까요? typescript@next tape 또는 get-parameter-names 를 사용하려고 하면 패키지가 없다는 사실 때문에 해당 패키지를 찾을 수 없기 때문에 내 얼굴에 폭발합니다. 재산.

물론, 그것들은 typescript 모듈이 아니지만 해결 방법을 찾을 수 없는 것 같고 npm 생태계의 상당 부분을 잠급니다.

@danpantry 일반적으로 해당 모듈을 위해 특별히 작성된 일반 .d.ts 파일을 사용합니다. 확실히Typed 프로젝트에는 많은 공통 모듈에 대한 .d.ts 파일이 있습니다. 확실히 Typed에서 .d.ts 파일을 설치하고 관리하는 데 도움이 되는 tsd 유틸리티가 있습니다.

일반 commonjs require 구문을 사용하면 입력하지 않고 일반 모듈을 사용할 수 있습니다.

예
var 모듈 이름 = 필요("모듈 이름")

@chanon 은 TypeScript와 함께 ES6 구문을 사용할 때 JavaScript 종속성을 사용할 수 있도록 '클래식' require 구문을 사용하는 것이 약간 해킹처럼 느껴지지만 감사합니다. tsd 유틸리티에 대해 들어본 적이 있지만 이러한 종류의 모듈에 /// <reference path=... 를 사용하기 시작하지 않는 한 이것이 ES6 가져오기를 사용하는 데 어떻게 영향을 미칠지 잘 모르겠습니다.

네, 한 가지 방법입니다. 또 다른 방법은 tsconfig.json 파일을 사용하고 루트 tsd.d.ts 파일을 첫 번째 파일로 두는 것입니다.

tsd 및 타이핑 https://angularclass.com/the-state-of-typescript-packages/ 를 포함하여 이것을 읽는 데 관심이 있을 수도 있습니다.

@joewood 정보 감사합니다. 마지막으로 typescript를 조사한 것은 개별 .d.ts 파일 시대였습니다. 우수한 기사

@chanon @danpantry foo의 package.json에 타이핑이 없을 때 import foo = require('foo') (node_modules 아래에 foo 포함)이 작동하지 않는 것은 다소 불행한 일입니다.

@wmono 글쎄요. TypeScript 0.80 또는 이전 import foo = require('foo') 구문은 타이핑이 있는 모듈을 가져오기 위한 것이었으니까요. 타이핑이 없으면 대신 var foo = require('foo') 를 사용합니다. 그래서 나는 그것이 있는 그대로라고 말하고 싶다.

@chanon 실례합니다; 사용자 오류. webpack이 "벌거벗은" require 로 고군분투하는 것처럼 보였지만 문제는 다른 곳에 있었습니다.

누군가가 이유를 명확히 할 수 있습니다 죄송합니다
var foo = require('foo');
타이핑 없이 표준 node_module에서 작동하지만
import foo from 'foo';
그렇지 않아? 그냥 임의로 정의한건가요? 후자가 작동하지 않아야 하는 이유를 모르겠습니다. 외부 JS 라이브러리에 입력이 있는지 여부는 신경 쓰지 않습니다.

누군가가 이유를 명확히 할 수 있습니다 죄송합니다
var foo = require('foo');
타이핑 없이 표준 node_module에서 작동하지만
'foo'에서 foo를 가져옵니다.
그렇지 않아? 그냥 임의로 정의한건가요? 후자가 작동하지 않아야 하는 이유를 모르겠습니다. 외부 JS 라이브러리에 입력이 있는지 여부는 신경 쓰지 않습니다.

@harangue 는 var require 가 _유형 검사 시스템 외부에서_ 지원되는 경쟁 모듈 구문 중 하나였기 때문입니다(이 구문은 commonjs 이고 목록에 있는 다른 구문은 amd 포함). 유형 시스템을 사용하려면 import require 를 사용합니다. ES6에서 :hammer:를 사용하고 하나의 구문(:ring:)이 모든 것을 지배한다고 말하면 ... 상자에서 꺼내는 형식 검사 시스템에서 해당 모듈 구문을 지원하는 것이 합리적입니다.

@basarat 설명 감사합니다. 아이콘도 유용했습니다. ;) ES6 구문이 유형 검사를 요구하는 이유는 아직 확실하지 않습니다. 컴파일러가 "오, 해당 모듈에 대한 유형 데이터를 찾을 수 없지만 어쨌든 가져올 것입니다"라고 말하는 것을 막는 방법은 무엇입니까? 이(오히려 직관적인 IMO) 행동은 어떤 부작용을 일으키나요?

이것은 ES6에서 TypeScript로 넘어가는 사람들(저와 같은)에게는 혼란스럽습니다. ES6 모듈 가져오기 구문이 TypeScript에서 동일한 방식으로 작동할 것으로 예상하지만 안타깝게도 대부분의 npm 패키지에서는 전혀 작동하지 않습니다...

하지만 대부분의 npm 패키지에서는 전혀 작동하지 않습니다...

@teohhanhui 헷갈립니다. 달성하려는 것과 이를 달성하기 위해 시도한 코드에 대한 구체적인 예를 제공할 수 있습니까? 이것은 내가 당신을 도울 수 있도록 하기 위한 것입니다 :장미:

import koa from 'koa';

target 가 es6 일 때 $ Cannot find module 'koa'. (2307) 를 제공합니다.

koa 는 (물론) node_modules 입니다.

그러나 koa는 프로젝트와 함께 Typescript 타이핑을 게시하지 않습니다. 이것은 프로젝트와 함께 .d.ts를 게시하고 package.json에 나열하는 패키지에만 해당됩니다. koa는 그렇지 않으므로 확실히 유형 지정에서 해당 유형 정의를 추가로 설치하려고 할 것입니다.

import 문이 일반 ES6 모듈에서와 같이 작동할 것으로 예상하기 때문에 이는 잘못된 결정처럼 보입니다. (예, 대부분의 npm 패키지는 CommonJS 모듈이지만 여기에서 지원하는 것이 여전히 현명한 일이라는 것을 압니다.)

TypeScript를 처음 사용하기 때문에 아마도 잘못 이해하고 있을 수 있지만 유형 정의는 선택 사항이 아닙니까? 유형 정의 없이 패키지를 가져올 수 없는 이유는 무엇입니까? 유형 정의를 찾거나 생성하도록 강요받고 싶지 않습니다.

레거시 TS 모듈 가져오기 구문으로 전환하는 것은 es6 대상을 사용할 때 허용되지 않기 때문에 옵션이 아닙니다.

TypeScript를 처음 사용하기 때문에 아마도 잘못 이해하고 있을 수 있지만 유형 정의는 선택 사항이 아닙니까?

그것은 잘못된 것입니다. _자신의 코드에서_ 유형 정의는 암시적일 수 있습니다. 즉, Typescript 컴파일러가 "알아낼" 것입니다. Typescript 컴파일러를 통해 타사 라이브러리를 전달하지 않을 것이므로 컴파일러는 이러한 유형이 무엇인지 결코 알지 못합니다. 타사 코드를 사용할 계획이라면 확실히 형식화 및 tsd 도구를 사용하는 방법을 배워야 합니다.

@basarat의 이 답변은 어떻습니까?

http://stackoverflow.com/a/27434010/1529493

유형 정의가 없는 비 TypeScript 모듈을 그대로 가져올 수 없는 이유는 무엇입니까?

const koa = require(‘koa’)

2016년 1월 21일 14시 47분에 Teoh Han Hui [email protected] 이 다음과 같이 썼습니다.

유형 정의가 없는 모듈을 그렇게 가져올 수 없는 이유는 무엇입니까?

—
이 이메일에 직접 회신하거나 GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173574234에서 확인하세요.

@bgrieder ES6 가져오기 구문을 참조하고 있습니다.

(즉, commonjs를 사용하고 있음) 그렇지 않은 경우 declare var of Basarat 답변을 사용하십시오.

2016년 1월 21일 14시 48분, Bruno Grieder bruno. [email protected] 은 다음과 같이 썼습니다.

const koa = require(‘koa’)

2016년 1월 21일 14시 47분에 Teoh Han Hui < [email protected] [email protected] >이(가) 다음과 같이 썼습니다.

유형 정의가 없는 모듈을 그렇게 가져올 수 없는 이유는 무엇입니까?

—
이 이메일에 직접 회신하거나 GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173574234에서 확인하세요.

요점은 TypeScript의 목표 중 하나가 유효한 JS가 유효한 TS여야 한다는 것입니다. ES6 모듈 구문의 경우 TS는 유형 선언이 있든 없든 이것을 컴파일해야 합니다. 유형 선언이 없으면 import 문은 any 로 해석되어야 합니다.

나는 그것에 전적으로 동의합니다.

@조우드 👍

2016년 1월 21일 14시 52분에 Joe Wood [email protected] 에서 다음과 같이 썼습니다.

요점은 TypeScript의 목표 중 하나가 유효한 JS가 유효한 TS여야 한다는 것입니다. ES6 모듈 구문의 경우 TS는 유형 선언이 있든 없든 이것을 컴파일해야 합니다. 형식 선언이 없으면 import 문은 any로 해석되어야 합니다.

나는 그것에 전적으로 동의합니다.

—
이 이메일에 직접 답장하거나 GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173575301에서 확인하세요.

FWIW 이 동작(모든 타사 라이브러리를 미리 입력해야 함)으로 인해 TypeScript보다 Flow를 사용하게 되었습니다. TypeScript는 IDE를 지원하지만 모든 것이 미리 입력될 것이라고 기대하는 것은 합리적이지 않습니다. 특히 다음과 같은 라이브러리가 많이 있는 경우에는 더욱 그렇습니다.

• 확실하게 입력되지 않음
• ./typings 폴더가 없습니다.
• 직접 쓸 시간이 없어요

내 발전에 도움이 될 만한 일과 싸우지 않는 것이 좋습니다.

@danpantry , lib 진입점을 any로 선언하면 컴파일러는 다음과 같이 만족할 것입니다.

declare var $: any;

해결 방법입니다. 하지만 TypeScript가 ES6 모듈 코드를 존중하고 우아하게 폴백하는 것이 좋은 아이디어라고 생각합니다. 최상위 모듈이 유형이 지정되지 않은 경우 가져오기 문이 오류를 보고하는 대신 any 로 대체할 수 없는 이유를 알 수 없습니다.

나는 런타임 문제가 눈에 띄지 않게 서서히 커지는 것보다 컴파일러가 일찍 그리고 큰 소리로 (현재 동작) 실패하는 것을 선호합니다. 명시적으로 declare var foo: any 행을 사용하여 "이것은 안전하지 않으며 내가 무엇을 하고 있는지 알고 있습니다"라고 표시하는 것을 선호합니다.

사용할 수 있는 입력이 없을 때 ES6 가져오기 구문을 허용하지 않는 이유는 «방출 방지» 오류 대신 가져오기가 any 로 해결되었다는 간단한 컴파일러 경고 문제가 있습니까?

2016년 1월 21일 18:42에 S. Chris Colbert [email protected] 이 다음과 같이 썼습니다.

런타임 문제가 눈에 띄지 않게 발생하기보다는 컴파일러가 조기에 큰 소리로 실패하는 것을 선호합니다(현재 동작). 명시적으로 var foo: any 라인을 선언하여 "이것은 안전하지 않으며 내가 무엇을 하고 있는지 알고 있습니다"를 표시하는 것을 선호합니다.

—
이 이메일에 직접 회신하거나 GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173649845에서 확인하세요.

어쨌든 컴파일러는 현재 모듈을 찾을 수 없다고 주장하지만 실제로는 유형 정의 없이 모듈 가져오기를 거부하는 것뿐입니다. 별로 도움이 되지 않죠?

^^ 천번입니다. 이 문제가 처음 발생했을 때 내가 뭔가 잘못하고 있다는 표시가 없었습니다. 마침내 무슨 일이 일어났는지 알아내는 데 오랜 시간 힘든 인터넷 검색이 필요했습니다. 너무 불필요합니다. 그리고 Angular 2가 TypeScript를 주류로 끌어들이면서 이 동작에서 얼마나 많은 스택 오버플로 질문이 나올지 상상할 수 있습니다.

열악한 오류 처리 설명에 매우 동의하고 그대로 가져옵니다!

@sccolbert 알림이 있어야 한다는 데 동의하지만 실패여야 하는지 잘 모르겠습니다. 대신 경고가 표시될 수 있습니다.

@mhegazy 및 @sccolbert에 동의합니다.

나는 우리의 프로덕션 빌드 스크립트(즉, CI 서버)가 문제가 있는 경우 큰 소리로 불평하는 것을 훨씬 선호합니다.

안녕하세요 여러분,
이 행동은 나를 미치게 만듭니다. 정의 파일이 최신 상태가 아니거나 package.json 에 등록되어 있지 않습니다.
결국 TypeScript 는 JavaScript 를 생성하므로 우리 모두가 이 언어로 갈 때까지 당신과 같은 다른 트랜스파일된 언어로 된 모국어용 라이브러리를 제공하는 나머지 세계에 대해 관대해지십시오. .
TypeScript 이 JavaScript 생태계에 머물기를 원하는지(아직 없는 것처럼 "통합"이라고 말하고 싶습니다), 아니면 다른 삶을 살기를 원하는지 알고 싶습니다. 두 번째 옵션은 나를 다른 곳으로 이동하게 할 것입니다.
.tsconfig 파일의 스위치가 작동하도록 하려면 엄격한 가져오기를 원하는지 여부를 말할 수 있습니다.
CI 시끄러운 불만에 대해서는 JavaScript 에 이에 대한 테스트 프레임워크가 있습니다. 어쨌든 런타임에 유형 검사를 받지 못할 것이므로 가져오기 검사가 제대로 이루어지지 않는 것이 덜 중요한 문제입니다.
모두 제일 좋다.

@devel-pa, 오류는 컴파일러가 가져오기가 무엇인지 전혀 모른다는 것을 의미합니다. 가져오기의 후속 사용은 확인할 수 없습니다.

오류를 끄면 문제가 해결되지 않습니다. 시스템 전체에서 이러한 "알 수 없는" 항목을 자동으로 푸시합니다. 유형 정보가 없으면 컴파일러는 안전한 것과 그렇지 않은 것을 경고할 수 없습니다. 이것이 TypeScript의 요점입니다. :)

생성된 JS의 경우. TS 유형 오류 중 어떤 것도 출력 생성을 중지하지 않습니다. 유형 오류에 신경 쓰지 않는다면 모두 무시하십시오. 컴파일러는 여전히 일치하는 .js 파일을 생성합니다.

누락된 정의에 대한 해결책은 정의를 선언하는 것입니다. 모듈의 전체 모양을 선언할 필요는 없고 이름만 있으면 됩니다. 이를 통해 컴파일러는 "myLibrary" 모듈이 있다는 것을 알게 되며, 모듈 이름의 오타에 대해 경고할 수 있으며 더 중요한 것은 다른 모듈이 확인되지 않을 것이라는 점입니다.

declare module "myLibrary" {
    var a: any;
    export = a;
}

#6615에 설명된 대로 TypeScript는 곧 더 짧은 형식을 지원해야 합니다.

문제는 이것이 온보딩 프로젝트에 발생하는 고통이라고 생각합니다. 이 문제는 암시적 any 와 유사하다고 생각합니다. 현재 이러한 가져오기는 본질적으로 암시적 void 입니다. 물론 오류는 무시할 수 있지만 이는 많은 소음을 일으키고 점진적인 입력 철학에 어긋나고 유효한 JS는 유효한 TS입니다.

TS를 처음 접하는 사람들의 혼란을 이해할 수 있습니다. JS에서 ES6 모듈 구문을 적극적으로 사용했다면 TS에서만 작동하지 않는 이유는 무엇입니까? var x = require 에 대한 import from 의 특별한 점은 암시적 any로 _is_ 취급됩니다. 원래 가져오기 는 TS 특정 키워드였으므로 개발자가 모듈을 유형이 지정된 모듈로 처리하기를 원한다는 의미였습니다. 이제 TS에만 해당되는 것이 아니기 때문에 그런 가정을 할 수 없다고 생각합니다.

암시적 오류는 유형이 없는 변수 선언에 있습니다. 그러나 선언되지 않은 변수를 사용하는 것은 오늘날에도 여전히 오류입니다. jquery의 경우, 컴파일러가 $ 라는 전역 변수를 갖고 있다는 것을 알 수 있도록 어딘가에 declare var $; 가 필요합니다. 모듈에 대해 거의 동일하므로 컴파일러는 "myLibrary" 라는 모듈이 있으며 이는 입력이 잘못된 이름이 아님을 알아야 합니다. 따라서 선언을 추가하십시오.

어쨌든, #6615는 시스템의 모든 모듈과 일치하도록 declare module "*"; 추가를 지원해야 합니다. 하지만 그렇게 하면 도구에서 도움을 받지 못하고 고통스러운 나중에 제거하기로 결정할 때 전환하십시오.

@mhegazy 나는 당신의 추론을 이해하지만 이 근거에 정말 문제가 있습니다

기본적으로 "자리 표시자" 모듈 정의를 설계하라고 하면 문제가 사라집니다.
이 위험은 적당한 크기의 프로젝트에서 잠시 후 이러한 "자리 표시자" 정의가 갑자기 나타나서 일부 타이핑 디렉토리에 묻힐 수 있다는 것입니다. 더 이상 경고가 없으면 모든 사람이 경고를 잊어버리고 문제가 발생하면 모든 모듈 정의를 살펴보고 어느 것이 자리 표시자인지 확인하는 것은 고통스러울 것입니다.

상황은 우리가 적절하게 입력된 것으로 가정할 수 있는 유형이 지정된 모듈(package.json에 typings 항목이 있는 모듈)이 실제로 내부적으로 해당 자리 표시자를 사용할 수 있는 경우 더욱 악화됩니다.

이러한 자리 표시자는 방지할 수 없다는 것을 이해하지만 최소한 권장되지 않는 것이 좋습니다.
옹호해야 하는 것은 기본적으로 가져오기가 any 로 해석되고 컴파일러 가 모든 컴파일에서 경고를 발행한다는 것입니다. 따라서 최소한 컴파일러/CI 로그를 보면 뭔가 문제가 있고 개선이 필요하다는 것을 알 수 있습니다.

(단, typescriptlang.org 홈 페이지에 명시된 바와 같이 Typescript는 Javascript의 '상위 집합'이며 IMHO는 유효한 ES6 구문을 있는 그대로 삼켜야 합니다.)

해결 방법과 카펫 아래에 쓰레기를 숨기는 것은 나에게 일어날 수 있는 최악의 일입니다(ES6 super 외에).
저는 항상 JS 라이브러리로 작업하고 있으며 일반적으로 집에서 작업 및 추가 코딩의 일부로 마지막 버전을 사용합니다. 90%는 형식이 지정되지 않았거나 오래된 def가 있고 9%는 형식이 좋지 않습니다(컴파일러가 모든 파일에 대해 하나의 def를 만드는 것을 알지 못하기 때문에). 어느 쪽도 매우 좋은 정의를 가지고 있지 않습니다. 동일한 이전 이유와 내 대상이 JS라는 이유로 원래 언어에 대해 신경 쓸 필요가 없다고 생각합니다.
또한 '알 수 없는' 라이브러리가 있는 이유도 보았습니다. 아니요, 전혀 아닙니다. 개발자가 사용되는 라이브러리가 무엇인지 이해하고 이해하지 못한다면 왜 귀찮게 합니까? 저는 제가 왜 물건을 사용하고 있으며 스택에 추가하는 이유를 압니다. 경고와 테스트(존재하는 경우)로 충분합니다.
Pls, JavaScript 먼저, 이것이 대상이자 생태계입니다. TS는 컴파일 시간에 더 나은 코딩 및 유형 검사를 위한 액세서리일 뿐이지만 우리가 구축하고 있는 것에 한합니다. 나머지는 타이프스크립트 사업이 아닙니다.
나는 nmps peerDependencies 에도 반대했고 소프트웨어가 아니라 내가 선택한 사람임을 언급하고 싶습니다. 명령형 프로그래밍, 자기야.

node_modules 대신 JSPM 디렉토리에서 모듈을 가져오는 것은 어떻습니까?

편집: 기존 티켓을 찾았습니다 -> https://github.com/Microsoft/TypeScript/issues/6012

SystemJS를 사용하여 디렉토리를 로드할 때 노드 모듈 확인 문제가 발생했습니다.

분명히 Node(따라서 TypeScript)는 경로가 실제로 디렉토리라는 것을 이해하고 대신 index.ts 를 로드하지만 SystemJS는 그런 일을 하지 않습니다. 즉, 유효한 TS 코드가 실제로 브라우저에서 로드되지 않습니다.

이는 index.ts/js 진입점이 있거나 package.json main 속성을 사용하는 노드 모듈에서도 마찬가지입니다. 이것은 SystemJS에 패키지 구성을 추가하는 것이 (반복적이지만) 쉽기 때문에 작업하기가 약간 더 쉽습니다. 이것은 임의의 디렉토리로 작업할 때 쉽지 않습니다.

이에 대한 적절한 해결책은 무엇입니까?

JSPM 자동 모듈 확인은 현재 지원되지 않습니다. 이것은 https://github.com/Microsoft/TypeScript/issues/6012에서 추적합니다.

경로 매핑 모듈 확인 지원을 사용하는 것이 좋습니다( https://github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module%20Resolution.md#path -mapping 참조).

위의 지침은 시작이지만 일부 사람들은 추가 작업을 수행해야 할 수도 있습니다. 추가해야 할 수도 있습니다.
<Folder Include="node_modules" />
.njsproj로

더 많은 정보

나는 꿀꺽 꿀꺽 꿀꺽 마시고 있었고 .nsproj에서 TypeScriptCompileBlocked를 사용했습니다. VS 15 Preview 5에서 디버깅 중단점 문제("모듈에 프레임이 없음" 오류가 발생함) 및 Intellisense에서 발생했던 문제를 수정하려면 추가해야 했습니다. .njsproj로. 그 디렉토리는 내가 프로젝트를 가져올 때 이미 거기에 있었지만 git-ignore로 설정되었습니다. 이것이 Visual Studio가 이를 무시한 이유에 대한 제 이론입니다(아마도 node_modules에 대한 자동 예외가 있어야 합니까?)

디버깅과 Intellisense 모두 ​​작동하는 것 외에도 예상되는 대로 꿀꺽 꿀꺽 꿀꺽 꿀꺽꺽꺽하면서 본 것과 똑같은 오류를 넘어서는 Intellisense 오류도 더 이상 볼 수 없었습니다.