Auto: حقن $ NPM_TOKEN في .npmrc للمستخدم

أيضًا ، لماذا لم يتم التحقق من process.env.NPM_TOKEN ، مثل GH_TOKEN ؟

هل يمكن أن يضخ $ auto-release $NPM_TOKEN في .npmrc للمستخدم؟ (يحتمل أن يكون مفيدًا في تصميمات CI)

هذا شيء خاص بمؤسسة GitHub. يمكن لـadierkens إخبارك بالمزيد لأنني لم أواجهها.

هل يمكن للإصدار التلقائي حقن $ NPM_TOKEN في .npmrc للمستخدم؟ (يحتمل أن يكون مفيدًا في تصميمات CI)

أحب هذا. يجب أن تكون قادرة على القيام به

ربما يجب تمكين هذه الميزة فقط على CI. إذا كان سيتم تشغيله محليًا ، فقد تلتزم بالرمز عن طريق الخطأ.

هل ستحقق هذه الحزمة السلوك المطلوب الذي تبحث عنه؟

https://www.npmjs.com/package/@hutson/set -npm-auth-token-for-ci

بالتأكيد ، لكن إلقاء نظرة على الكود المصدري يكشف عن تطبيق أساسي للغاية ، لذلك سيكون من الأفضل تضمينه في auto-release بدلاً من إجبار المستخدم على تثبيت تبعية أخرى.

يبدو أنه يفعل ما يفعله جيدًا على الرغم من:

• يتعامل مع ملفات rc في مواقع متعددة على أي نظام تشغيل (باستخدام local-or-home-npmrc)
• يتحقق مما إذا تم تعيين الرمز المميز بالفعل
• يتعامل مع التسجيل الذي يتم تعيينه في package.json
• يعالج تكوين نطاق npmrc بشكل صحيح (باستخدام عنوان url الخاص بالسجل)

هذه مجموعة من الوظائف التي إذا أردنا تغطية جميع حالات الاستخدام ، فسيتعين علينا ترميز كل ما سبق أيضًا (أو على الأقل استخدام نفس الحزم).

في حالات قليلة أخرى ، نفعل نفس الشيء أيضًا. نرجئ تحليل المؤلف لتحليل المؤلف git بشكل صحيح و parse-github-url لعنوان URL الخاص بـ github. لذلك لن يكون استخدام حزمة للقيام بذلك أمرًا ممتدًا.

أحب أيضًا الاعتماد على حزم مثل هذه حتى يقل تكرار الكود في العالم. أي باستخدام هذه الحزمة وإيجاد مشاكل معها ، يمكننا حل المشكلات للمطورين في المستقبل أيضًا!

مشكلتي الرئيسية مع الحزمة هي كيفية قيامهم أيضًا بشحن CLI مع واجهة برمجة التطبيقات. لذلك فتحت قضية هنا

في غضون ذلك ، يجب أن نفترق الحزمة (وربما حتى نفتح PR). 😁

نعم ، أخطط لعمل علاقات عامة! فقط أريد أن أعرف ما يود المؤلف. ولكن ربما يكون أفضل مسار لهذه الحزمة هو القيام بالأمرين معًا: إنشاء monorepo واستخدام مكتبة CLI أصغر

المشرف نفذ هذا بالفعل! https://gitlab.com/hyper-expanse/open-source/set-npm-auth-token-for-ci/issues/2