ໃຫ້ໂຮສທີ່ເລືອກໃນ Yarn ສະໄໝໃໝ່ໃຊ້ພຣັອກຊີອື່ນ

ພຣັອກຊີທົ່ວໄປອັນດຽວອາດບໍ່ເໝາະກັບທຸກແຫຼ່ງແພັກເກດ. Yarn ສະໄໝໃໝ່ຮອງຮັບການຕັ້ງຄ່າເຄືອຂ່າຍຕາມຊື່ໂຮສ ຈຶ່ງເຮັດໃຫ້ໂຮສທີ່ເລືອກສາມາດໃຊ້ເສັ້ນທາງຕ່າງຈາກຄ່າເລີ່ມຕົ້ນໄດ້.

ຕົວຢ່າງ, ໂຄງການສາມາດເກັບເສັ້ນທາງທົ່ວໄປໄວ້ໜຶ່ງເສັ້ນ ແລ້ວເລືອກອີກເສັ້ນໜຶ່ງສຳລັບ registry ພາຍໃນ:

httpsProxy: "http://203.0.113.10:8080"
networkSettings:
  "registry.example.internal":
    httpsProxy: "http://203.0.113.20:8080"

ທັງສອງທີ່ຢູ່ເປັນຕົວຢ່າງບ່ອນວາງ. ສຳລັບເສັ້ນທາງທົ່ວໄປໄປຫາແຫຼ່ງແພັກເກດສາທາລະນະ, ບັນຊີພຣັອກຊີ HTTP ສະເໜີຕົວເລືອກ ເມື່ອອະນຸຍາດໃຫ້ໃຊ້ພຣັອກຊີສາທາລະນະ. ໃຫ້ເກັບ override ຂອງ registry ພາຍໃນໄວ້ໃນພຣັອກຊີທີ່ໄດ້ຮັບອະນຸມັດ. ໃສ່ການຕັ້ງຄ່າໃນ .yarnrc.yml ທີ່ເໝາະສຳລັບ ລຸ້ນ Yarn ສະໄໝໃໝ່. ຕົວຢ່າງນີ້ເລືອກສອງພຣັອກຊີ; ມັນບໍ່ໄດ້ບອກວ່າໂຮສພາຍໃນຄວນເຊື່ອມຕໍ່ໂດຍກົງ.

ຈັບຄູ່ຊື່ໂຮສທີ່ຮ້ອງຂໍ

ລາຍການ networkSettings ໃຊ້ກັບຮູບແບບຊື່ໂຮສ ບໍ່ແມ່ນ scope ຂອງແພັກເກດ ຫຼື ເສັ້ນທາງ URL ຕາມອຳເພີໃຈ. ເກັບກົດສຳລັບໂຮສດຽວໃຫ້ແທ້ຄັດ ເມື່ອນັ້ນແມ່ນສິ່ງທີ່ຕ້ອງການ. wildcard ມີປະໂຫຍດກໍ່ຕໍ່ເມື່ອຕັ້ງໃຈໃຫ້ໂຮສເພີ່ມເຕີມໃຊ້ການຕັ້ງຄ່າດຽວກັນແທ້ໆ.

scope ຂອງແພັກເກດ ແລະ ຊື່ໂຮສເຄືອຂ່າຍເປັນຕົວເລືອກທີ່ແຕກຕ່າງກັນ. ແພັກເກດແບບ scoped ສາມາດດຶງຈາກ registry ທີ່ໂຮສຖືກແບ່ງປັນກັບແພັກເກດອື່ນ, ໃນຂະນະທີ່ artifact ທີ່ຖືກປ່ຽນທາງອາດມາຈາກຊື່ໂຮສອື່ນໂດຍສິ້ນເຊີງ.

ຕິດຕາມເສັ້ນທາງດາວໂຫຼດທັງໝົດ

ຖ້າ metadata ໃຊ້ໂຮສໜຶ່ງ ແລະ ການດາວໂຫຼດ archive ໃຊ້ອີກໂຮສໜຶ່ງ, ພວກມັນອາດຈັບຄູ່ກັບການຕັ້ງຄ່າເຄືອຂ່າຍຕ່າງກັນ. ບັນທຶກ URL ທີ່ລົ້ມເຫຼວຈິງ ກ່ອນທີ່ຈະຂະຫຍາຍກົດ. “registry ເຮັດວຽກໄດ້” ບໍ່ໄດ້ພິສູດວ່າຄຳຮ້ອງຕໍ່ມາເລືອກເສັ້ນທາງໃດ.

ການຕັ້ງຄ່າຕໍ່ໂຮສຂອງ Yarn ຍັງອາດລວມ CA ແລະ ການຕັ້ງຄ່າ TLS ອື່ນໆ. ເກັບການຕັດສິນໃຈເຫຼົ່ານັ້ນໄວ້ແຍກກັນ: ການເລືອກທີ່ຢູ່ພຣັອກຊີບໍ່ໄດ້ໃຫ້ຄວາມໄວ້ໃຈທີ່ຈຳເປັນສຳລັບ ສະພາບແວດລ້ອມທີ່ກວດສອບ ດ້ວຍຕົວມັນເອງ.

ເຮັດໃຫ້ override ເຫັນໄດ້

ກວດເບິ່ງການຕັ້ງຄ່າທີ່ມີຜົນຂອງໂຄງການດ້ວຍເຄື່ອງມືທີ່ລຸ້ນ Yarn ຂອງມັນຮອງຮັບ ແລ້ວທົດສອບຄຳຮ້ອງທີ່ຕັ້ງໃຈ. ຫຼີກລ່ຽງການແບ່ງປັນ dump ການຕັ້ງຄ່າເຕັມຮູບແບບ ຖ້າມັນມີຂໍ້ມູນຢືນຢັນຕົວຕົນ.

ຄຸນສົມບັດນີ້ມີປະໂຫຍດເມື່ອໂຮສຕ້ອງການເສັ້ນທາງຕ່າງກັນແທ້ໆ. ຖ້າທຸກຄຳຮ້ອງຄວນໃຊ້ endpoint ດຽວກັນ, ການຕັ້ງຄ່າທົ່ວໄປອັນດຽວງ່າຍຕໍ່ການຮັກສາກວ່າບັນຊີ override ຊື່ໂຮສທີ່ຄືກັນທີ່ເພີ່ມຂຶ້ນເລື້ອຍໆ.