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

ทำไมคุณยังคงได้รับ 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 ต้อง “ตรงกันทุกประการ”

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

# ❌ Incorrect: เส้นทางไม่ตรงกัน ซึ่งจะทำให้เกิดความล้มเหลวในการอนุญาต
//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
# @company scope ใช้ group level registry
# แพ็คเกจ @company/* ทั้งหมดจะติดตั้งจาก registry นี้
@company:registry=https://gitlab.com/api/v4/groups/YOUR_GROUP_ID/-/packages/npm/

# การตั้งค่าการรับรองความถูกต้อง GitLab npm registry
# ใช้ common gitlab.com auth token (ครอบคลุมคำขอระดับ group และ project ทั้งหมด)
//gitlab.com/api/v4/groups/YOUR_GROUP_ID/-/packages/npm/:_authToken=${GITLAB_NPM_TOKEN}
# ใช้ project registry เพื่อเผยแพร่แพ็คเกจ
//gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/:_authToken=${GITLAB_NPM_TOKEN}


# แพ็คเกจสาธารณะอื่นๆ ยังคงไปที่ official registry
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 จะเป็นผู้ช่วยที่ทรงพลังในกระบวนการพัฒนาของบริษัทคุณ!