이 저장소는 고품질의 타입스크립트(TypeScript) 자료형 정의(Type definition)를 위한 저장소입니다.
이 도움말은 영어, 스페인어, 러시아어, 그리고 중국어로도 읽으실 수 있습니다!
관리자 설명서 링크
저장소 및 퍼블리싱 과정의 상태를 표시합니다. 기여자분들이 작성한 PR 또는 패키지에 문제가 발생했을 경우 이 표시를 보면 도움이 될 수 있습니다.
- 최신 빌드가 타입 체크/린트 과정을 깔끔하게 통과했습니다:
- 모든 패키지가 typescript@next상에서 타입 체크/린트 과정을 깔끔하게 통과합니다:
- 모든 패키지가 1시간 내에 npm에 배포되었습니다:
- typescript-bot이 Definitely Typed에서 잘 돌고 있습니다
상태 표시가 비정상이거나 고장 표시가 발생하면 Definitely Typed Discord 채널에서 이 문제를 알려주세요.
타입스크립트 안내서(TypeScript handbook)를 읽어보세요.
이 방법을 사용하기를 추천합니다. 아래는 예시입니다:
npm install --save-dev @types/node
node
를 위한 자료형(Typing)이 컴파일 과정에 자동으로 포함될 겁니다.
모듈을 사용하지 않는 경우 types
참조를 추가해 주어야 할 수 있습니다.
/// <reference types="node" />
더 자세한 내용은 안내서(Handbook)에서 확인해보실 수 있습니다.
npm 의 "foo" 패키지에 대응되는 자료형 패키지는 "@types/foo" 입니다. 원하시는 패키지를 찾을 수 없는 경우, 타입서치(TypeSearch) 사이트에서 한 번 찾아보세요.
그래도 찾을 수 없는 경우, 찾고 있는 패키지가 자료형(Typing)을
함께 제공하고 있지는 않은지 확인해보세요.
이 경우 주로 package.json
파일의 "types"
나 "typings"
필드(Field)를 통해 제공되지만,
/// <reference path="" />
같은 주석을 사용하여 패키지 안의 ".d.ts" 파일들을 직접 가져와야 할 수도 있습니다.
이전 버전 TypeScript
@types
패키지 안에는 패키지가 확실하게 지원하는 TypeScript 버전이 태그로 쓰여 있으므로, 2년 지원 기간이 지난 오래된 패키지도 보통 찾아보실 수 있습니다.
예를 들어, npm dist-tags @types/react
명령어를 입력하면 TypeScript 2.5는 [email protected]용 타입을, TypeScript 2.6 및 2.7은 [email protected]용 타입을 사용할 수 있는 것을 확인하실 수 있습니다:
태그 | 버전 |
---|---|
latest | 16.9.23 |
ts2.0 | 15.0.1 |
... | ... |
ts2.5 | 16.0.36 |
ts2.6 | 16.4.7 |
ts2.7 | 16.4.7 |
... | ... |
- 이 저장소의
master
브랜치에서 직접 다운로드해 프로젝트에 삽입하기 Typings를 사용하기(다른 방법을 사용해주세요. typings는 더이상 추천하지 않습니다)NuGet 을 사용하기(다른 방법을 사용해주세요. NuGet은 더 이상 DT 자료형(Typing)을 제공하지 않습니다.)
위 방법을 사용할 경우 수동으로 참조(Reference)를 추가해주어야 할 수 있습니다.
Definitely Typed는 여러분과 같은 많은 기여자들의 도움 덕분에 돌아가고 있습니다!
개선한 부분을 세상에 공유하기 전에 먼저 직접 사용해 보세요.
새로운 기능을 추가하려면 모듈 증강(module augmentation)를 사용할 수 있습니다.
물론 node_modules/@types/foo/index.d.ts
를 직접 수정하실 수도 있으며, 이 파일을 복사한 다음 아래의 과정을 따라하실 수도 있습니다.
사용하고 계신 tsconfig.json
에 다음 내용을 추가해주세요.
"baseUrl": "types",
"typeRoots": ["types"],
(types
대신 src/types
을 사용하실 수도 있습니다.)
그리고 "foo" 모듈(Module)에 대한 선언(Declaration)을 포함하는 types/foo/index.d.ts
파일을 만들어주세요.
이제 코드 안에서 여러분의 새 자료형 선언(Type declaration)을 사용하는 "foo"
모듈(Module)을 임포트(Import)하실 수 있을 겁니다.
코드를 컴파일하고 실행시켜서 여러분의 자료형(Typing)이 실행 중에 실제로 벌어지는 일과 잘 맞아떨어지는지 확인해주세요.
실제 코드를 통한 확인이 끝나면, 풀 리퀘스트(Pull request)를 만들어주세요.
이미 존재하는 패키지를 수정하거나 새 패키지를 만들기위한 과정들을 따라하시면 됩니다.
패키지가 잘 작동하는지 확인하셨다면, Definitely Typed에 공유해주세요.
우선, 이 저장소를 포크(fork)해 주시고, node 를 설치하신 뒤, npm install
명령을 실행해주세요.
cd types/<package to edit>
명령을 실행합니다.- 자료형(Typing) 파일들을 수정합니다. 테스트를 추가하는 것도 잊지마세요! 만약 브레이킹 체인지(Breaking change)를 만드셨다면, 메이저 버전(major version)을 꼭 올려주세요.
- 패키지 머릿주석의 "Definitions by" 부분에 여러분의 이름을 추가하실 수도 있습니다.
- 이름을 추가하시면 다른 사람들이 그 패키지에 대한 풀 리퀘스트(Pull request)나 이슈(Issue)를 만들 때 여러분에게 알람이 갑니다.
// Definitions by: Alice <https://github.com/alice>, Bob <https://github.com/bob>
와 같이 여러분의 이름을 줄의 맨 마지막에 추가할 수 있습니다.- 사람이 너무 많을 경우엔, 다음과 같이 여러 줄로 쓰실 수도 있습니다.
// Definitions by: Alice <https://github.com/alice> // Bob <https://github.com/bob> // Steve <https://github.com/steve> // John <https://github.com/john>
npm test <package to test>
명령을 실행시키고 결과를 확인해주세요.
이미 존재하는 패키지에 대한 풀 리퀘스트(Pull request)를 만들었을 경우에는, dt-bot
이 이전 저자들을 자동으로 호출하는지 확인해주세요.
그렇지 않은 경우에는, 여러분이 직접 풀 리퀘스트(Pull request)와 관계있는 사람들을 호출할 수도 있습니다.
만약 라이브러리를 만드는 중이고 라이브러리가 타입스크립트(TypeScript)로 쓰여있다면, Definitely Typed 에 선언(Declaration)을 올리는 대신 패키지에 자동생성된 선언(Declaration) 파일을 포함시킬 수 있습니다.
npm 패키지를 위한 자료형(Typing) 패키지를 만드시려면, 패키지의 이름과 같은 이름의 디렉토리를 만들어주세요.
npm 에 올라가 있지 않은 패키지를 위한 자료형(Typing) 패키지를 만드시려면, 그 패키지가 npm 에 올라와 있는 패키지와 이름이 겹치지 않는지 확인해주세요.
(npm info <my-package>
명령어를 사용하여 <my-package>
패키지가 npm 에 있는지 확인할 수 있습니다.)
새 자료형 패키지는 다음과 같은 구조로 구성되어있어야만 합니다.
파일 이름 | 용도 |
---|---|
index.d.ts |
패키지를 위한 자료형(Typing)을 포함하는 파일입니다. |
<my-package>-tests.ts |
자료형(Typing)의 테스트를 위한 파일입니다. 이 파일의 코드는 실행되지는 않지만, 자료형 검사(Type checking)를 통과해야 합니다. |
tsconfig.json |
tsc 명령을 돌릴 수 있게 해주는 파일입니다. |
이 파일들은, npm ≥ 5.2.0 에서는 npx dts-gen --dt --name <my-package> --template module
명령으로,
그 이하 경우에는 npm install -g dts-gen
와 dts-gen --dt --name <my-package> --template module
명령으로 만들 수 있습니다.
dts-gen
의 모든 옵션(Option)을 보고싶으시면 dts-gen 저장소를 확인해주세요.
Definitely Typed 의 관리자들이 주기적으로 새로운 풀 리퀘스트(Pull request)들을 확인하기는 하지만, 다른 풀 리퀘스트(Pull request)가 많을 경우 확인이 느려질 수 있다는 걸 알아주세요.
base64-js 패키지는 좋은 예시 중 하나입니다.
패키지가 스스로의 형(Type)을 포함하게 되면, Definitely Typed 에 있는 자료형(Typing) 패키지를 삭제하는 것이 좋습니다.
pnpm run not-needed -- <typingsPackageName> <asOfVersion> [<libraryName>]
명령어를 사용하여 자료형(Typing) 패키지를 삭제할 수 있습니다.
<typingsPackageName>
는 삭제할 디렉토리의 이름입니다.<asOfVersion>
는 새 스텁(Stub) 용@types/<typingsPackageName>
를 퍼블리시(Publish)할 버전입니다. 이 버전은 현재 npm 에 올라간 버전보다 더 높은 버전이어야 합니다.<libraryName>
는 패키지의 이름을 읽기 쉽게 쓴 것입니다. 즉, "angular2" 대신에 "Angular 2" 와 같이 쓰는 것이 좋습니다. (생략했을 경우에는<typingsPackageName>
와 같은 것으로 취급됩니다.)
Definitely Typed 의 다른 패키지들이 삭제된 자료형(Typing) 패키지를 사용하고 있을 경우, 형(Type)을 포함하기 시작한 원래 패키지를 사용하도록 수정해야합니다. 삭제된 자료형(Typing) 패키지를 사용하는 각 Definitely Typed 패키지들의 package.json
파일에 "dependencies": { "<libraryName>": "x.y.z" }
를 추가해주시면 됩니다.
Definitely Typed 에 한 번도 올라온 적 없는 패키지가 형(Type)을 포함하게 되었다면, notNeededPackages.json
파일에 추가할 필요도 없습니다.
npm test <package to test>
명령을 통해 변경점을 테스트할 수 있습니다. 이 때, <package to test>
은 테스트하고 싶은 패키지의 이름입니다.
작성한 dts 파일을 타입스크립트 컴파일러로 돌려보기 위해 테스트 스크립트 내부적으로 dtslint를 사용합니다.
npm 패키지를 위한 자료형(Typing) 패키지를 만드시려면, 패키지의 이름과 같은 이름의 디렉토리를 만들어주세요.
npm 에 올라가 있지 않은 패키지를 위한 자료형(Typing) 패키지를 만드시려면, 그 패키지가 npm 에 올라와 있는 패키지와 이름이 겹치지 않는지 확인해주세요.
(npm info <my-package>
명령어를 사용하여 <my-package>
패키지가 npm 에 있는지 확인할 수 있습니다.)
If a non-npm package conflicts with an existing npm package try adding -browser to the end of the name to get <my-package>-browser
.
There should be a <my-package>-tests.ts
file, which is considered your test file, along with any *.ts
files it imports.
If you don't see any test files in the module's folder, create a <my-package>-tests.ts
.
These files are used to validate the API exported from the *.d.ts
files which are shipped as @types/<my-package>
.
Changes to the *.d.ts
files should include a corresponding *.ts
file change which shows the API being used, so that someone doesn't accidentally break code you depend on.
If you don't see any test files in the module's folder, create a <my-package>-tests.ts
For example, this change to a function in a .d.ts
file adding a new param to a function:
index.d.ts
:
- export function twoslash(body: string): string
+ export function twoslash(body: string, config?: { version: string }): string
<my-package>-tests.ts
:
import {twoslash} from "./"
// $ExpectType string
const result = twoslash("//")
+ // Handle options param
+ const resultWithOptions = twoslash("//", { version: "3.7" })
+ // When the param is incorrect
+ // @ts-expect-error
+ const resultWithOptions = twoslash("//", { })
If you're wondering where to start with test code, the examples in the README of the module are a great place to start.
You can validate your changes with npm test <package to test>
from the root of this repo, which takes changed files into account.
어떤 표현식(Expression)이 특정한 형(Type)을 가진다고 단언(Assert)하고 싶을 때에는 $ExpectType
를 사용하시면 됩니다. 어떤 표현식(Expression)이 컴파일에 실패해야하는 경우에는 @ts-expect-error
를 하시면 됩니다.
// $ExpectType void
f(1);
// @ts-expect-error
f("one");
dtslint 저장소의 README 파일에서 더 자세한 내용을 확인하실 수 있습니다.
If for some reason a lint rule needs to be disabled, disable it for a specific line:
// eslint-disable-next-line no-const-enum
const enum Const {
One,
}
const enum Enum { // eslint-disable-line no-const-enum
Two,
}
You can still disable rules with an .eslintrc.json, but should not in new packages. Disabling rules for the entire package makes it harder to review.
tsconfig.json
should have noImplicitAny
, noImplicitThis
, strictNullChecks
, and strictFunctionTypes
set to true
.
자료형(Typing) 패키지에 새 파일을 추가하거나, async
키워드를 사용하기 위해 "target"
을 "es6"
로 설정하거나, "lib"
를 추가하거나, jsx
지원을 추가하기 위해서 tsconfig.json
파일을 변경해야 할 수도 있습니다.
일반적으로는 package.json
파일을 사용할 필요가 없습니다. 패키지가 퍼블리시(Publish)될 때 패키지를 위한 package.json
파일은 자동으로 생성됩니다.
가끔 보이는 package.json
파일은 의존하는 것들을 표시하기 위해 사용됩니다. 예시를 한 번 보세요.
의존성을 제외한 다른 필드(Field)들, 그러니까 "description"
같은 것들은 사용해서는 안됩니다.
옛날 @types
패키지를 사용하고 싶으실 경우에도 "dependencies": { "@types/<libraryName>": "x.y.z" }
와 같은 내용을 package.json
파일에 넣으셔야 합니다.
If a file is neither tested nor referenced in index.d.ts
, add it to a file named OTHER_FILES.txt
. This file is a list of other files that need to be included in the typings package, one file per line.
- 우선, 안내서(Handbook)에 나와있는 내용들을 따라주세요.
- 코드에서는 모든 곳에서 탭(Tab)을 사용하거나, 항상 4 개의 띄어쓰기를 사용해주세요.
function sum(nums: number[]): number
의 경우, 만약 함수가 인자를 변경하지 않는다면ReadonlyArray
를 사용해주세요.interface Foo { new(): Foo; }
의 경우, 이런 선언은 이 형(Type)을 가진 객체(Object)에new
를 사용할 수 있도록 만듭니다. 많은 경우 여러분은declare class Foo { constructor(); }
를 사용하려는 것일 겁니다.const Class: { new(): IClass; }
의 경우,new
를 사용할 수 있는 상수를 만드는 대신,class Class { constructor(); }
와 같이 클래스 선언(Class declaration)을 사용하는 게 더 좋습니다.getMeAT<T>(): T
의 경우, 만일 자료형 매개변수(Type parameter)가 함수의 매개변수에 등장하지 않는다면, 그런 제너릭(Generic) 함수를 사용할 필요가 없습니다. 그 제너릭(Generic) 함수는 단순히 자료형 단언(Type assertion)을 위장시킨 것뿐입니다. 이 경우getMeAT() as number
와 같이 진짜 자료형 단언(Type assertion) 을 사용하는 게 더 좋습니다. 다음은 괜찮은 제너릭(Generic)의 예시입니다.function id<T>(value: T): T;
. 다음은 문제가 있는 제너릭(Generic)의 예시입니다.function parseJson<T>(json: string): T;
. 예외적으로,new Map<string, number>()
와 같은 경우는 괜찮습니다.Function
이나Object
와 같은 형(Type)을 사용하는 것은 대부분의 경우 문제를 일으킵니다. 99% 의 경우 더 구체적인 형(Type)을 사용하는게 가능합니다. 함수(Function) 를 위해서는(x: number) => number
와 같은, 객체를 위해서는{ x: number, y: number }
와 같은 형(Type)들을 사용할 수 있습니다. 형(Type)에 대한 정보가 전혀 없을 경우에는,Object
형(Type)이 아니라any
형(Type)을 사용해야 합니다. 만일 어떤 형(Type)이 객체라는 사실만 알고 있는 경우,Object
나{ [key: string]: any }
가 아니라object
를 사용해주세요.var foo: string | any
의 경우,any
가 합 자료형(Union type)의 안에서 사용될 경우, 결과 형(Type)은 언제나any
가 됩니다. 따라서 형(Type)의string
부분이 유용해 보인다 하더라도, 사실은 자료형 검사(Type checking)의 측면에서any
와 다른 것이 없습니다. 대신,any
,string
, 나string | object
중 하나를 필요에 맞게 골라서 사용해주세요.
DT has the concept of "Definition Owners" which are people who want to maintain the quality of a particular module's types
- Adding yourself to the list will cause you to be notified (via your GitHub username) whenever someone makes a pull request or issue about the package.
- Your PR reviews will have a higher precedence of importance to the bot which maintains this repo.
- The DT maintainers are putting trust in the definition owners to ensure a stable eco-system, please don't add yourself lightly.
To Add yourself as a Definition Owner:
- Adding your name to the end of the line, as in
// Definitions by: Alice <https://github.com/alice>, Bob <https://github.com/bob>
. - Or if there are more people, it can be multiline
// Definitions by: Alice <https://github.com/alice> // Bob <https://github.com/bob> // Steve <https://github.com/steve> // John <https://github.com/john>
Once a week the Definition Owners are synced to the file .github/CODEOWNERS which is our source of truth.
master
브랜치(Branch)의 내용들이 DefinitelyTyped-tools 를 사용해 자동으로 @types
퍼블리시(Publish)됩니다.
상황에 따라 다르지만, 대부분의 풀 리퀘스트(Pull request)들은 일주일 안에 합쳐집니다. 머릿주석에 있는 저자 중 한명에 의해 승인된 풀 리퀘스트(Pull request)는 보통 더 빨리 합쳐집니다. 새로운 패키지에 대한 풀 리퀘스트(Pull request)는 관리자의 세세한 코드 리뷰를 필요로 하기 때문에 더 오래 걸리는 경우가 많습니다. 각 PR 들은 합쳐지기 전에 TypeScript or Definitely Typed 팀 구성원의 코드 리뷰를 받아야 하며, 이는 사람이 하는 일이기 때문에 느려질 수도 있으니 양해를 바랍니다. 풀 리퀘스트 번다운 보드(New Pull Request Status Board)에서 열린 풀 리퀘스트에 대한 관리자들의 진행도를 확인하실 수 있습니다.
npm 의 패키지들은 수시간 안에 갱신될 겁니다. 만약 24 시간이 지나도 갱신되지 않으면, 문제를 파악하기 위해 @RyanCavanaugh 나 @andy-ms 를 풀 리퀘스트(Pull request)에서 호출해주세요.
다른 자료형 정의(Type definition)에 의존하는 자료형 정의(Type definition)을 만들고 있습니다. <reference types="" />
와 임포트(import) 중 무엇을 사용해야하나요?
외부 모듈(export
를 사용하는 모듈)을 사용할 경우, 임포트(import)를 사용해주세요.
환경과 관련된 모듈(ambient module)(declare module
를 쓰거나 전역 변수들을 선언한 모듈)을 사용할 경우, <reference types="" />
를 사용해주세요.
어떤 패키지들에 tslint.json
이 없거나, tsconfig.json
에 "noImplicitAny": true
, "noImplicitThis": true
, 나 "strictNullChecks": true
가 없어요.
그럼 그 패키지들이 잘못된 겁니다. 고쳐서 풀 리퀘스트(Pull request)를 제출해주시면 고맙겠습니다.
이미 요청된 자료형 정의(Type definition)들을 여기서 보실 수 있습니다.
웹 표준(Web standard)과 관련이 있는 자료형(Typing)들은 TSJS-lib-generator 저장소에 기여해서 고치실 수 있습니다. 고쳐진 자료형(Typing)은 lib.dom.d.ts
파일에 포함될 겁니다.
타입스크립트(TypeScript) 2.7 이상을 사용하고 계시면 프로젝트 안에서 --esModuleInterop
를 사용해주세요.
그 이하의 경우, 디폴트 임포트(Default import)가 동작하는 환경(Webpack, SystemJS, esm)에서 작업 중이시면 --allowSyntheticDefaultImports
를 사용하는 걸 고려해보세요.
자료형 정의(Type definition)가 맞는 경우에는 자료형 정의(Type definition)을 수정하지 마세요.
npm 패키지의 경우, node -p 'require("foo")'
가 원하는 값이라면 export =
이 맞고, node -p 'require("foo").default'
이 원하는 값이라면 export default
이 맞습니다.
정의(Definition) 머릿주석(// Definitions: https://github.com/DefinitelyTyped/DefinitelyTyped
) 뒤에 // Minimum TypeScript Version: 3.3
를 추가해주시면 됩니다.
TSJS-Lib-Generator 저장소가 관련되어있을 가능성이 있습니다. 해당 저장소의 안내를 따라주세요.
해당 표준이 아직 초안인 상태라면, 이 저장소와 관련된 일입니다.
dom-
으로 시작하는 패키지를 만드신 뒤, "Project" 머릿주석 부분에 해당 표준의 링크를 써 주세요.
다만 표준이 초안을 벗어나면 Definitely Typed 에서 삭제되고 @types
패키지가 지원이 중단된(Deprecated) 것으로 표시될 수도 있습니다.
옛날 버전도 계속해서 수정할 예정이라면, 이전 버전에 해당하는 새 디렉토리(예를 들어 2.
버전을 위해서는 v2
)를 만들고 현재 파일들을 그 디렉토리로 옮겨야 합니다. 새 디렉토리로 옮긴 뒤에는
tsconfig.json
와tslint.json
에 포함된 상대경로들을 수정해주어야 합니다.- 경로 대응 규칙(Path mapping rule)을 추가하여 테스트가 올바른 버전을 검사하도록 해야합니다.
예를 들어, history 패키지의 2 버전의 tsconfig.json
파일은 다음과 같이 생겼습니다.
{
"compilerOptions": {
"baseUrl": "../../",
"typeRoots": ["../../"],
"paths": {
"history": ["history/v2"]
}
},
"files": [
"index.d.ts",
"history-tests.ts"
]
}
수정 중인 패키지에 의존하는 Definitely Typed 의 다른 패키지들이 새 버전과 호환되지 않을 경우, 그 패키지들에도 옛날 버전으로의 경로 대응 규칙(Path mapping rule)을 추가해주어야 합니다. 수정 중인 패키지에 의존하는 패키지에 의존하는 패키지들에도 똑같은 작업을 해 주셔야 합니다.
예를 들어, browser-sync
패키지는 history@2
패키지에 의존하고 있기 때문에, browser-sync 패키지의 tsconfig.json
파일이 "micromatch": [ "micromatch/v2" ]
와 같은 경로 대응 규칙(Path mapping rule)을 가지고 있는 걸 볼 수 있습니다.
이어서 (browser-sync
패키지에 의존하는 패키지인) browser-sync-webpack-plugin
또한 tsconfig.json
파일 안에 경로 대응 규칙(Path mapping rule)을 가지고 있는 것을 보실 수 있습니다.
/// <reference types=".." />
에서는 경로 대응 규칙(Path mapping rule)이 동작하지 않기 때문에, Definitely Typed 패키지로에 의존할 때에는 임포트(import) 를 사용해야 합니다.
타입스크립트 안내서(TypeScript Handbook)은 선언(Declaration)을 쓰는 방법에 대한 전반적인 정보와 예시들을 포함하고 있습니다. 이 내용에는 ES6 식의 모듈 문법을 사용할 수 있는 자료형 선언(Type declaration)을 만드는 방법과 객체를 전역에서 사용할 수 있도록 하는 방법이 포함되어 있습니다. big.js
패키지의 자료형 선언(Type declaration)이 실례입니다. 이 패키지는 웹 페이지의 스크립트 태그를 사용해 불러올 수 있으며, 또한 ES6 식의 임포트(Import) 구문을 사용해서 불러올 수도 있습니다.
여러분의 패키지가 임포트(Import) 구문을 사용했을 때와 전역적으로 불렀을 때를 테스트 해보고 싶다면, test
디렉토리를 추가하고 YourLibraryName-global.test.ts
그리고 YourLibraryName-module.test.ts
라는 이름으로 테스트 파일 두 개를 추가해주세요. 전역(Global) 테스트 파일은 웹 페이지에서 전역적으로 사용될 때를 테스트하는 파일입니다. 이 파일에서는 임포트(Import) 구문을 사용하지 않아야 합니다. 모듈(Module) 테스트 파일은 임포트(Import) 구문을 사용할 때를 테스트 하는 파일입니다. 만약 여러분의 tsconfig.json
파일이 files
필드(Field)를 가지고 있다면, 이 필드(Field)는 반드시 두 테스트 파일을 모두 포함해야 합니다. 이 방식을 사용하는 실례 또한 big.js
패키지의 자료형 선언(Type declaration)에서 확인해보실 수 있습니다.
각각의 테스트 파일에 모든 상황을 테스트할 필요는 없다는 걸 잊지마세요. 전역 테스트 파일에서는 전역적으로 사용될 때만 테스트하고, 모듈 테스트 파일에서 나머지 상황들을 모두 테스트 할 수 있으며, 그 반대의 경우도 괜찮습니다.
@foo/bar
패키지와 같은 지역 패키지(Scoped package)를 위한 자료형 패키지(Type package)는 types/foo__bar
디렉토리에 추가하면 됩니다. 밑줄 문자가 두 번 있는 것에 주의하세요.
지역 패키지(Scoped package)를 위한 자료형 패키지(Type package)를 생성하기 위해 dts-gen
를 사용한 경우에는,
다음과 같이 생성된 tsconfig.json
안에 지역 패키지(Scoped package)를 위한 적절한 경로 대응 규칙(Path mapping rule)을 추가해주어야 합니다.
{
"paths": {
"@foo/*": ["foo__*"]
}
}
chai-http 패키지와 같은 몇몇 패키지들은 함수를 익스포트(Export)합니다.
이런 패키지들을 import * as foo from "foo";
와 같이 임포트(Import)하면 다음과 같은 오류가 발생합니다.
error TS2497: Module 'foo' resolves to a non-module entity and cannot be imported using this construct
이 오류는 함수의 이름과 똑같은 빈 이름공간(Namespace)을 정의해서 없앨 수 있으나, 좋은 방법은 아닙니다. 스택오버플로(Stack Overflow)의 이 질문의 답변이 이 문제와 관련되어 자주 언급됩니다.
import foo = require("foo");
를 사용하여 모듈을 임포트(Import)하거나, 환경에서 ES6 모듈 변환(Module interop)을 지원한다면 --allowSyntheticDefaultImports
와 함께 import foo from "foo";
같은 디폴트 임포트(Default import)를 사용하는 것이 더 나은 방법입니다.
이 프로젝트는 MIT license 가 적용되어 있습니다.
각 자료형 정의(Type definition) 파일들의 저작권은 각 기여자들에게 있으며, 기여자들은 해당 자료형 정의(Type definition) 파일들의 맨 위에 나열되어 있습니다.