TypeScript의 유형 정의 파일을 공유합니다!

8851 단어 TypeScript
2014/11/13 개정 CONTRIBUUTORS.md 자동 생성
안녕하세요. 주식회사 고층대문 미역@vvakame입니다.
Type Script 1.0이 출시되어 매우 기쁩니다!
안정판이 나왔으니 앞으로 보편화되는 추세겠죠.
타입 스크립트는 자바스크립트의 슈퍼 패키지다.
또한 Type Script는 정적 유형 언어입니다.
하지만 JavaScript는 동적 유형 언어입니다.따라서 Type Script에서 JavaScript의 기존 라이브러리를 안전하게 사용하려면 뒤에 유형 정보를 제공해야 합니다.
이른바 형식 정의 파일 (언어 규격상 declation source file) 이다.
이 유형의 정의 파일을 통합한 사이트는 DefinitelyTyped이다.
Definitely Type은 마이크로소프트의 공식 블로그에도 있다언급하다.
필자는 얼마 전부터 디피니터리 타입 팀.에 참가했고 주로 Definitely Type 창고의 테스트 인프라 시설의 유지보수와pull request의 심사와 도입을 맡았다.
이에 따라 Definitely Type에 pull request를 보내는 방법은 일본에서 온 사이트를 늘리기 위한 것이라고 설명했다.

유형 정의 파일 사용


DefinitelyTyped에서 원하는 물건을 찾으면 일반적으로 다운로드해서 사용합니다.
페이지를 열고 t키를 누르면 선별 검색을 할 수 있습니다. 원하는 프로그램 라이브러리 이름을 입력하십시오.
유명한 곳은 보통 다 찾을 수 있어요.
일부 형식 정의 파일은 다른 형식 정의 파일을 인용할 수 있습니다.
예를 들어 jqueryui.d.tsjquery.d.ts에 의존한다.
그래서 jqueryui.d.ts를 사용하고 싶은 경우 jquery.d.ts도 함께 다운로드해야 합니다.
다운로드한 유형 정의 파일의 저장 목표는 typings 폴더를 만드는 것이고 거기에 놓는 모델이 주류가 되었다.
jquery.d.ts와 jquery.d.ts의 관계를 바꾸지 않기 위해서, 예를 들어 다음과 같은 설정을 사용합니다.
.
└── typings
    ├── jquery
    │   └── jquery.d.ts
    └── jqueryui
        └── jqueryui.d.ts
손으로 다운로드하는 게 귀찮다면 tsd쓰세요.
npm과 bower와 부명령의 체계가 상당히 다르기 때문에 README(누가 일본어 소개 기사를 썼는지-)를 잘 읽어주세요.
이전의 일과 같은 일을 해야 한다tsd query jqueryui --resolve --save --action install.
이렇게 되면, jquery.d.ts와 jqueryui.d.ts는 위의 구조를 유지한 상태에서 다운로드됩니다.

유형 정의 파일 만들기


자세한 설명은 번거롭기 때문에 유형 정의 파일을 직접 만드는 방법은 상세하게 설명하지 않는다.
DefinitelyTyped에 이미 존재하는 형식 정의 파일을 보고 나도 모르게 알아차렸다.
대략적으로 말하면 모듈, 클래스, 함수와 변수를 발표할 때 맨 윗부분의 요소는 키워드declare만 추가하면 된다.
아니면 Type Script로 GAWA만 쓰고 tsc --declaration hoge.ts하면 hoge.d.ts가 생성되었기 때문에 그것을 기본적으로 가볍게 합시다.
만약 정말 곤란하다면, 트위터의 #typescriptjp 테마 태그에 넣으면 지지를 받을 수 있을 것이다.

pull request 보내주세요.


제작된 형식 정의 파일은pull request를 Definitely Type 창고에 적극적으로 보내야 합니다.
GiitHub의 사용법을 알고 영어도 읽을 수 있는 사람은 한마디How to contribute를 읽고 꺼내세요.됐어요.
우선 GiitHub의 사용법을 알고 영어를 잘 못하는 사람을 위한 해설을 써야 한다.

pull request 보내기 전의 검사 요점


주의사항: 이 해설은 위키2014년04월04시를 바탕으로 쓴 것이다.
직역이 아니라 젊은이들의 최선의 실천을 쓴다.

새 형식 정의 파일을 추가할 때


