ထည့်သွင်းရေး script များ ဒေါင်းလုဒ်လုပ်စဉ် npm proxy မအောင်မြင်မှုများ

npm ထည့်သွင်းမှုသည် registry ဒေါင်းလုဒ်ကို ကျော်ပြီး ထည့်သွင်း script တွင် ရပ်တန့်ပါက ဒုတိယ ဒေါင်းလုဒ်လုပ်သူကို ဖော်ထုတ်ပါ။ JavaScript package သည် ရှိပြီးသား ဖြစ်နိုင်ပြီး ၎င်း၏ platform သီးသန့် binary မှာ မရှိသေးပါ။

1. log တွင် တောင်းဆိုမှု၏ ပိုင်ရှင်ကို ရှာပါ။ lifecycle script၊ executable သို့မဟုတ် HTTP library၊ ဦးတည် host အမည်နှင့် ပထမ အမှားကို မှတ်တမ်းတင်ပါ။ package တစ်ခုသည် npm registry လွှဲပြောင်းမှုနှင့် သီးခြားဖြစ်သော ဒေါင်းလုဒ်ရှိသည့် အခြား program တစ်ခုကို စတင်နိုင်သည်။
2. ထို ဒေါင်းလုဒ်လုပ်သူ ပံ့ပိုးသော proxy interface ကို အသုံးပြုပါ။ tfjs-node ၏ resources.js လမ်းကြောင်းအတွက် child process ၏ proxy ပတ်ဝန်းကျင် သည် တိကျသော ဥပမာတစ်ခု ဖြစ်သည်။ package ၏ မှတ်တမ်းတင်ထားသော ဒေါင်းလုဒ် ဆက်တင်များနှင့် တောင်းဆိုမှု ပြုလုပ်နေသော process ၏ ပတ်ဝန်းကျင်ကို စစ်ဆေးပါ။ စံ proxy variable သည် ထို အသုံးပြုသူက ၎င်းကို ဖတ်မှသာ အထောက်အကူ ဖြစ်သည်။ အလားတူ အမည်ရှိ variable များ ထည့်ခြင်းက ပံ့ပိုးမှုကို မသက်သေပြပါ။
3. artifact ၏ အမှန်တကယ် လမ်းကြောင်းကို လိုက်နာပါ။ ထုတ်ဝေရေး ဆာဗာများ၊ object store များနှင့် လမ်းကြောင်းပြောင်း ဦးတည်ချက်များသည် registry နှင့် ကွဲပြားနိုင်သည်။ မအောင်မြင်သော တောင်းဆိုမှုအတွက် proxy အတည်ပြုခြင်း၊ ခွင့်ပြုထားသော ဦးတည်ချက်များနှင့် TLS ယုံကြည်မှုကို နှိုင်းယှဉ်ပါ။

cache များ မရှင်းလင်းမီ ဤသို့ ပြုလုပ်ပါ- log တွင် package ရယူခြင်းမှ lifecycle လုပ်ဆောင်ခြင်းသို့ ကူးပြောင်းမှုက ချို့ယွင်းချက်ကို ကျဉ်းမြောင်းစေပြီး ဖြစ်သည်။ registry သို့ အောင်မြင်စွာ ဝင်ရောက်ခြင်းသည် အသုံးဝင်သော နှိုင်းယှဉ် အထောက်အထား ဖြစ်သော်လည်း ဒုတိယ program သည် တူညီသော လမ်းကြောင်းကို ပံ့ပိုးသည်ဟု သော်လည်းကောင်း ၎င်း၏ artifact host သို့ ရောက်နိုင်သည်ဟု သော်လည်းကောင်း မသက်သေပြပါ။

ထည့်သွင်း script များကို ပိတ်ခြင်းက ဒေါင်းလုဒ်ကို ကျော်သွားစေပြီး package ကို အသုံးမပြုနိုင်အောင် ထားနိုင်သည်။ package သည် ခွင့်ပြုထားသော ကြိုတင်တည်ဆောက်ထားသော သို့မဟုတ် အော့ဖ်လိုင်း ထည့်သွင်းလမ်းကြောင်းကို မှတ်တမ်းတင်ထားပါက ထို artifact ကို ရည်ရွယ်ချက်ရှိရှိ ပြင်ဆင်ပြီး ထည့်သွင်းမှုကို ပြီးစီးသည်ဟု မသတ်မှတ်မီ executable ရနိုင်ကြောင်း အတည်ပြုပါ။