คุณติดขัดกับการกำหนดค่า .npmrc เนื่องจากโปรเจ็กต์ของบริษัทต้องใช้ Private Package หรือไม่?

ทำไมยังแสดง 404 Not Found ทั้งที่ตั้งค่า Token แล้ว?

เมื่อบริษัทมีหลายทีม หลายแพ็คเกจ (เช่น @frontend, @backend) คุณจะจัดการ .npmrc อย่างสง่างามได้อย่างไร?

ไขความกระจ่างสองความเชื่อเกี่ยวกับ .npmrc

ก่อนจะเข้าใจ .npmrc คุณต้องเข้าใจก่อนว่ามันทำงานอย่างไร

พูดง่ายๆ คือ ตรรกะหลักของมันสรุปได้สองประการ: Scope Mapping และ Authentication

1. Scope Mapping

นี่เป็นการบอก npm ว่า: เมื่อคุณเห็นแพ็คเกจที่ขึ้นต้นด้วย @company อย่าไปหาที่ npmjs.org อย่างเป็นทางการ แต่ให้ไปที่ GitLab Registry ที่เรากำหนด

@company:registry=https://gitlab.com/api/v4/groups/100/-/packages/npm/

2. Authentication

เมื่อมีที่อยู่แล้ว คุณยังต้องมีกุญแจ กุญแจคือ AuthToken ของคุณ

นี่คือกฎที่สำคัญอย่างยิ่ง: Registry URL และ AuthToken Path ต้อง “ตรงกันทุกประการ”

# ✅ ถูกต้อง: เส้นทางตรงกับ registry ที่กำหนดไว้ข้างต้นทุกประการ
//gitlab.com/api/v4/groups/100/-/packages/npm/:_authToken=${GITLAB_TOKEN}

# ❌ ผิด: เส้นทางไม่ตรงกัน ซึ่งจะทำให้เกิดความล้มเหลวในการอนุญาต
//gitlab.com/api/v4/:_authToken=${GITLAB_TOKEN}

หลายคนตั้งค่าล้มเหลวบ่อยครั้งเพราะมีเครื่องหมายทับเกินมาหรือขาดระดับในเส้นทาง

Dependency Hell และข้อผิดพลาด 404

สถานการณ์ที่น่าปวดหัวที่สุดคือ: คุณติดตั้งแพ็คเกจ A ซึ่งขึ้นอยู่กับแพ็คเกจ B (ซึ่งเป็นส่วนตัวเช่นกัน) จากนั้น npm ก็พ่น 404 Not Found ออกมา

ทำไมถึงเกิดขึ้น? นั่นเป็นเพราะ npm หลงทางเมื่อแก้ไขการพึ่งพาหากไม่มีความสอดคล้องที่ถูกต้อง

โดยเฉพาะเมื่อคุณมีสอง Scope ที่แตกต่างกัน (เช่น @team-a และ @team-b) ใน GitLab Group ที่แตกต่างกัน .npmrc อาจซับซ้อนและดูแลรักษายากมาก ยิ่งไปกว่านั้น Registry ที่แตกต่างกันอาจต้องการ Token ที่แตกต่างกัน การจัดการตัวแปรสภาพแวดล้อมเหล่านี้เพียงอย่างเดียวก็เพียงพอที่จะทำให้คุณอิ่มแล้ว

มีวิธีที่ฉลาดกว่านี้ไหม?

โซลูชันที่แนะนำ: Unified Download Group Registry & Independent Publish Project Registry

ทำไมต้องทำเช่นนี้?

การตั้งค่าในทางปฏิบัติ

คุณสามารถคัดลอกเทมเพลตนี้ได้โดยตรง:

จำไว้ว่าให้มอบงานปกป้อง Token ให้กับตัวแปรสภาพแวดล้อม อย่าฮาร์ดโค้ด Token โดยตรงในโค้ดเด็ดขาด!

# .npmrc
# auth token ระดับโดเมนทั่วไป (ครอบคลุมคำขอติดตั้งระดับ group และ project ทั้งหมด)
//gitlab.com/:_authToken=${GITLAB_NPM_TOKEN}

# สำหรับการเผยแพร่: project-level auth token (npm publish ต้องมีการจับคู่เส้นทางที่แน่นอน)
//gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/:_authToken=${GITLAB_NPM_TOKEN}

# @company scope ใช้ registry ระดับ group
# แพ็คเกจ @company/* ทั้งหมดจะถูกติดตั้งจาก registry นี้
@company:registry=https://gitlab.com/api/v4/groups/YOUR_GROUP_ID/-/packages/npm/

# แพ็คเกจสาธารณะอื่นๆ ยังคงไปที่ไลบรารีอย่างเป็นทางการ
registry=https://registry.npmjs.org/

กำหนดค่า publishConfig ใน package.json เพื่อเผยแพร่แพ็คเกจไปยัง GitLab Project Registry ที่เกี่ยวข้อง

{
  "name": "@company/my-package",
  "publishConfig": {
    "@company:registry": "https://gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/"
  }
}

บทสรุป

ด้วยกลยุทธ์ของ “Unified Download Group Registry” และ “Independent Publish Project Registry” เราสามารถลดค่าใช้จ่ายในการบำรุงรักษาได้อย่างมากและทำให้กระบวนการพัฒนาราบรื่นขึ้น

เมื่อเข้าใจตรรกะเหล่านี้แล้ว GitLab NPM Registry จะเป็นผู้ช่วยที่ทรงพลังในกระบวนการพัฒนาของบริษัทคุณ!