npm মুছে ফেলার পরেও কেন এখনও একটি প্রক্সি আছে
npm একাধিক কনফিগারেশন উৎস পড়ে। একটি ফাইল থেকে এন্ট্রি সরানো বা Node পুনরায় ইনস্টল করলে অন্য একটি উৎস কার্যকর থাকতে পারে।
আপনি npm-এর প্রক্সি মুছে ফেলেন, আবার জিজ্ঞাসা করেন, আর মানটি তখনও রয়েছে। আরও বেশি বিশেষাধিকার নিয়ে কমান্ডটি পুনরাবৃত্তি করার আগে দেখুন আপনি কোন কনফিগারেশন মুছেছেন।
একটি প্রকল্পের .npmrc, একটি ব্যবহারকারী ফাইল, গ্লোবাল কনফিগারেশন, কমান্ড অপশন এবং এনভায়রনমেন্ট সেটিংস—সবই গুরুত্বপূর্ণ হতে পারে। এক জায়গা থেকে একটি মান সরালে তার নিচের অন্য একটি মান প্রকাশিত হতে পারে।
পরিবর্তনের আগে মানটি খুঁজে বের করুন
npm-এর কার্যকর কনফিগারেশন এবং সেই আহ্বানের সাথে সম্পর্কিত ফাইলগুলি পরীক্ষা করুন। কাজটি প্রকল্প-স্থানীয় না গ্লোবাল, সেদিকে মন দিন। একটি প্রকল্প সেটিং গ্লোবাল ইনস্টলেশনের প্রমাণ নয়।
প্রক্সি অপশনের নামগুলিও গুরুত্বপূর্ণ। http_proxy-এর মতো একটি কাস্টম কী স্বয়ংক্রিয়ভাবে নথিভুক্ত proxy অপশন নয়। এনভায়রনমেন্ট-ভেরিয়েবলের বানান এবং npm কনফিগারেশন-কীর বানান আলাদা ইন্টারফেস।
এক্সিকিউটেবলটি পুনরায় ইনস্টল করা অপ্রাসঙ্গিক
Node-এর ইনস্টলেশন ডিরেক্টরি অবশ্যই আপনার ব্যবহারকারী কনফিগারেশন থাকার জায়গা নয়। এক্সিকিউটেবলটি প্রতিস্থাপন করলে ব্যবহারকারী ফাইল এবং প্রসেস এনভায়রনমেন্ট অক্ষত থাকতে পারে। এজন্যই একটি পরিচ্ছন্ন প্রোগ্রাম ইনস্টলেশন সঙ্গে সঙ্গে পুরনো নেটওয়ার্ক এন্ডপয়েন্ট দেখাতে পারে।
উৎসটি খুঁজে পেলে সেই স্তরে পুরনো এন্ট্রিটি সরান। তারপর যে কাজের ডিরেক্টরি ও অ্যাকাউন্ট ব্যর্থতা তৈরি করেছিল, সেখান থেকেই কার্যকর মানটি আবার জিজ্ঞাসা করুন। ইনস্টল করা npm সেই অর্থ নথিভুক্ত না করলে ইচ্ছামতো খালি বা null-সদৃশ স্ট্রিং সেট করা এড়িয়ে চলুন।
registry সেটিংটি আলাদা রাখুন। একটি স্থানীয় registry URL প্রক্সি ঠিকানার মতো দেখাতে পারে, কিন্তু এটি মুছে ফেললে প্যাকেজ মেটাডেটা কোথা থেকে অনুরোধ করা হবে তা বদলে যায়। শুধু একটি অবাঞ্ছিত ফরোয়ার্ডিং প্রক্সি সরানোর জন্য প্রয়োজনীয় অভ্যন্তরীণ registry মুছবেন না।