การเชื่อมต่อ VPN ไม่ควรหมายถึงการแก้ไขการตั้งค่า registry ของ npm วันละสองครั้ง รายการ scope ในไฟล์กำหนดค่าที่ระดับโปรเจกต์สามารถส่งแพ็กเกจของบริษัทไปยัง registry หนึ่งและส่งอย่างอื่นไปยัง registry สาธารณะ โดยไม่ต้องสลับและไม่มี override หลงเหลือในบ่ายวันศุกร์ กับดักคือวิธีนี้แก้เพียงการตั้งชื่อ ส่วนการกำหนดเส้นทาง ข้อมูลรับรอง และลำดับความสำคัญของการกำหนดค่าเป็นสามเรื่องแยกกันที่ล้มเหลวคนละแบบ

สองชื่อ สองปลายทาง

ชื่อแพ็กเกจ npm มี scope หรือไม่มี ชื่อที่มี scope เริ่มต้นด้วยเครื่องหมาย at และตัวระบุ scope และตัวระบุนั้นคือสิ่งที่การกำหนดค่าจับคู่ได้ ไม่มีสิ่งอื่นเกี่ยวกับแพ็กเกจที่สำคัญต่อการจับคู่ registry ไม่เคยเห็นคำขอที่อิงว่าแพ็กเกจเป็นภายในหรือสาธารณะ มันเห็นเพียงชื่อ

ไฟล์ด้านล่างจึงแสดงเจตนาสองอย่างในสามบรรทัด แพ็กเกจสาธารณะไปยัง registry สาธารณะ และแพ็กเกจภายใต้ scope ของบริษัทไปยัง registry ของบริษัทพร้อม token สำหรับ host นั้น

registry=https://registry.npmjs.org/
@acme:registry=https://packages.corp.example/
//packages.corp.example/:_authToken=${NPM_TOKEN}

แทนที่ scope, host และชื่อตัวแปรด้วยสิ่งที่องค์กรให้มาจริง โครงสร้างคือสิ่งที่สำคัญ ไม่ใช่ค่าตัวอย่าง สองบรรทัดของการกำหนดค่าบรรจุนโยบายทั้งหมด นั่นคือเหตุผลที่ควรทำความเข้าใจแทนการคัดลอก

แยกการจับคู่กับเครือข่ายไว้คนละช่องในหัวของคุณ รายการ scope ไม่สามารถทำให้ host ที่เข้าถึงไม่ได้เข้าถึงได้ และ tunnel ที่ทำงานได้ก็ไม่สามารถบอก npm ได้ว่าแพ็กเกจเป็นของ registry ใด

เขียนไฟล์ตามลำดับที่ถูกต้อง

ให้ไฟล์โปรเจกต์มาก่อนในการคิดของคุณแม้ npm จะอ่านหลายไฟล์ .npmrc ในไดเรกทอรีโปรเจกต์คือไฟล์ที่เพื่อนร่วมงานของคุณได้รับผ่าน repository จึงควรแสดงนโยบายร่วมไม่ใช่ token ส่วนตัวของคุณ ไฟล์นั้นยังเป็นไฟล์ที่ผู้ตรวจจะอ่านด้วย เก็บให้เล็กพอที่จะตรวจได้ในครั้งเดียว

ปล่อยบรรทัด registry ค่าเริ่มต้นให้ชี้ไปที่ registry สาธารณะ เว้นแต่องค์กรจะตัดสินใจเป็นอย่างอื่น การลบมันทำให้เครื่องขึ้นอยู่กับสิ่งที่ไฟล์ระดับผู้ใช้บอก ซึ่งเป็น Dependency โดยนัยแบบเดียวกับที่ให้ผลลัพธ์ต่างกันบนแล็ปท็อปสองเครื่อง

บรรทัด scope ไม่ใช่ไวลด์การ์ด ชื่อที่อยู่นอก scope ยังคงใช้ค่าเริ่มต้น ซึ่งเป็นพฤติกรรมที่คุณต้องการสำหรับทุก Dependency ที่คุณไม่ได้เขียนเอง

ตรวจสอบว่าไฟล์แก้เป็นอะไรก่อน commit โดยใช้ชื่อแพ็กเกจชั่วคราวแทนการติดตั้งจริง เพื่อให้ความผิดพลาดไม่เสียอะไร

ข้อมูลรับรองเป็นของ host ไม่ใช่ของโปรเจกต์

