คู่มือที่ครอบคลุมเกี่ยวกับการแก้ปัญหาโมดูล TypeScript ครอบคลุมกลยุทธ์การแก้ปัญหาโมดูลแบบคลาสสิกและโหนด baseUrl เส้นทาง และแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการเส้นทาง Import ในโครงการที่ซับซ้อน
TypeScript Module Resolution: ไขความลับกลยุทธ์เส้นทาง Import
ระบบการแก้ปัญหาโมดูลของ TypeScript เป็นส่วนสำคัญของการสร้างแอปพลิเคชันที่ปรับขนาดและบำรุงรักษาได้ การทำความเข้าใจวิธีที่ TypeScript ค้นหาโมดูลตามเส้นทาง Import เป็นสิ่งสำคัญสำหรับการจัดระเบียบโค้ดเบสของคุณและหลีกเลี่ยงข้อผิดพลาดทั่วไป คู่มือฉบับสมบูรณ์นี้จะเจาะลึกถึงความซับซ้อนของการแก้ปัญหาโมดูล TypeScript ครอบคลุมกลยุทธ์การแก้ปัญหาโมดูลแบบคลาสสิกและโหนด บทบาทของ baseUrl และ paths ใน tsconfig.json และแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการเส้นทาง Import อย่างมีประสิทธิภาพ
Module Resolution คืออะไร
Module Resolution คือกระบวนการที่คอมไพเลอร์ TypeScript กำหนดตำแหน่งของโมดูลตามคำสั่ง Import ในโค้ดของคุณ เมื่อคุณเขียน import { SomeComponent } from './components/SomeComponent'; TypeScript จำเป็นต้องหาว่าโมดูล SomeComponent อยู่ที่ใดในระบบไฟล์ของคุณ กระบวนการนี้อยู่ภายใต้ชุดของกฎและการกำหนดค่าที่กำหนดวิธีที่ TypeScript ค้นหาโมดูล
การแก้ปัญหาโมดูลที่ไม่ถูกต้องอาจนำไปสู่ข้อผิดพลาดในการคอมไพล์ ข้อผิดพลาดรันไทม์ และความยากลำบากในการทำความเข้าใจโครงสร้างของโปรเจ็กต์ ดังนั้นความเข้าใจที่มั่นคงเกี่ยวกับการแก้ปัญหาโมดูลจึงเป็นสิ่งสำคัญสำหรับนักพัฒนา TypeScript ทุกคน
กลยุทธ์ Module Resolution
TypeScript มีกลยุทธ์ Module Resolution หลักสองประการ ซึ่งกำหนดค่าผ่านตัวเลือกคอมไพเลอร์ moduleResolution ใน tsconfig.json:
- Classic: กลยุทธ์ Module Resolution ดั้งเดิมที่ใช้โดย TypeScript
- Node: เลียนแบบอัลกอริทึม Module Resolution ของ Node.js ทำให้เหมาะสำหรับโปรเจ็กต์ที่กำหนดเป้าหมาย Node.js หรือใช้แพ็กเกจ npm
Classic Module Resolution
กลยุทธ์ Module Resolution classic เป็นวิธีที่ง่ายกว่าในสองวิธีนี้ โดยจะค้นหาโมดูลด้วยวิธีตรงไปตรงมา โดยการข้ามขึ้นไปบนโครงสร้างไดเรกทอรีจากไฟล์ที่ Import
วิธีการทำงาน:
- เริ่มต้นจากไดเรกทอรีที่มีไฟล์ที่ Import
- TypeScript มองหาไฟล์ที่มีชื่อและนามสกุลที่ระบุ (
.ts,.tsx,.d.ts) - หากไม่พบ จะย้ายขึ้นไปยังไดเรกทอรีหลักและทำซ้ำการค้นหา
- กระบวนการนี้ดำเนินต่อไปจนกว่าจะพบโมดูลหรือถึงรูทของระบบไฟล์
ตัวอย่าง:
พิจารณาโครงสร้างโปรเจ็กต์ต่อไปนี้:
project/
├── src/
│ ├── components/
│ │ ├── SomeComponent.ts
│ │ └── index.ts
│ └── app.ts
├── tsconfig.json
หาก app.ts มีคำสั่ง Import import { SomeComponent } from './components/SomeComponent'; กลยุทธ์ Module Resolution classic จะ:
- มองหา
./components/SomeComponent.ts,./components/SomeComponent.tsxหรือ./components/SomeComponent.d.tsในไดเรกทอรีsrc - หากไม่พบ จะย้ายขึ้นไปยังไดเรกทอรีหลัก (รูทของโปรเจ็กต์) และทำซ้ำการค้นหา ซึ่งไม่น่าจะสำเร็จในกรณีนี้เนื่องจากคอมโพเนนต์อยู่ในโฟลเดอร์
src
ข้อจำกัด:
- ความยืดหยุ่นที่จำกัดในการจัดการโครงสร้างโปรเจ็กต์ที่ซับซ้อน
- ไม่รองรับการค้นหาภายใน
node_modulesทำให้ไม่เหมาะสำหรับโปรเจ็กต์ที่ต้องพึ่งพาแพ็กเกจ npm - สามารถนำไปสู่เส้นทาง Import แบบสัมพันธ์ที่ยืดยาวและซ้ำซาก
ควรใช้เมื่อใด:
โดยทั่วไปแล้วกลยุทธ์ Module Resolution classic เหมาะสำหรับโปรเจ็กต์ขนาดเล็กมากที่มีโครงสร้างไดเรกทอรีที่เรียบง่ายและไม่มี Dependency ภายนอก โปรเจ็กต์ TypeScript สมัยใหม่ควรใช้กลยุทธ์ Module Resolution node เกือบตลอดเวลา
Node Module Resolution
กลยุทธ์ Module Resolution node เลียนแบบอัลกอริทึม Module Resolution ที่ใช้โดย Node.js ทำให้เป็นตัวเลือกที่ต้องการสำหรับโปรเจ็กต์ที่กำหนดเป้าหมาย Node.js หรือใช้แพ็กเกจ npm เนื่องจากให้ลักษณะการทำงาน Module Resolution ที่สอดคล้องและคาดการณ์ได้
วิธีการทำงาน:
กลยุทธ์ Module Resolution node เป็นไปตามชุดกฎที่ซับซ้อนกว่า โดยจัดลำดับความสำคัญของการค้นหาภายใน node_modules และการจัดการนามสกุลไฟล์ที่แตกต่างกัน:
- Non-relative Import: หากเส้นทาง Import ไม่ได้ขึ้นต้นด้วย
./,../หรือ/TypeScript จะถือว่าเป็นการอ้างอิงถึงโมดูลที่อยู่ในnode_modulesโดยจะค้นหาโมดูลในตำแหน่งต่อไปนี้: node_modulesในไดเรกทอรีปัจจุบันnode_modulesในไดเรกทอรีหลัก- ...และอื่นๆ ขึ้นไปจนถึงรูทของระบบไฟล์
- Relative Import: หากเส้นทาง Import ขึ้นต้นด้วย
./,../หรือ/TypeScript จะถือว่าเป็นเส้นทางแบบสัมพันธ์และค้นหาโมดูลในตำแหน่งที่ระบุ โดยพิจารณาถึงสิ่งต่อไปนี้: - ขั้นแรก จะมองหาไฟล์ที่มีชื่อและนามสกุลที่ระบุ (
.ts,.tsx,.d.ts) - หากไม่พบ จะมองหาไดเรกทอรีที่มีชื่อที่ระบุและไฟล์ชื่อ
index.ts,index.tsxหรือindex.d.tsภายในไดเรกทอรีนั้น (เช่น./components/index.tsหาก Import คือ./components)
ตัวอย่าง:
พิจารณาโครงสร้างโปรเจ็กต์ต่อไปนี้ที่มี Dependency ในไลบรารี lodash:
project/
├── src/
│ ├── utils/
│ │ └── helpers.ts
│ └── app.ts
├── node_modules/
│ └── lodash/
│ └── lodash.js
├── tsconfig.json
หาก app.ts มีคำสั่ง Import import * as _ from 'lodash'; กลยุทธ์ Module Resolution node จะ:
- รับรู้ว่า
lodashเป็น Non-relative Import - ค้นหา
lodashในไดเรกทอรีnode_modulesภายในรูทของโปรเจ็กต์ - ค้นหาโมดูล
lodashในnode_modules/lodash/lodash.js
หาก helpers.ts มีคำสั่ง Import import { SomeHelper } from './SomeHelper'; กลยุทธ์ Module Resolution node จะ:
- รับรู้ว่า
./SomeHelperเป็น Relative Import - มองหา
./SomeHelper.ts,./SomeHelper.tsxหรือ./SomeHelper.d.tsในไดเรกทอรีsrc/utils - หากไม่มีไฟล์เหล่านั้น จะมองหาไดเรกทอรีชื่อ
SomeHelperจากนั้นค้นหาindex.ts,index.tsxหรือindex.d.tsภายในไดเรกทอรีนั้น
ข้อดี:
- รองรับ
node_modulesและแพ็กเกจ npm - ให้ลักษณะการทำงาน Module Resolution ที่สอดคล้องกับ Node.js
- ลดความซับซ้อนของเส้นทาง Import โดยอนุญาต Non-relative Import สำหรับโมดูลใน
node_modules
ควรใช้เมื่อใด:
กลยุทธ์ Module Resolution node เป็นตัวเลือกที่แนะนำสำหรับโปรเจ็กต์ TypeScript ส่วนใหญ่ โดยเฉพาะอย่างยิ่งโปรเจ็กต์ที่กำหนดเป้าหมาย Node.js หรือใช้แพ็กเกจ npm ให้ระบบ Module Resolution ที่ยืดหยุ่นและมีประสิทธิภาพมากกว่าเมื่อเทียบกับกลยุทธ์ classic
การกำหนดค่า Module Resolution ใน tsconfig.json
ไฟล์ tsconfig.json เป็นไฟล์กำหนดค่าส่วนกลางสำหรับโปรเจ็กต์ TypeScript ของคุณ ช่วยให้คุณระบุตัวเลือกคอมไพเลอร์ รวมถึงกลยุทธ์ Module Resolution และปรับแต่งวิธีที่ TypeScript จัดการโค้ดของคุณ
นี่คือไฟล์ tsconfig.json พื้นฐานที่มีกลยุทธ์ Module Resolution node:
{
"compilerOptions": {
"moduleResolution": "node",
"target": "es5",
"module": "commonjs",
"esModuleInterop": true,
"strict": true,
"outDir": "dist",
"sourceMap": true
},
"include": [
"src/**/*"
],
"exclude": [
"node_modules"
]
}
compilerOptions หลักที่เกี่ยวข้องกับ Module Resolution:
moduleResolution: ระบุกลยุทธ์ Module Resolution (classicหรือnode)baseUrl: ระบุไดเรกทอรีฐานสำหรับการแก้ปัญหาชื่อโมดูลที่ไม่ใช่แบบสัมพันธ์paths: ช่วยให้คุณกำหนดค่าการแมปเส้นทางแบบกำหนดเองสำหรับโมดูล
baseUrl และ paths: การควบคุมเส้นทาง Import
ตัวเลือกคอมไพเลอร์ baseUrl และ paths มีกลไกที่มีประสิทธิภาพสำหรับการควบคุมวิธีที่ TypeScript แก้ปัญหาเส้นทาง Import สามารถปรับปรุงความสามารถในการอ่านและความสามารถในการบำรุงรักษาโค้ดของคุณได้อย่างมาก โดยอนุญาตให้คุณใช้ Import แบบสัมบูรณ์และสร้างการแมปเส้นทางแบบกำหนดเอง
baseUrl
ตัวเลือก baseUrl ระบุไดเรกทอรีฐานสำหรับการแก้ปัญหาชื่อโมดูลที่ไม่ใช่แบบสัมพันธ์ เมื่อตั้งค่า baseUrl แล้ว TypeScript จะแก้ปัญหาเส้นทาง Import ที่ไม่ใช่แบบสัมพันธ์ที่สัมพันธ์กับไดเรกทอรีฐานที่ระบุ แทนที่จะเป็นไดเรกทอรีการทำงานปัจจุบัน
ตัวอย่าง:
พิจารณาโครงสร้างโปรเจ็กต์ต่อไปนี้:
project/
├── src/
│ ├── components/
│ │ ├── SomeComponent.ts
│ │ └── index.ts
│ └── app.ts
├── tsconfig.json
หาก tsconfig.json มีสิ่งต่อไปนี้:
{
"compilerOptions": {
"moduleResolution": "node",
"baseUrl": "./src"
}
}
จากนั้น ใน app.ts คุณสามารถใช้คำสั่ง Import ต่อไปนี้:
import { SomeComponent } from 'components/SomeComponent';
แทนที่จะ:
import { SomeComponent } from './components/SomeComponent';
TypeScript จะแก้ปัญหา components/SomeComponent ที่สัมพันธ์กับไดเรกทอรี ./src ที่ระบุโดย baseUrl
ประโยชน์ของการใช้ baseUrl:
- ลดความซับซ้อนของเส้นทาง Import โดยเฉพาะอย่างยิ่งในไดเรกทอรีที่ซ้อนกันลึก
- ทำให้โค้ดอ่านง่ายขึ้นและเข้าใจง่ายขึ้น
- ลดความเสี่ยงของข้อผิดพลาดที่เกิดจากเส้นทาง Import แบบสัมพันธ์ที่ไม่ถูกต้อง
- อำนวยความสะดวกในการปรับโครงสร้างโค้ดใหม่โดยแยกเส้นทาง Import ออกจากโครงสร้างไฟล์ทางกายภาพ
paths
ตัวเลือก paths ช่วยให้คุณกำหนดค่าการแมปเส้นทางแบบกำหนดเองสำหรับโมดูล ให้วิธีการที่ยืดหยุ่นและมีประสิทธิภาพมากขึ้นในการควบคุมวิธีที่ TypeScript แก้ปัญหาเส้นทาง Import ช่วยให้คุณสร้าง Alias สำหรับโมดูลและเปลี่ยนเส้นทาง Import ไปยังตำแหน่งต่างๆ
ตัวเลือก paths เป็นออบเจ็กต์ โดยที่แต่ละคีย์แสดงถึงรูปแบบเส้นทาง และแต่ละค่าคืออาร์เรย์ของการแทนที่เส้นทาง TypeScript จะพยายามจับคู่เส้นทาง Import กับรูปแบบเส้นทาง และหากพบการจับคู่ จะแทนที่เส้นทาง Import ด้วยเส้นทางการแทนที่ที่ระบุ
ตัวอย่าง:
พิจารณาโครงสร้างโปรเจ็กต์ต่อไปนี้:
project/
├── src/
│ ├── components/
│ │ ├── SomeComponent.ts
│ │ └── index.ts
│ └── app.ts
├── libs/
│ └── my-library.ts
├── tsconfig.json
หาก tsconfig.json มีสิ่งต่อไปนี้:
{
"compilerOptions": {
"moduleResolution": "node",
"baseUrl": "./src",
"paths": {
"@components/*": ["components/*"],
"@mylib": ["../libs/my-library.ts"]
}
}
}
จากนั้น ใน app.ts คุณสามารถใช้คำสั่ง Import ต่อไปนี้:
import { SomeComponent } from '@components/SomeComponent';
import { MyLibraryFunction } from '@mylib';
TypeScript จะแก้ปัญหา @components/SomeComponent เป็น components/SomeComponent ตามการแมปเส้นทาง @components/* และ @mylib เป็น ../libs/my-library.ts ตามการแมปเส้นทาง @mylib
ประโยชน์ของการใช้ paths:
- สร้าง Alias สำหรับโมดูล ลดความซับซ้อนของเส้นทาง Import และปรับปรุงความสามารถในการอ่าน
- เปลี่ยนเส้นทาง Import ไปยังตำแหน่งต่างๆ อำนวยความสะดวกในการปรับโครงสร้างโค้ดใหม่และการจัดการ Dependency
- ช่วยให้คุณแยกโครงสร้างไฟล์ทางกายภาพออกจากเส้นทาง Import ทำให้โค้ดของคุณมีความยืดหยุ่นต่อการเปลี่ยนแปลงมากขึ้น
- รองรับอักขระ Wildcard (
*) สำหรับการจับคู่เส้นทางที่ยืดหยุ่น
กรณีการใช้งานทั่วไปสำหรับ paths:
- การสร้าง Alias สำหรับโมดูลที่ใช้บ่อย: ตัวอย่างเช่น คุณสามารถสร้าง Alias สำหรับไลบรารียูทิลิตี้หรือชุดของคอมโพเนนต์ที่แชร์
- การแมปกับการ Implement ที่แตกต่างกันตามสภาพแวดล้อม: ตัวอย่างเช่น คุณสามารถแมปอินเทอร์เฟซกับการ Implement แบบ Mock เพื่อวัตถุประสงค์ในการทดสอบ
- ลดความซับซ้อนของการ Import จาก Monorepo: ใน Monorepo คุณสามารถใช้
pathsเพื่อแมปกับโมดูลภายในแพ็กเกจต่างๆ
แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการเส้นทาง Import
การจัดการเส้นทาง Import ที่มีประสิทธิภาพเป็นสิ่งสำคัญสำหรับการสร้างแอปพลิเคชัน TypeScript ที่ปรับขนาดและบำรุงรักษาได้ ต่อไปนี้คือแนวทางปฏิบัติที่ดีที่สุดที่ควรปฏิบัติตาม:
- ใช้กลยุทธ์ Module Resolution
node: กลยุทธ์ Module Resolutionnodeเป็นตัวเลือกที่แนะนำสำหรับโปรเจ็กต์ TypeScript ส่วนใหญ่ เนื่องจากให้ลักษณะการทำงาน Module Resolution ที่สอดคล้องและคาดการณ์ได้ - กำหนดค่า
baseUrl: ตั้งค่าตัวเลือกbaseUrlเป็นไดเรกทอรีรูทของซอร์สโค้ดของคุณเพื่อลดความซับซ้อนของเส้นทาง Import และปรับปรุงความสามารถในการอ่าน - ใช้
pathsสำหรับการแมปเส้นทางแบบกำหนดเอง: ใช้ตัวเลือกpathsเพื่อสร้าง Alias สำหรับโมดูลและเปลี่ยนเส้นทาง Import ไปยังตำแหน่งต่างๆ โดยแยกโครงสร้างไฟล์ทางกายภาพออกจากเส้นทาง Import - หลีกเลี่ยงเส้นทาง Import แบบสัมพันธ์ที่ซ้อนกันลึก: เส้นทาง Import แบบสัมพันธ์ที่ซ้อนกันลึก (เช่น
../../../../utils/helpers) อาจอ่านและบำรุงรักษายาก ใช้baseUrlและpathsเพื่อลดความซับซ้อนของเส้นทางเหล่านี้ - มีความสอดคล้องกับสไตล์ Import ของคุณ: เลือกสไตล์ Import ที่สอดคล้องกัน (เช่น การใช้ Import แบบสัมบูรณ์หรือ Import แบบสัมพันธ์) และยึดมั่นในสไตล์นั้นตลอดทั้งโปรเจ็กต์ของคุณ
- จัดระเบียบโค้ดของคุณเป็นโมดูลที่กำหนดไว้อย่างดี: การจัดระเบียบโค้ดของคุณเป็นโมดูลที่กำหนดไว้อย่างดีทำให้ง่ายต่อการทำความเข้าใจและบำรุงรักษา และลดความซับซ้อนของกระบวนการจัดการเส้นทาง Import
- ใช้ตัวจัดรูปแบบโค้ดและ Linter: ตัวจัดรูปแบบโค้ดและ Linter สามารถช่วยคุณบังคับใช้มาตรฐานการเขียนโค้ดที่สอดคล้องกันและระบุปัญหาที่อาจเกิดขึ้นกับเส้นทาง Import ของคุณ
การแก้ไขปัญหา Module Resolution
ปัญหา Module Resolution อาจทำให้หงุดหงิดในการดีบัก ต่อไปนี้คือปัญหาและวิธีแก้ไขทั่วไป:
- ข้อผิดพลาด "Cannot find module":
- ปัญหา: TypeScript ไม่พบโมดูลที่ระบุ
- วิธีแก้ไข:
- ตรวจสอบว่าได้ติดตั้งโมดูลแล้ว (หากเป็นแพ็กเกจ npm)
- ตรวจสอบเส้นทาง Import สำหรับการพิมพ์ผิด
- ตรวจสอบให้แน่ใจว่าได้กำหนดค่าตัวเลือก
moduleResolution,baseUrlและpathsอย่างถูกต้องในtsconfig.json - ยืนยันว่าไฟล์โมดูลมีอยู่ที่ตำแหน่งที่คาดไว้
- เวอร์ชันโมดูลไม่ถูกต้อง:
- ปัญหา: คุณกำลัง Import โมดูลที่มีเวอร์ชันที่ไม่เข้ากัน
- วิธีแก้ไข:
- ตรวจสอบไฟล์
package.jsonของคุณเพื่อดูว่ามีการติดตั้งโมดูลเวอร์ชันใด - อัปเดตโมดูลเป็นเวอร์ชันที่เข้ากันได้
- ตรวจสอบไฟล์
- Dependency วนซ้ำ:
- ปัญหา: สองโมดูลขึ้นไปขึ้นอยู่กับซึ่งกันและกัน สร้าง Dependency วนซ้ำ
- วิธีแก้ไข:
- ปรับโครงสร้างโค้ดของคุณเพื่อทำลาย Dependency วนซ้ำ
- ใช้ Dependency Injection เพื่อแยกโมดูล
ตัวอย่างในโลกแห่งความเป็นจริงในเฟรมเวิร์กต่างๆ
หลักการของ TypeScript Module Resolution ใช้ได้กับเฟรมเวิร์ก JavaScript ต่างๆ นี่คือวิธีที่ใช้กันทั่วไป:
- React:
- โปรเจ็กต์ React ต้องพึ่งพาสถาปัตยกรรมแบบคอมโพเนนต์อย่างมาก ทำให้ Module Resolution ที่ถูกต้องมีความสำคัญอย่างยิ่ง
- การใช้
baseUrlเพื่อชี้ไปยังไดเรกทอรีsrcช่วยให้สามารถ Import ได้อย่างสะอาด เช่นimport MyComponent from 'components/MyComponent'; - โดยทั่วไปแล้ว ไลบรารี เช่น
styled-componentsหรือmaterial-uiจะถูก Import โดยตรงจากnode_modulesโดยใช้กลยุทธ์การแก้ปัญหาnode
- Angular:
- Angular CLI จะกำหนดค่า
tsconfig.jsonโดยอัตโนมัติด้วยค่าเริ่มต้นที่สมเหตุสมผล รวมถึงbaseUrlและpaths - โดยทั่วไปแล้วโมดูลและคอมโพเนนต์ Angular จะถูกจัดระเบียบเป็นโมดูลคุณสมบัติ โดยใช้ Alias เส้นทางสำหรับการ Import ที่ง่ายขึ้นภายในและระหว่างโมดูล ตัวอย่างเช่น
@app/sharedอาจแมปกับไดเรกทอรีโมดูลที่แชร์
- Angular CLI จะกำหนดค่า
- Vue.js:
- เช่นเดียวกับ React โปรเจ็กต์ Vue.js ได้รับประโยชน์จากการใช้
baseUrlเพื่อปรับปรุงการ Import คอมโพเนนต์ - โมดูลร้านค้า Vuex สามารถสร้าง Alias ได้อย่างง่ายดายโดยใช้
pathsซึ่งช่วยปรับปรุงการจัดระเบียบและความสามารถในการอ่านของโค้ดเบส
- เช่นเดียวกับ React โปรเจ็กต์ Vue.js ได้รับประโยชน์จากการใช้
- Node.js (Express, NestJS):
- ตัวอย่างเช่น NestJS สนับสนุนให้ใช้ Alias เส้นทางอย่างกว้างขวางสำหรับการจัดการการ Import โมดูลในแอปพลิเคชันที่มีโครงสร้าง
- กลยุทธ์การแก้ปัญหาโมดูล
nodeเป็นค่าเริ่มต้นและจำเป็นสำหรับการทำงานกับnode_modules
สรุป
ระบบ Module Resolution ของ TypeScript เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการจัดระเบียบโค้ดเบสของคุณและการจัดการ Dependency อย่างมีประสิทธิภาพ โดยการทำความเข้าใจกลยุทธ์ Module Resolution ที่แตกต่างกัน บทบาทของ baseUrl และ paths และแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการเส้นทาง Import คุณสามารถสร้างแอปพลิเคชัน TypeScript ที่ปรับขนาดได้ บำรุงรักษาได้ และอ่านง่าย การกำหนดค่า Module Resolution อย่างถูกต้องใน tsconfig.json สามารถปรับปรุงเวิร์กโฟลว์การพัฒนาของคุณได้อย่างมาก และลดความเสี่ยงของข้อผิดพลาด ทดลองกับการกำหนดค่าต่างๆ และค้นหาวิธีที่เหมาะสมที่สุดสำหรับความต้องการของโปรเจ็กต์ของคุณ