릴리즈
라이브러리의 최신 버전만 유지하기 때문에 파일 이름에 버전 번호를 포함하지 않습니다.
커뮤니티가 여러 프로그램 라이브러리 버전을 지속적으로 유지하지 못하는 체력 때문이다.
그나저나 아무도 하기 싫겠지.
편지봉투를 붙이다
  • 유형 정의 파일의 시작 부분에 머리글을 추가합니다.
  • // Type definitions for [LIBRARY NAME]
    // Project: [LIBRARY URL]
    // Definitions by: [AUTHOR NAME] <[AUTHOR URL]>
    // Definitions: https://github.com/borisyankov/DefinitelyTyped
    
    실제 예는 이런 느낌.
    // Type definitions for Backbone 0.9.10
    // Project: http://backbonejs.org/
    // Definitions by: Boris Yankov <https://github.com/borisyankov/>
    // Definitions: https://github.com/borisyankov/DefinitelyTyped
    
    라이브러리 배치 위치
    jQuery라는 라이브러리의 형식 정의 파일이면 jquery 폴더를 만듭니다.d.ts의 이름으로 배치합니다.
    JSDc 쓰기
    힘내서 써.그러나 미역은 JSDoc가 효과적으로 활용할 수 있는 환경에서 일하지 않기 때문에 그다지 중시하지 않습니다.
    시험 쓰세요.
    형식 정의 파일에 대한 테스트를 작성하십시오.좋은 문서를 대체할 수도 있다.
    hoge.d.ts라는 형식 정의 파일을 만든 경우hoge-tests.ts 파일 만들기d.ts의 사용 예를 쓰십시오.
    hoge-tests.ts는 '동작' 코드가 필요하지 않습니다.번역이 통과되었는지 확인할 수 있었으면 좋겠어요.
    DefinitelyType 창고가 Travis-II 테스트 중입니다.형식 정의 파일을 tsc에서 성공적으로 컴파일해야 합니다. 옵션인 noImplicitany가 있습니다.
    한 마디로 하면pullrequest가 발송되기 전에 확인tsc --noImplicitAny hoge/hoge.d.tstsc --noImplicitAny hoge/hoge-tests.ts 통과.
    네임스페이스 사용 방법
    다른 프로그램 라이브러리와 충돌하지 않도록 내부 모듈을 잘 사용하세요.
    README.MD에 이름 써주세요.
    README.md에 이름을 추가합니다.
    형식은 * [LIBRARY NAME WITH LINK] (by [AUTHOR NAME WITH LINK])입니다.기존에 있는 것을 모방하여 쓰세요.
    CONTRIBUTORS.MD에 이름을 추가하는 운용이지만 매번 지적할 때마다 상당히 번거롭다반자동 생성.

    기존 유형 정의 파일을 수정할 때


    어쨌든 - noImplicitany 옵션이 있는 컴파일링이 통과하면 OK입니다.
    영향을 끼친 서류가 커 보이면npm update && npm run all 중 하나도 환불하지 않으면 괜찮아요.

    pull request를 보낼 때의 검사 요점


    Definitely Type에 pull request를 보낼 때 영어로 보냅니다.
    단, 약속에 포함된 변경점이 좋으면pullrequest를 보낼 때 제목과 개요가 잘 맞아도 상관없습니다.
    극단적으로 형식 정의 파일add hoge/hoge.d.ts의 제목이 개요 공백 표시줄이 추가되면, 업데이트된 경우update hoge/hoge.d.ts의 제목이 개요 공백 표시줄이면 문제가 없다.
    리뷰할 때 유용하기 때문에 기존 정의를 수정할 때 변경점이 정말 정확한 문서와 소스 코드임을 확인할 수 있는 URL이 있다면 기쁠 것이다.
    없어도 돼. 여기서 조사 안 해도 돼.
    토론으로 발전하면 Google 번역을 활용하거나 GiitHub에 @vvakame 라고 적어서 부르면 Google 번역: P

    pull request 발송 후 검사 요점


    pull request를 보내면 Travis-CI가 자동으로 테스트를 테스트하고 실행합니다.
    결과는 실패로 인해 빨개질 수 있으므로pull request를 보낸 후 잠시 후에 페이지를 다시 불러와서 결과를 확인하는 것이 좋습니다.
    pull request를 보내면merge를 할 수 있는 권한이 없기 때문에 아래 캡처와는 조금 다른 상태로 표시됩니다. 참고할 수 있습니다.
    Travis-CI 반응 전.

    Travis-CI에서 반응 테스트를 진행 중입니다.

    Travis-CI 테스트에 성공한 상태입니다.

    그리고 댓글이 올라와서 합병만 기다렸어요!
    테스트에 실패하거나 시청자가 지적하면 추가 제출을 만들고 같은 지점에서push를 사용하여pullrequest에 자동으로 반영합니다.
    pull request를 다시 만들 필요가 없습니다.

    GiitHub pull request 만드는 법


    그리고 새로운 지점을 적당히 잘라서 제출한 후 자신의 창고에 보관하세요.
    GiitHub의 지점이 증가했는지 확인하세요.

    창고의 첫 페이지에는 pull request를 보내는 UI가 있어야 합니다.

    보내기 전의 변경 사항을 확인합니다.

    최후


    그럼, 즐거운 생활 되세요!
    GiitHub에 대해 더 알고 싶은 경우 최근에 출판된 GiitHub 실습 시작책이 평가가 좋다고 들었습니다(저는 서서 읽기만 합니다:P).

    좋은 웹페이지 즐겨찾기