รายการรับรองความถูกต้องผูกกับ host ของ registry และผูกกับพาธในที่ที่ registry ต้องการ นั่นคือเหตุผลที่บรรทัด token เริ่มด้วยเครื่องหมายสแลชคู่และ host ไม่ใช่ scope เมื่อคุณเห็น host ในตำแหน่งนั้น ส่วนที่เหลือของบรรทัดก็เลิกดูเหมือนเครื่องหมายวรรคตอนที่สุ่มขึ้น มันคือที่อยู่ และ token ถูกแนบไว้กับที่อยู่นั้น

การใช้ตัวแปรสภาพแวดล้อมทำให้ token ตามตัวอักษรอยู่นอกไฟล์ใน repository มันไม่ได้ทำให้ token ล่องหนทุกที่ มันยังปรากฏในสภาพแวดล้อมของโปรเซส และคำสั่งที่พิมพ์การกำหนดค่าอาจเปิดเผยมันได้

จัดหาตัวแปรผ่านกลไกข้อมูลรับรองภายในเครื่องหรือ CI ที่องค์กรอนุมัติ และอย่าวาง token จริงลงในตัวอย่างที่อาจถูกคัดลอกไปยังเอกสาร

ถ้ามี registry สองตัว แต่ละตัวมีรายการของตัวเอง การตั้งค่า token เดียวที่ไม่ระบุคุณสมบัติอย่างดีที่สุดก็คลุมเครือ และอย่างแย่ที่สุดก็ถูกส่งไปยัง host ผิด

เมื่อ registry ผิดเป็นผู้ชนะ

การกำหนดค่าเป็นชั้น ๆ และค่าที่มีผลไม่จำเป็นต้องเป็นค่าในไฟล์ที่คุณเพิ่งแก้ การตั้งค่าโปรเจกต์ การตั้งค่าผู้ใช้ การตั้งค่าระดับโลก และตัวแปรสภาพแวดล้อมล้วนมีส่วน การเป็นชั้นนี้คือเหตุผลที่การแก้ไขได้ผลบนเครื่องของคุณแต่ไม่ในคอนเทนเนอร์ของเพื่อนร่วมงาน และยังเป็นเหตุผลที่ควรพิมพ์ค่าที่มีผลก่อนจะเถียงกันเรื่องนี้

ตัวแปรสภาพแวดล้อมคือผู้ร้ายปกติใน CI ซึ่งงานหนึ่งตั้ง registry ครั้งเดียวแล้วทุกขั้นตอนหลังจากนั้นสืบทอดมันไป ที่พบบ่อยเป็นอันดับสองคือไฟล์ระดับผู้ใช้บนเครื่องของนักพัฒนาที่เขียนทับสิ่งที่ repository บอก

พิมพ์การกำหนดค่าที่มีผลและ registry ที่แก้ได้สำหรับชื่อที่มี scope หนึ่งชื่อและไม่มี scope หนึ่งชื่อก่อนแก้ปัญหาอย่างอื่น ถ้าคำตอบสองข้อนั้นเป็นอย่างที่คุณคาด ปัญหาคือเครือข่าย ถ้าไม่ใช่ ปัญหาคือการกำหนดค่าและงาน VPN เท่าไรก็ไม่ช่วย

รายการตรวจสอบก่อน commit

ยืนยันว่าชื่อ scope ตรงกับแพ็กเกจที่เผยแพร่จริง registry ค่าเริ่มต้นชัดเจน และบรรทัด token ระบุ host ที่ถูกต้อง การพิมพ์ผิดใน scope ทำให้เกิดความล้มเหลวที่แปลกที่สุด เพราะแพ็กเกจแก้จาก registry สาธารณะและคืน module ของคนอื่นที่ชื่อเดียวกัน ตรวจชื่อก่อนจะแก้ token

ยืนยันว่า registry ส่วนตัวเข้าถึงได้จากเครื่องในบริบทที่รันการติดตั้ง ไม่ใช่แค่จากเบราว์เซอร์ของคุณ ความแตกต่างนั้นสำคัญเมื่อ proxy หรือคอนเทนเนอร์มีเส้นทางต่างจาก shell ของคุณ

จากนั้นยืนยันพฤติกรรมบน checkout สะอาดที่ไม่มีแพ็กเกจแคช การติดตั้งใหม่คือการทดสอบเดียวที่แสดงว่าคนใหม่จะพบอะไร

บทความที่เกี่ยวข้อง