พื้นที่เก็บข้อมูลสำหรับคำจำกัดความประเภท TypeScript คุณภาพสูง
คุณยังสามารถอ่าน README นี้ได้ในภาษา Español, เกาหลี, Русский, 简体中文, Português, Italiano, 日本語 และ Français!
ลิงค์ไปยังคู่มือผู้ดูแลระบบ
Typed แน่นอนเพิ่งเปลี่ยนเป็น monorepo pnpm ที่เหมาะสม คุณอาจต้องการอ่านเอกสารนี้อีกครั้งเพื่อดูการเปลี่ยนแปลงเค้าโครงของแพ็คเกจใน repo นี้
อย่างน้อยที่สุดคุณอาจต้องการ git clean -fdx the repo (หรือ node ./scripts/clean-node-modules.js บน Windows) เพื่อล้าง node_modules และรัน pnpm install --filter . เพื่อติดตั้งรูทเวิร์กสเปซ ดูส่วนเพิ่มเติมสำหรับข้อมูลเพิ่มเติมเกี่ยวกับ pnpm install
ส่วนนี้จะติดตามความสมบูรณ์ของพื้นที่เก็บข้อมูลและกระบวนการเผยแพร่ อาจเป็นประโยชน์สำหรับผู้มีส่วนร่วมที่ประสบปัญหาใดๆ กับการประชาสัมพันธ์และแพ็คเกจของตน
หากมีสิ่งใดที่นี่ดูเหมือนผิดปกติหรือข้อใดข้อหนึ่งข้างต้นล้มเหลว โปรดแจ้งให้เราทราบในช่องของประเภทที่แน่นอนบนเซิร์ฟเวอร์ Discord ของชุมชน TypeScript
ดูคู่มือ TypeScript
นี่เป็นวิธีที่ต้องการ ตัวอย่างเช่น:
npm install --save-dev @types/node หากต้องการติดตั้งการพิมพ์สำหรับโมดูลที่กำหนดขอบเขต ให้ลบ @ และเพิ่มเครื่องหมายขีดล่างคู่หลังขอบเขต ตัวอย่างเช่น หากต้องการติดตั้งการพิมพ์สำหรับ @babel/preset-env :
npm install --save-dev @types/babel__preset-env คอมไพเลอร์ควรรวมประเภทต่างๆ ไว้โดยอัตโนมัติ คุณอาจต้องเพิ่มการอ้างอิง types หากคุณไม่ได้ใช้โมดูล:
/// <reference types="node" />ดูเพิ่มเติมในคู่มือ
สำหรับแพ็คเกจ npm "foo" การพิมพ์จะอยู่ที่ "@types/foo"
หากแพ็คเกจของคุณระบุการพิมพ์โดยใช้ types หรือคีย์ typings ใน package.json รีจิสทรี npm จะแสดงว่าแพ็คเกจมีการผูกที่พร้อมใช้งานดังนี้:
คุณสามารถโคลนพื้นที่เก็บข้อมูลทั้งหมดได้ตามปกติ แต่มีขนาดใหญ่และมีไดเร็กทอรีประเภทแพ็คเกจจำนวนมาก การโคลนจะใช้เวลาสักระยะและอาจยุ่งยากโดยไม่จำเป็น
สำหรับโคลนที่สามารถจัดการได้มากขึ้นซึ่งมี เฉพาะ แพ็คเกจประเภทที่เกี่ยวข้องกับคุณ คุณสามารถใช้คุณสมบัติ sparse-checkout และ --filter ของ git ได้ วิธีนี้จะช่วยลดเวลาการโคลนและปรับปรุงประสิทธิภาพของคอมไพล์
ต้องใช้คอมไพล์เวอร์ชันขั้นต่ำ 2.27.0 ซึ่งอาจใหม่กว่าค่าเริ่มต้นในเครื่องส่วนใหญ่ ขั้นตอนที่ซับซ้อนมากขึ้นมีอยู่ในเวอร์ชันเก่า แต่ไม่ครอบคลุมอยู่ในคู่มือนี้
git clone --sparse --filter=blob:none <forkedUrl>--sparse เตรียมข้อมูลเบื้องต้นให้กับไฟล์ sparse-checkout ดังนั้นไดเร็กทอรีการทำงานจะเริ่มต้นด้วยเฉพาะไฟล์ที่อยู่ในรูทของที่เก็บ--filter=blob:none จะรวมประวัติการคอมมิตทั้งหมด แต่ไม่รวมไฟล์ โดยดึงข้อมูลตามที่จำเป็นเท่านั้นgit sparse-checkout add types/<type> types/<dependency-type> ...pnpm test <package to test> เมื่อคุณสร้าง PR เพื่อแก้ไขแพ็คเกจที่มีอยู่ dt-bot ควร @-กล่าวถึงเจ้าของแพ็คเกจ หากไม่เป็นเช่นนั้น คุณสามารถทำได้ด้วยตนเองในความคิดเห็นที่เกี่ยวข้องกับ PR
หากคุณเป็นผู้เขียนไลบรารีและแพ็คเกจของคุณเขียนด้วย TypeScript ให้รวมไฟล์การประกาศที่สร้างขึ้นในแพ็คเกจของคุณแทนที่จะเผยแพร่ไปยังประเภทที่แน่นอน คุณยังสามารถสร้างไฟล์การประกาศจากไฟล์ JavaScript โดยใช้ JSDoc สำหรับคำอธิบายประกอบประเภท
หากคุณกำลังเพิ่มการพิมพ์สำหรับแพ็คเกจ npm ให้สร้างไดเร็กทอรีที่มีชื่อเดียวกัน หากแพ็คเกจที่คุณกำลังเพิ่มการพิมพ์ไม่ได้อยู่ในเวลา npm ตรวจสอบให้แน่ใจว่าชื่อที่คุณเลือกไม่ขัดแย้งกับชื่อของแพ็คเกจในเวลา npm (คุณสามารถใช้ npm info <my-package> เพื่อตรวจสอบการมีอยู่ของแพ็คเกจ <my-package> )
แพ็คเกจของคุณควรมีโครงสร้างนี้:
| ไฟล์ | วัตถุประสงค์ |
|---|---|
index.d.ts | ข้อมูลนี้มีการพิมพ์สำหรับแพ็คเกจ |
<my-package>-tests.ts | ประกอบด้วยโค้ดตัวอย่างซึ่งทดสอบการพิมพ์ รหัสนี้ ไม่ ทำงาน แต่มีการตรวจสอบประเภทแล้ว |
tsconfig.json | สิ่งนี้ทำให้คุณสามารถรัน tsc ภายในแพ็คเกจได้ |
.eslintrc.json | (ไม่ค่อยมี) จำเป็นเท่านั้นเพื่อปิดการใช้งานกฎผ้าสำลีที่เขียนสำหรับ eslint |
package.json | มีข้อมูลเมตาสำหรับแพ็คเกจ รวมถึงชื่อ เวอร์ชัน และการขึ้นต่อกัน |
.npmignore | ระบุไฟล์ที่ต้องการรวมไว้ในแพ็คเกจ |
สร้างสิ่งเหล่านี้โดยการรัน npx dts-gen --dt --name <my-package> --template module ดูตัวเลือกทั้งหมดที่ dts-gen
หากคุณมีไฟล์ .d.ts นอกเหนือจาก index.d.ts ให้แน่ใจว่าไฟล์เหล่านั้นมีการอ้างอิงใน index.d.ts หรือการทดสอบ
สมาชิก Typed จะติดตาม PR ใหม่เป็นประจำ แต่โปรดจำไว้ว่าจำนวน PR อื่นๆ อาจทำให้การดำเนินการช้าลง
สำหรับแพ็คเกจตัวอย่างที่ดี โปรดดูที่ base64-js
เมื่อแพ็คเกจรวมประเภทของตัวเอง ควรลบประเภทออกจากประเภทที่แน่นอนเพื่อหลีกเลี่ยงความสับสน
คุณสามารถลบมันออกได้โดยการรัน pnpm run not-needed <typingsPackageName> <asOfVersion> [<libraryName>]
<typingsPackageName> : นี่คือชื่อของไดเร็กทอรีที่จะลบ<asOfVersion> : stub จะถูกเผยแพร่ไปที่ @types/<typingsPackageName> ด้วยเวอร์ชันนี้ ควรสูงกว่าเวอร์ชันที่เผยแพร่ในปัจจุบัน และควรเป็นเวอร์ชันของ <libraryName> เวลา npm<libraryName> : ชื่อของแพ็คเกจ npm ที่แทนที่ประเภทที่พิมพ์แน่นอน โดยปกติแล้วจะเหมือนกับ <typingsPackageName> ซึ่งในกรณีนี้คุณสามารถละเว้นได้ หากแพ็คเกจไม่เคยอยู่ในประเภทที่แน่นอน ก็ไม่จำเป็นต้องเพิ่มแพ็คเกจนั้นใน notNeededPackages.json
ทดสอบการเปลี่ยนแปลงของคุณโดยการรัน pnpm test <package to test> โดยที่ <package to test> คือชื่อของแพ็คเกจของคุณ คุณต้องเรียกใช้สิ่งนี้จากไดเร็กทอรี SureTyped เนื่องจากแต่ละ package.jsons ไม่ได้กำหนดสคริปต์ทดสอบ
สคริปต์นี้ใช้ dtslint เพื่อเรียกใช้คอมไพเลอร์ TypeScript กับไฟล์ dts ของคุณ
เมื่อคุณมีการเปลี่ยนแปลงทั้งหมดพร้อมแล้ว ให้ใช้ pnpm run test-all เพื่อดูว่าการเปลี่ยนแปลงของคุณส่งผลต่อโมดูลอื่นๆ อย่างไร
attw ) dtslint มีรูปแบบโมดูลและการตรวจสอบการกำหนดค่า package.json จาก @arethetypeswrong/cli การตรวจสอบจะทำงานเฉพาะเมื่อสามารถพบแพ็คเกจการใช้งานที่เข้ากันได้กับ SemVer-major ได้ในเวลา npm เพื่อเปรียบเทียบกับแพ็คเกจ SureTyped (แพ็คเกจ DefinitelyTyped ที่ทำเครื่องหมายเป็น nonNpm ใน package.json จะถูกข้าม)
ปัจจุบันแพ็คเกจจำนวนมากไม่ผ่านการตรวจสอบ attw และจำเป็นต้องได้รับการแก้ไข เพื่อให้เราสามารถดำเนินการเพิ่มเติมได้ การตรวจสอบ attw ที่ล้มเหลวจะไม่ทำให้การรัน dtslint ล้มเหลวเมื่อแพ็กเกจอยู่ในรายการ failingPackages ใน attw.json แต่จะยังคงถูกรายงานในเอาต์พุต pnpm test my-package หากคุณแก้ไขแพ็กเกจ ให้ลบออกจาก failingPackages เพื่อให้การตรวจสอบ attw สามารถเริ่มต้นการรัน dtslint ที่ล้มเหลว
ปัญหาทั้งหมดที่รายงานโดย attw มีเอกสารเชื่อมโยงอยู่ในผลลัพธ์ กฎทั่วไปบางประการเพื่อช่วยหลีกเลี่ยงปัญหา:
package.json ในแพ็คเกจ SureTyped ต้องมี type ที่ตรงกันและช่อง exports หากแพ็คเกจการใช้งานใช้ใน package.json ตัวอย่างเช่น หากการใช้งาน package.json มีลักษณะดังนี้:
{
"name" : " my-package " ,
"version" : " 1.0.1 " ,
"type" : " module " ,
"main" : " dist/cjs/index.cjs " ,
"exports" : {
"." : {
"import" : " ./dist/esm/index.js " ,
"require" : " ./dist/cjs/index.cjs "
},
"./subpath" : {
"import" : " ./dist/esm/subpath.js " ,
"require" : " ./dist/cjs/subpath.cjs "
}
}
} ดังนั้น AbsoluteTyped package.json ควรมีลักษณะดังนี้:
{
"name" : "@types/my-package" ,
"version" : "1.0.9999" ,
"type" : "module" ,
"types" : "index.d.ts" ,
"exports" : {
"." : {
"import" : "./index.d.ts" ,
"require" : "./index.d.cts"
} ,
"./subpath" : {
"import" : "./subpath.d.ts" ,
"require" : "./subpath.d.cts"
}
}
} โปรดสังเกตว่าแต่ละเส้นทางย่อย exports จะสะท้อนให้เห็น และไฟล์ JavaScript แต่ละไฟล์มีไฟล์ประกาศที่เกี่ยวข้องซึ่งมีนามสกุลไฟล์ตรงกัน ไฟล์ .d.ts จะจัดประเภทเป็นไฟล์ .js ไม่ใช่ไฟล์ .mjs หรือ .cjs !
เมื่อแพ็คเกจการใช้งานใช้ module.exports = ... แพ็คเกจ AbsoluteTyped ควรใช้ export = ไม่ใช่ export default (หรืออีกทางหนึ่ง หาก module.exports เป็นเพียงออบเจ็กต์ของคุณสมบัติที่มีชื่อ แพ็คเกจ SureTyped สามารถใช้ชุดของการส่งออกที่มีชื่อได้) อุปสรรคที่พบบ่อยที่สุดในการแก้ไขปัญหานี้คือความสับสนเกี่ยวกับวิธีการส่งออกประเภทนอกเหนือจากการส่งออกหลัก ตัวอย่างเช่น สมมติว่าประเภทเหล่านี้ใช้ export default ไม่ถูกต้อง :
export interface Options {
// ...
}
export default function doSomething ( options : Options ) : void ; การเปลี่ยน export default เป็นการ export = สร้างข้อผิดพลาด:
export interface Options {
// ...
}
declare function doSomething ( options : Options ) : void ;
export = doSomething ;
// ^^^^^^^^^^^^^^^^^
// Error: An export assignment cannot be used in a module with other exported elements.เพื่อแก้ไขปัญหานี้ ให้ย้ายประเภทภายในเนมสเปซที่มีชื่อเดียวกันกับฟังก์ชัน:
declare namespace doSomething {
export interface Options {
// ...
}
}
declare function doSomething ( options : doSomething . Options ) : void ;
export = doSomething ;หากคุณต้องการความช่วยเหลือในการแก้ไขปัญหา โปรดถามในช่องของ IndeedTyped บนเซิร์ฟเวอร์ Discord ของชุมชน TypeScript
หากคุณกำลังเพิ่มการพิมพ์สำหรับแพ็คเกจ npm ให้สร้างไดเร็กทอรีที่มีชื่อเดียวกัน หากแพ็คเกจที่คุณกำลังเพิ่มการพิมพ์ไม่ได้อยู่ใน npm ให้ตั้งค่า "nonNpm": true ใน package.json และตรวจสอบให้แน่ใจว่าชื่อที่คุณเลือกไม่ขัดแย้งกับชื่อของแพ็คเกจในเวลา npm (คุณสามารถใช้ npm info <my-package> เพื่อตรวจสอบการมีอยู่ของแพ็คเกจ <my-package> )
ในบางกรณีที่เกิดขึ้นไม่บ่อยนัก nonNpm อาจถูกตั้งค่าเป็น "conflict" ซึ่งระบุว่ามีแพ็คเกจบน npm ที่มีชื่อเดียวกัน แต่ประเภทนั้นจงใจขัดแย้งกับแพ็คเกจนั้น สิ่งนี้อาจเป็นจริงสำหรับแพ็คเกจที่กำหนดสภาพแวดล้อม เช่น @types/node หรือสำหรับแพ็คเกจจำลอง เช่น aws-lambda หลีกเลี่ยงการใช้ "conflict" หากเป็นไปได้
<my-package>-tests.ts ควรมีไฟล์ <my-package>-tests.ts ซึ่งถือเป็นไฟล์ทดสอบของคุณ พร้อมด้วยไฟล์ *.ts ใดๆ ที่ไฟล์นั้นนำเข้า หากคุณไม่เห็นไฟล์ทดสอบใดๆ ในโฟลเดอร์ของโมดูล ให้สร้าง <my-package>-tests.ts ไฟล์เหล่านี้ใช้เพื่อตรวจสอบความถูกต้องของ API ที่ส่งออกจากไฟล์ *.d.ts ซึ่งจัดส่งเป็น @types/<my-package> พวกเขาไม่ได้จัดส่งเอง
การเปลี่ยนแปลงไฟล์ *.d.ts ควรรวมการเปลี่ยนแปลงไฟล์ *.ts ที่เกี่ยวข้องซึ่งแสดง API ที่ใช้งานอยู่ เพื่อไม่ให้ผู้อื่นทำลายโค้ดที่คุณพึ่งพาโดยไม่ได้ตั้งใจ ตัวอย่างเช่น การเปลี่ยนแปลงฟังก์ชันในไฟล์ .d.ts โดยเพิ่มพารามิเตอร์ใหม่ให้กับฟังก์ชัน:
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("//", { })หากคุณสงสัยว่าจะเริ่มต้นด้วยโค้ดทดสอบจากที่ใด ตัวอย่างใน README ของแพ็คเกจดั้งเดิมถือเป็นจุดเริ่มต้นที่ดี
คุณสามารถตรวจสอบการเปลี่ยนแปลงของคุณด้วย npm test <package to test> จากรากของ repo นี้ ซึ่งจะคำนึงถึงไฟล์ที่เปลี่ยนแปลง
ใช้ $ExpectType เพื่อยืนยันว่านิพจน์เป็นประเภทที่กำหนด และ @ts-expect-error เพื่อยืนยันว่าเป็นข้อผิดพลาดในการคอมไพล์ ตัวอย่าง:
// $ExpectType void
f ( 1 ) ;
// @ts-expect-error
f ( "one" ) ;สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ dtslint readme
.eslintrc.jsonหากจำเป็นต้องปิดการใช้งานกฎ Lint ด้วยเหตุผลบางประการ ให้ปิดการใช้งานสำหรับบรรทัดใดบรรทัดหนึ่ง:
// eslint-disable-next-line no-const-enum
const enum Const {
One ,
}
const enum Enum { // eslint-disable-line no-const-enum
Two ,
}คุณยังคงสามารถปิดการใช้งานกฎด้วย .eslintrc.json ได้ แต่ไม่ควรอยู่ในแพ็คเกจใหม่ การปิดใช้งานกฎสำหรับแพ็คเกจทั้งหมดทำให้ยากต่อการตรวจสอบ
tsconfig.json tsconfig.json ควรมีการตั้งค่า noImplicitAny , noImplicitThis , strictNullChecks และ strictFunctionTypes เป็น true
คุณสามารถแก้ไข tsconfig.json เพื่อเพิ่มไฟล์ทดสอบใหม่ เพื่อเพิ่ม "target": "es6" (จำเป็นสำหรับฟังก์ชัน async) เพื่อเพิ่มลงใน "lib" หรือเพื่อเพิ่มตัวเลือกคอมไพเลอร์ "jsx"
esModuleInterop / allowSyntheticDefaultImports TL; DR: esModuleInterop และ allowSyntheticDefaultImports ไม่ได้รับอนุญาต ใน tsconfig.json ของคุณ
ตัวเลือกเหล่านี้ทำให้สามารถเขียนการนำเข้าเริ่มต้นสำหรับการส่งออก CJS โดยสร้างแบบจำลองความสามารถในการทำงานร่วมกันในตัวระหว่างโมดูล CJS และ ES ใน Node และในบันเดิล JS บางตัว:
// component.d.ts declare class Component { } // CJS export, modeling `module.exports = Component` in JS export = Component ; // index.d.ts // ESM default import, only allowed under 'esModuleInterop' or 'allowSyntheticDefaultExports' import Component from "./component" ;เนื่องจากความถูกต้องเวลาคอมไพล์ของการนำเข้าใน
index.d.tsขึ้นอยู่กับการตั้งค่าการคอมไพล์เฉพาะ ซึ่งผู้ใช้ประเภทของคุณไม่ได้รับการสืบทอด การใช้รูปแบบนี้ใน SureTyped จะบังคับให้ผู้ใช้เปลี่ยนการตั้งค่าการคอมไพล์ของตนเอง ซึ่งอาจไม่ถูกต้อง สำหรับรันไทม์ของพวกเขา คุณต้องเขียนการนำเข้า CJS สำหรับการส่งออก CJS แทน เพื่อให้แน่ใจว่ามีความเข้ากันได้อย่างกว้างขวางและเป็นอิสระจากการกำหนดค่า:// index.d.ts // CJS import, modeling `const Component = require("./component")` in JS import Component = require ( "./component" ) ;
package.jsonไฟล์นี้จำเป็นและควรเป็นไปตามเทมเพลตนี้:
{
"private" : true ,
"name" : "@types/PACKAGE-NAME" ,
"version" : "1.2.9999" ,
"projects" : [
"https://aframe.io/"
] ,
"dependencies" : {
"@types/DEPENDENCY-1" : "*" ,
"@types/DEPENDENCY-2" : "*"
} ,
"devDependencies" : {
"@types/PACKAGE-NAME" : "workspace:."
} ,
"owners" : [
{
"name" : "Your Name Here" ,
"githubUsername" : "ghost"
}
]
} package.json ระบุการขึ้นต่อกัน ทั้งหมด รวมถึงแพ็คเกจ @types อื่นๆ
คุณต้องเพิ่มการขึ้นต่อกันที่ไม่ใช่ @types ลงในรายการการขึ้นต่อกันภายนอกที่อนุญาต พิคาเดย์เป็นตัวอย่างที่ดี ส่วนเพิ่มเติมเหล่านี้ได้รับการอนุมัติจากผู้ดูแล ซึ่งเปิดโอกาสให้เราตรวจสอบให้แน่ใจว่าแพ็คเกจ @types ไม่ได้ขึ้นอยู่กับแพ็คเกจที่เป็นอันตราย
หากแพ็คเกจการใช้งานใช้ ESM และระบุ "type": "module" คุณควรแก้ไข package.json ให้ตรงกัน:
{
"type" : " module "
} นอกจากนี้ยังใช้หากแพ็คเกจการใช้งานมี exports ใน package.json
Typed อนุญาต peerDependencies ใน package.json แน่นอน การพึ่งพาเพียร์สามารถช่วยป้องกันสถานการณ์ที่ตัวจัดการแพ็คเกจติดตั้งเวอร์ชันใหม่เกินไปหรือแพ็คเกจเดียวกันมากกว่าหนึ่งเวอร์ชันโดยไม่คาดคิด อย่างไรก็ตาม การพึ่งพาเพื่อนก็มีข้อเสีย ผู้จัดการแพ็คเกจแตกต่างกันในการจัดการการพึ่งพาเพียร์ (เช่น yarn ไม่ได้ติดตั้งโดยอัตโนมัติ npm ต้องการ --legacy-peer-deps สำหรับความไม่ตรงกัน) ด้วยเหตุนี้ PR ที่แนะนำการพึ่งพาเพียร์ใหม่ต้องได้รับอนุมัติจากผู้ดูแล และควรจำกัดไว้ตามสถานการณ์เฉพาะ
โดยทั่วไป แพคเกจประเภทควรมีการพึ่งพาเพียร์เท่านั้น หากแพ็คเกจอัปสตรีมมีการพึ่งพาเพียร์ในแพ็คเกจเดียวกัน (หรือประเภทของแพ็คเกจ) ตัวอย่างเช่น แพ็คเกจ DT สำหรับส่วนประกอบ React สามารถระบุการพึ่งพาเพียร์บน @types/react@* เนื่องจากผู้บริโภคจะต้องติดตั้ง @types/react เพื่อใช้ JSX ตั้งแต่แรก หากผู้บริโภคติดตั้ง @types/react@16 ในโปรเจ็กต์ของตน แต่ @types/react เวอร์ชันใหม่กว่านั้นพร้อมใช้งานในเวลา npm การพึ่งพาเพียร์อาจช่วยให้ผู้จัดการแพ็คเกจเลือก @types/react@16 แทนที่จะเป็นเวอร์ชันที่ใหม่กว่านั้น ในทำนองเดียวกัน chai-as-promised มีการพึ่งพาเพื่อนใน chai ดังนั้น @types/chai-as-promised ควรมีการอ้างอิงเพื่อนใน @types/chai
มีบางกรณีที่แพ็คเกจอัพสตรีมไม่มีการพึ่งพาเพียร์กับแพ็คเกจประเภท แต่การพึ่งพาเพียร์ยังคงเหมาะสม โดยทั่วไปจะเป็นกรณีที่แพ็คเกจอัพสตรีมขยายแพ็คเกจอื่นและถือว่ามีอยู่ ดังนั้น ควร ได้ประกาศการพึ่งพาเพียร์ในขณะที่ขยายแพ็คเกจอื่น แต่ไม่ได้ทำ ตัวอย่างเช่น chai-match-pattern ขยาย chai แต่ไม่ได้ประกาศการพึ่งพาเพียร์บน chai แต่ต้องการให้มันทำงาน @types/chai-match-pattern ควรมีการพึ่งพาเพื่อน @types/chai
หากแพ็คเกจเปิดเผยประเภทจากแพ็คเกจอื่นโดยเป็นส่วนหนึ่งของ API เนื่องจากการขึ้นต่อกันปกติในแพ็คเกจอัพสตรีม ก็ ไม่ควร ใช้การขึ้นต่อกันแบบเพียร์ ตัวอย่างเช่น express มี qs อยู่ใน "dependencies" เมื่อผู้ใช้ติดตั้ง express พวกเขาไม่จำเป็นต้องติดตั้ง qs ด้วยตนเอง ในทำนองเดียวกัน @types/express มี @types/qs ใน "dependencies" การประกาศ @types/qs เป็นการพึ่งพาเพียร์ของ @types/express จะไม่ถูกต้อง เนื่องจากจะต้องให้ผู้บริโภคดาวน์สตรีมบางรายติดตั้ง @types/qs ด้วยตนเอง
.npmignore ไฟล์นี้กำหนดไฟล์ที่จะรวมไว้ในแพ็คเกจ @types แต่ละแพ็คเกจ มันจะต้องมีรูปแบบเฉพาะ สำหรับแพ็คเกจที่มีเวอร์ชันเดียวใน repo:
*
! ** / * .d.ts
! ** / * .d.cts
! ** / * .d.mts
! ** / * .d. * .tsซึ่งก็คือ "ละเว้นไฟล์ทั้งหมด แต่อย่าเพิกเฉยต่อไฟล์ประกาศใดๆ" สำหรับแพ็คเกจที่มีมากกว่าหนึ่งเวอร์ชันใน repo เวอร์ชัน "ล่าสุด" (ที่ระดับบนสุด) ควรมีดังต่อไปนี้:
*
! ** / * .d.ts
! ** / * .d.cts
! ** / * .d.mts
! ** / * .d. * .ts
/ v15 /
/ v16 /
/ v17 / ซึ่งเหมือนกับ .npmignore ก่อนหน้า แต่ไม่สนใจไดเรกทอรีย่อยแต่ละเวอร์ชัน
CI จะล้มเหลวหากไฟล์นี้มีเนื้อหาที่ไม่ถูกต้องและระบุค่าที่ต้องการ ไม่ว่าไฟล์นี้จะประกอบด้วยอะไร ผู้เผยแพร่จะเผยแพร่เฉพาะไฟล์การประกาศเท่านั้น
pnpm dprint fmt -- 'path/to/package/**/*.ts' ได้.vscode/settings.template.json (หรือเทียบเท่าสำหรับโปรแกรมแก้ไขอื่นๆ) เพื่อจัดรูปแบบในการบันทึกด้วยส่วนขยาย VS Code dprintfunction sum(nums: number[]): number : ใช้ ReadonlyArray หากฟังก์ชันไม่ได้เขียนลงในพารามิเตอร์interface Foo { new(): Foo; } : นี่เป็นการกำหนดประเภทของออบเจ็กต์ที่สามารถทำได้ใหม่ คุณอาจต้องการ declare class Foo { constructor(); } .const Class: { new(): IClass; } : ต้องการใช้ class Class { constructor(); } แทนค่าคงที่ที่สามารถทำได้ใหม่getMeAT<T>(): T : หากพารามิเตอร์ type ไม่ปรากฏในประเภทของพารามิเตอร์ใด ๆ แสดงว่าคุณไม่มีฟังก์ชันทั่วไปจริงๆ คุณเพียงแค่มีการยืนยันประเภทปลอมตัว ต้องการใช้การยืนยันประเภทจริง เช่น getMeAT() as number ตัวอย่างที่ยอมรับพารามิเตอร์ประเภทได้: function id<T>(value: T): T; - ตัวอย่างที่ไม่สามารถยอมรับได้: function parseJson<T>(json: string): T; - ข้อยกเว้น: new Map<string, number>() ใช้ได้Function และ Object แทบจะไม่ใช่ความคิดที่ดีเลย ใน 99% ของกรณี สามารถระบุประเภทที่เฉพาะเจาะจงมากขึ้นได้ ตัวอย่าง ได้แก่ (x: number) => number สำหรับฟังก์ชัน และ { x: number, y: number } สำหรับอ็อบเจ็กต์ หากไม่มีความแน่นอนเกี่ยวกับประเภทใดเลย ตัวเลือก any ถูกต้อง ไม่ใช่ Object หากข้อเท็จจริงที่ทราบเพียงอย่างเดียวเกี่ยวกับประเภทนี้คือเป็นวัตถุบางอย่าง ให้ใช้ประเภท object ไม่ใช่ Object หรือ { [key: string]: any }var foo: string | any : เมื่อ any ถูกใช้ในประเภทยูเนี่ยน ประเภทผลลัพธ์จะยังคง any ดังนั้น แม้ว่าส่วน string ของคำอธิบายประกอบประเภทนี้อาจ ดู มีประโยชน์ แต่จริงๆ แล้วไม่มีการตรวจสอบประเภทเพิ่มเติมใดๆ เพียงแค่ใช้ any . ทางเลือกอื่นที่ยอมรับได้อาจ any , string หรือ string | object ทั้งนี้ขึ้นอยู่กับความตั้งใจ string | object .TL; DR: ห้ามแก้ไข
.github/CODEOWNERSให้แก้ไขรายชื่อเจ้าของในpackage.jsonเสมอ
DT มีแนวคิด "Definition Owners" ซึ่งเป็นผู้ที่ต้องการรักษาคุณภาพของโมดูลประเภทใดประเภทหนึ่งโดยเฉพาะ
หากต้องการเพิ่มตัวคุณเองเป็นเจ้าของคำจำกัดความ ให้แก้ไขอาร์เรย์ owners ใน package.json :
"owners" : [
{
"name" : " Some Person " ,
"githubUsername" : " somebody "
},
{
"name" : " Some Corp " ,
"url" : " https://example.org "
}
]โปรดทราบว่ารายการนี้ ไม่ได้ ใช้เพื่อให้เครดิตสำหรับการบริจาค ใช้สำหรับจัดการรีวิว PR เท่านั้น
สัปดาห์ละครั้ง เจ้าของคำจำกัดความจะซิงค์กับไฟล์ .github/CODEOWNERS ซึ่งเป็นแหล่งที่มาของความจริงของเรา
Typed แน่นอนเป็นหนึ่งในแหล่งเก็บข้อมูลที่มีการใช้งานมากที่สุดบน GitHub คุณอาจสงสัยว่าโครงการนี้เกิดขึ้นได้อย่างไร @johnnyreilly เขียนประวัติของ Absolute Typed มันบอกเล่าเรื่องราวของช่วงแรกๆ ของ Indeed Typed จากพื้นที่เก็บข้อมูลที่สร้างโดย @borisyankov จนถึงจุดที่กลายเป็นส่วนสำคัญของระบบนิเวศของ TypeScript คุณสามารถอ่านเรื่องราวของ Sure Typed ได้ที่นี่
@types บน npm คืออะไร? สาขา master จะถูกเผยแพร่โดยอัตโนมัติไปยังขอบเขต @types เวลา npm ด้วยเครื่องมือ SureTyped
ขึ้นอยู่กับว่าคำขอดึงส่วนใหญ่จะถูกรวมเข้าด้วยกันภายในหนึ่งสัปดาห์ เจ้าของโมดูลสามารถรวม PR บางตัวเข้าด้วยกันได้ และสามารถรวมได้เร็วกว่ามาก ประมาณ:
PR ที่เปลี่ยนเฉพาะประเภทของโมดูลและมีการเปลี่ยนแปลงการทดสอบที่เกี่ยวข้องจะถูกรวมเข้าด้วยกันเร็วขึ้นมาก
PR ที่ได้รับการอนุมัติโดยเจ้าของที่แสดงอยู่ใน package.json ของคำจำกัดความมักจะถูกรวมเข้าด้วยกันเร็วกว่า การประชาสัมพันธ์สำหรับคำจำกัดความใหม่จะใช้เวลามากขึ้นเนื่องจากต้องมีการตรวจสอบเพิ่มเติมจากผู้ดูแล PR แต่ละรายการจะได้รับการตรวจสอบโดยสมาชิกในทีม TypeScript หรือ Surely Typed ก่อนที่จะรวมเข้าด้วยกัน ดังนั้นโปรดอดทนรอเนื่องจากปัจจัยด้านมนุษย์อาจทำให้เกิดความล่าช้า ตรวจสอบกระดานสถานะคำขอดึงข้อมูลใหม่เพื่อดูความคืบหน้าในขณะที่ผู้ดูแลทำงานผ่าน PR แบบเปิด
สำหรับการเปลี่ยนแปลงโมดูลยอดนิยม เช่น Node/Express/Jest ซึ่งมีการดาวน์โหลดหลายล้านครั้งต่อสัปดาห์ในเวลา npm ข้อกำหนดสำหรับการสนับสนุนจะสูงขึ้นเล็กน้อย การเปลี่ยนแปลงโครงการเหล่านี้อาจมีผลกระทบต่อระบบนิเวศอย่างมาก ดังนั้นเราจึงปฏิบัติต่อการเปลี่ยนแปลงเหล่านั้นด้วยความเอาใจใส่เป็นอย่างมาก โมดูลเหล่านี้ต้องการทั้งการลงนามจากผู้ดูแล DT และการสนับสนุนจากเจ้าของโมดูลอย่างกระตือรือร้น เกณฑ์ในการผ่านบอลอาจค่อนข้างสูง และบ่อยครั้งที่ PR อาจจืดชืดเนื่องจากไม่มีแชมป์ หากคุณพบว่าไม่มีใครมุ่งมั่น พยายามทำให้ PR ของคุณมีจุดสนใจที่เล็กลง
@types npm จะได้รับการอัปเดตเมื่อใดแพ็คเกจ npm ควรอัปเดตภายในหนึ่งชั่วโมง หากใช้เวลานานกว่าหนึ่งชั่วโมง ให้พูดถึงหมายเลข PR บนช่องที่พิมพ์แน่นอนบนเซิร์ฟเวอร์ Discord ของชุมชน TypeScript และผู้ดูแลคนปัจจุบันจะได้รับสมาชิกในทีมที่ถูกต้องเพื่อทำการตรวจสอบ
<reference types="" /> หรือนำเข้า หากโมดูลที่คุณกำลังอ้างอิงเป็นโมดูล (ใช้ export ) ให้ใช้การนำเข้า หากโมดูลที่คุณกำลังอ้างอิงเป็นโมดูลแอมเบียนต์ (ใช้ declare module ) หรือเพียงแค่ประกาศ globals ให้ใช้ <reference types="" />
tsconfig.json ที่ไม่มี "noImplicitAny": true , "noImplicitThis": true หรือ "strictNullChecks": trueแล้วพวกเขาก็ผิดและเรายังไม่ได้สังเกตเลย คุณสามารถช่วยได้โดยส่งคำขอดึงเพื่อแก้ไข
ใช่ ใช้ dprint เราขอแนะนำให้ใช้ส่วนขยาย dprint สำหรับโปรแกรมแก้ไขของคุณ
หรือคุณสามารถเปิดใช้งาน git hook ซึ่งจะจัดรูปแบบโค้ดของคุณโดยอัตโนมัติ เรียกใช้ pnpm run setup-hooks จากนั้นเมื่อคุณคอมมิต คำสั่ง dprint fmt จะถูกดำเนินการกับไฟล์ที่ถูกเปลี่ยนแปลง หากคุณใช้ประโยชน์จากการโคลนบางส่วน อย่าลืมเรียก git sparse-checkout add .husky เพื่อตรวจสอบ git hooks ก่อนที่จะรันสคริปต์ setup-hooks
คำขอพุลไม่จำเป็นต้องรวมการจัดรูปแบบที่ถูกต้อง โค้ดที่ไม่ได้ฟอร์แมตจะถูกฟอร์แมตใหม่โดยอัตโนมัติหลังจากรวมเข้าด้วยกัน
หากคุณเป็นผู้ใช้ VS Code เราขอแนะนำให้คัดลอกไฟล์
.vscode/settings.template.jsonไปที่.vscode/settings.jsonเทมเพลตนั้นตั้งค่าส่วนขยาย dprint VS Code เป็นตัวจัดรูปแบบเริ่มต้นใน repo
นี่คือคำจำกัดความที่ร้องขอในปัจจุบัน
หากประเภทเป็นส่วนหนึ่งของมาตรฐานเว็บ ควรสนับสนุน TypeScript-DOM-lib-generator เพื่อให้สามารถเป็นส่วนหนึ่งของค่าเริ่มต้น lib.dom.d.ts
หากไม่มีซอร์สโค้ด JavaScript เลย เช่น หากคุณกำลังเขียนประเภทตัวช่วยหรือประเภทสำหรับข้อมูลจำเพาะ คุณควรเผยแพร่ประเภทดังกล่าวด้วยตนเอง ไม่ใช่ในประเภทที่แน่นอน เนื่องจากมีไว้เพื่อจัดเตรียมประเภทสำหรับโค้ด JavaScript ที่มีอยู่ แพ็คเกจ @types จึงไม่ได้ถูกกำหนดให้นำเข้าโดยตรง นั่นคือคุณไม่ควรสร้างแพ็คเกจที่พิมพ์แน่นอนซึ่งมีไว้เพื่อใช้เช่น import type { ... } from "@types/foo" คุณไม่ควรคาดหวังที่จะเขียน import type { ... } from "foo" เมื่อไม่มีการติดตั้ง foo
สิ่งนี้แตกต่างจากการระบุประเภทสำหรับเบราว์เซอร์เฉพาะไลบรารี JavaScript หรือประเภทสำหรับสภาพแวดล้อมทั้งหมด เช่น โหนด บุญ และอื่นๆ ที่นั่น ประเภทต่างๆ จะได้รับการแก้ไขโดยปริยายหรือใช้ /// <references types="foo" />
แพ็กเกจบางอย่าง เช่น chai-http จะส่งออกฟังก์ชัน
การนำเข้าโมดูลนี้ด้วยการนำเข้าสไตล์ ES6 ในแบบฟอร์ม import * as foo from "foo"; นำไปสู่ข้อผิดพลาด:
ข้อผิดพลาด TS2497: โมดูล 'foo' แก้ไขเป็นเอนทิตีที่ไม่ใช่โมดูล และไม่สามารถนำเข้าโดยใช้โครงสร้างนี้
ข้อผิดพลาดนี้สามารถระงับได้โดยการรวมการประกาศฟังก์ชันเข้ากับเนมสเปซว่างที่มีชื่อเดียวกัน แต่ไม่สนับสนุนแนวทางปฏิบัตินี้ นี่เป็นคำตอบของ Stack Overflow ที่อ้างถึงโดยทั่วไปเกี่ยวกับเรื่องนี้
เหมาะสมกว่าในการนำเข้าโมดูลโดยใช้ import foo = require("foo"); ไวยากรณ์ อย่างไรก็ตาม หากคุณต้องการใช้การนำเข้าเริ่มต้น เช่น import foo from "foo"; คุณมีสองทางเลือก:
--allowSyntheticDefaultImports หากรันไทม์โมดูลของคุณรองรับรูปแบบการทำงานร่วมกันสำหรับโมดูลที่ไม่ใช่ ECMAScript เช่น หากการนำเข้าเริ่มต้นทำงานในสภาพแวดล้อมของคุณ (เช่น Webpack, SystemJS, esm)--esModuleInterop หากคุณต้องการให้ TypeScript ดูแลการทำงานร่วมกันที่ไม่ใช่ ECMAScript (ตั้งแต่ TypeScript 2.7) export = แต่ฉันชอบใช้การนำเข้าเริ่มต้น ฉันสามารถเปลี่ยน export = เป็น export default หรือไม่ เช่นเดียวกับในคำถามก่อนหน้านี้ อ้างถึงการใช้ตัวเลือกคอมไพเลอร์ --allowSyntheticDefaultImports หรือ --esModuleInterop
อย่าเปลี่ยนคำจำกัดความของประเภทหากถูกต้อง สำหรับแพ็คเกจ npm export = ถูกต้องหาก node -p 'require("foo")' ทำงานเพื่อนำเข้าโมดูลและ export default จะแม่นยำหาก node -p 'require("foo").default' ทำงานเพื่อนำเข้าโมดูล .
จากนั้น คุณจะต้องตั้งค่าเวอร์ชันขั้นต่ำที่รองรับโดยการระบุ "minimumTypeScriptVersion": "XY" ใน package.json
อย่างไรก็ตาม หากโปรเจ็กต์ของคุณจำเป็นต้องรักษาประเภทที่เข้ากันได้กับ 3.7 ขึ้นไป พร้อมกับ ประเภทที่เข้ากันได้กับ 3.6 หรือต่ำกว่า คุณจะต้องใช้ฟีเจอร์ typesVersions คุณสามารถดูคำอธิบายโดยละเอียดเกี่ยวกับคุณลักษณะนี้ได้ในเอกสาร TypeScript อย่างเป็นทางการ
นี่เป็นตัวอย่างสั้นๆ ในการเริ่มต้น:
คุณจะต้องเพิ่ม typesVersions ไปที่ package.json :
{
"private" : true ,
"types" : " index " ,
"typesVersions" : {
"<=3.6" : { "*" : [ " ts3.6/* " ] }
}
} สร้างไดเรกทอรีย่อยที่กล่าวถึงในช่อง typesVersions ภายในไดเรกทอรีประเภทของคุณ ( ts3.6/ ในตัวอย่างนี้) ts3.6/ จะรองรับ TypeScript เวอร์ชัน 3.6 และต่ำกว่า ดังนั้นให้คัดลอกประเภทที่มีอยู่และการทดสอบที่นั่น
กลับไปที่รูทของแพ็คเกจ เพิ่มคุณสมบัติ TypeScript 3.7 ที่คุณต้องการใช้ เมื่อมีคนติดตั้งแพ็คเกจ TypeScript 3.6 และต่ำกว่าจะเริ่มจาก ts3.6/index.d.ts ในขณะที่ TypeScript 3.7 และสูงกว่าจะเริ่มจาก index.d.ts
คุณสามารถดูบลูเบิร์ดเป็นตัวอย่างได้
สิ่งนี้อาจอยู่ใน TypeScript-DOM-lib-generator ดูแนวทางที่นั่น ถ้ามาตรฐานยังคงเป็นแบบร่าง มันก็จะอยู่ที่นี่ ใช้ชื่อที่ขึ้นต้นด้วย dom- และรวมลิงก์ไปยังมาตรฐานเป็นลิงก์ "โครงการ" ใน package.json เมื่อจบโหมดร่างแล้ว เราอาจลบมันออกจาก Surely Typed และเลิกใช้แพ็คเกจ @types ที่เกี่ยวข้อง
หมายเหตุ: การอภิปรายในส่วนนี้จะถือว่ามีความคุ้นเคยกับการกำหนดเวอร์ชันเชิงความหมาย
แต่ละแพ็คเกจที่พิมพ์อย่างแน่นอนจะได้รับเวอร์ชันเมื่อเผยแพร่เป็น npm SureTyped-tools (เครื่องมือที่เผยแพร่แพ็คเกจ @types เป็น npm) จะตั้งค่าเวอร์ชันของแพ็คเกจการประกาศโดยใช้หมายเลขเวอร์ชัน major.minor.9999 ที่แสดงอยู่ใน package.json ตัวอย่างเช่น ต่อไปนี้เป็นสองสามบรรทัดแรกของการประกาศประเภทของโหนดสำหรับเวอร์ชัน 20.8.x ในขณะที่เขียน:
{
"private" : true ,
"name" : " @types/node " ,
"version" : " 20.8.9999 "
} เนื่องจากเวอร์ชันแสดงเป็น 20.8.9999 เวอร์ชัน npm ของแพ็กเกจ @types/node จะเป็น 20.8.x เช่นกัน โปรดทราบว่าเวอร์ชันใน package.json ควรมีเฉพาะเวอร์ชัน major.minor (เช่น 10.12 ) ตามด้วย .9999 เนื่องจากเฉพาะหมายเลขรุ่นหลักและรุ่นรองเท่านั้นที่สอดคล้องระหว่างแพ็คเกจไลบรารีและแพ็คเกจการประกาศประเภท ( .9999 คือเพื่อให้แน่ใจว่าแพ็คเกจ @types ในเครื่องจะใหม่ล่าสุดเสมอในระหว่างการพัฒนาในเครื่อง) หมายเลขการเผยแพร่แพตช์ของแพ็คเกจการประกาศประเภท (เช่น .0 ใน 20.8.0 ) จะถูกเตรียมใช้งานเป็นศูนย์โดยแน่นอน Typed และจะเพิ่มขึ้นในแต่ละครั้ง แพ็คเกจ @types/node ใหม่ถูกเผยแพร่เป็น npm สำหรับไลบรารีที่เกี่ยวข้องเวอร์ชันหลัก/รองเดียวกัน
บางครั้งประเภทเวอร์ชันแพ็คเกจการประกาศและเวอร์ชันแพ็คเกจไลบรารีอาจไม่ตรงกัน ด้านล่างนี้คือสาเหตุทั่วไปบางประการ ตามลำดับความไม่สะดวกของผู้ใช้ห้องสมุด โดยทั่วไปแล้วเฉพาะกรณีสุดท้ายเท่านั้นที่เป็นปัญหา
@types ที่เกี่ยวข้อง โดยทั่วไปแล้ว npm update ควรใช้งานได้ ❗ หากคุณกำลังอัปเดตการประกาศประเภทสำหรับไลบรารี ให้ตั้งค่าเวอร์ชัน major.minor ใน package.json ให้ตรงกับเวอร์ชันไลบรารีที่คุณกำลังจัดทำเอกสารเสมอ!
การกำหนดเวอร์ชันเชิงความหมายกำหนดให้เวอร์ชันที่มีการเปลี่ยนแปลงแบบด่วนต้องเพิ่มหมายเลขเวอร์ชันหลัก ตัวอย่างเช่น ไลบรารีที่ลบฟังก์ชันที่ส่งออกสู่สาธารณะหลังจากเวอร์ชัน 3.5.8 จะต้องเพิ่มเวอร์ชันเป็น 4.0.0 ในเวอร์ชันถัดไป นอกจากนี้ เมื่อไลบรารี่ออกเวอร์ชัน 4.0.0 แพ็คเกจการประกาศประเภท Absolute Typed ก็ควรได้รับการอัปเดตเป็น 4.0.0 รวมถึงการเปลี่ยนแปลงใด ๆ ที่เกิดขึ้นกับ API ของไลบรารีด้วย
ไลบรารี่หลายแห่งมีฐานนักพัฒนาจำนวนมาก (รวมถึงผู้ดูแลแพ็คเกจอื่น ๆ ที่ใช้ไลบรารีนั้นเป็นสิ่งอ้างอิง) ซึ่งจะไม่ย้ายไปยังเวอร์ชันใหม่ที่มีการเปลี่ยนแปลงทันที เนื่องจากอาจใช้เวลาหลายเดือนก่อนที่ผู้ดูแลจะมีเวลาเขียนใหม่ รหัสเพื่อปรับให้เข้ากับเวอร์ชันใหม่ ในระหว่างนี้ ผู้ใช้ไลบรารีเวอร์ชันเก่ายังอาจต้องการอัปเดตการประกาศประเภทสำหรับเวอร์ชันเก่า
หากคุณตั้งใจที่จะอัปเดตการประกาศประเภทของไลบรารีเวอร์ชันเก่าต่อไป คุณสามารถสร้างโฟลเดอร์ย่อยใหม่ (เช่น /v2/ ) ที่ตั้งชื่อตามเวอร์ชันปัจจุบัน (เร็วๆ นี้จะเป็น "เก่า") และคัดลอกไฟล์ที่มีอยู่จากเวอร์ชันปัจจุบันไปยังโฟลเดอร์นั้น .
เมื่อสร้างโฟลเดอร์เวอร์ชันใหม่ ตรวจสอบให้แน่ใจว่าฟิลด์เวอร์ชันของ package.json ได้รับการอัพเดตแล้ว pnpm จะแก้ไขแพ็คเกจเวอร์ชันนี้โดยอัตโนมัติทุกครั้งที่จำเป็น หากแพ็คเกจอื่นใน repo จำเป็นต้องขึ้นอยู่กับเวอร์ชันใหม่นี้ ตรวจสอบให้แน่ใจว่า package.json ของแพ็คเกจนั้นได้รับการอัปเดตด้วย
ตัวอย่างเช่น หากเรากำลังสร้าง types/history/v2 package.json ของมันจะมีลักษณะดังนี้:
{
"private" : true ,
"name" : " @types/history " ,
"version" : " 2.4.9999 "
}แพ็คเกจอื่นอาจเลือกเวอร์ชันนี้โดยระบุ:
{
"private" : true ,
"name" : " @types/browser-sync " ,
"version" : " 2.26.9999 " ,
"dependencies" : {
"@types/history" : " ^2 "
}
} นอกจากนี้ /// <reference types=".." /> จะไม่ทำงานกับการแมปพาธ ดังนั้นการขึ้นต่อกันต้องใช้ import
@types packages จะพิมพ์แพ็คเกจที่เป็นเวอร์ชันเดียวกันเสมอ ดังนั้น @types/[email protected] จึงมีไว้สำหรับ [email protected] ด้วยเหตุนี้ การเปลี่ยนแปลงทั้งหมด ไม่ว่าจะเสียหายหรือไม่ก็ตาม ได้รับการเผยแพร่เป็นการแก้ไขแพตช์ เว้นแต่จะจับคู่กับการเปลี่ยนแปลงหลัก/เล็กน้อยเพื่อเปลี่ยนเวอร์ชันแพ็คเกจที่เป็นเป้าหมาย (โดยบังเอิญหรือไม่ก็ตาม)
เมื่อพูดถึงการเปลี่ยนแปลงที่หยุดชะงัก ผู้ดูแล DT จะพิจารณาถึงความนิยมของแพ็คเกจ ข้อดีของการเปลี่ยนแปลงที่เสนอให้ ความพยายามที่ผู้ใช้จะต้องแก้ไขโค้ดของตน และการเปลี่ยนแปลงนั้นอาจล่าช้าอย่างสมเหตุสมผลจนกว่าจะสามารถซิงค์ได้หรือไม่ กับการชนครั้งใหญ่ของห้องสมุดต้นน้ำ
คู่มือ TypeScript มีข้อมูลทั่วไปที่ดีเยี่ยมเกี่ยวกับการเขียนคำจำกัดความ และไฟล์คำจำกัดความตัวอย่างนี้ซึ่งแสดงวิธีสร้างคำจำกัดความโดยใช้ไวยากรณ์โมดูลสไตล์ ES6 ในขณะเดียวกันก็ระบุอ็อบเจ็กต์ที่ทำให้พร้อมใช้งานในขอบเขตส่วนกลาง เทคนิคนี้แสดงให้เห็นในทางปฏิบัติในคำจำกัดความของ big.js ซึ่งเป็นไลบรารีที่สามารถโหลดได้ทั่วโลกผ่านแท็กสคริปต์บนหน้าเว็บ หรือนำเข้าผ่านคำสั่ง need หรือการนำเข้าสไตล์ ES6
หากต้องการทดสอบว่าคำจำกัดความของคุณสามารถนำมาใช้อย่างไรเมื่อมีการอ้างอิงทั่วโลกหรือเป็นโมดูลที่นำเข้า ให้สร้างโฟลเดอร์ test และวางไฟล์ทดสอบสองไฟล์ในนั้น ตั้งชื่อหนึ่ง YourLibraryName-global.test.ts และ YourLibraryName-module.test.ts อีกอัน ไฟล์ทดสอบ ส่วนกลาง ควรใช้คำจำกัดความตามวิธีการใช้ในสคริปต์ที่โหลดบนเว็บเพจที่มีไลบรารีอยู่ในขอบเขตส่วนกลาง ในสถานการณ์นี้ คุณไม่ควรระบุคำสั่งนำเข้า ไฟล์ทดสอบ โมดูล ควรใช้คำจำกัดความตามวิธีการใช้เมื่อนำเข้า (รวมถึงคำสั่ง import ) หากคุณระบุคุณสมบัติ files ในไฟล์ tsconfig.json ของคุณให้แน่ใจว่าได้รวมไฟล์ทดสอบทั้งสองไฟล์ ตัวอย่างที่เป็นประโยชน์ของสิ่งนี้ยังมีอยู่ในนิยาม big.js
โปรดทราบว่าไม่จำเป็นต้องใช้คำจำกัดความในไฟล์ทดสอบแต่ละไฟล์อย่างเต็มที่ - เพียงพอที่จะทดสอบเฉพาะองค์ประกอบที่เข้าถึงได้ทั่วโลกในไฟล์ทดสอบทั่วโลกและใช้คำจำกัดความในไฟล์ทดสอบโมดูลหรือในทางกลับกัน
ประเภทสำหรับแพ็คเกจที่กำหนดขอบเขต @foo/bar ควรไปเป็น types/foo__bar สังเกตขีดล่างสองเท่า
โครงการนี้ได้รับอนุญาตภายใต้ใบอนุญาต MIT
ลิขสิทธิ์ในไฟล์นิยามนั้นเป็นไปตามลำดับของผู้สนับสนุนแต่ละคนที่แสดงรายการที่จุดเริ่มต้นของแต่ละไฟล์นิยาม
