सार्वजनिक गैर-स्कोप्ड पैकेजों के लिए सिमेंटिक रिलीज़ कैसे लागू करें

GitHub Actions की शक्ति का लाभ उठाते हुए सिमेंटिक रिलीज़ का उपयोग करके एक गैर-स्कोप्ड सार्वजनिक पैकेज प्रकाशित करने पर विस्तृत निर्देश

उभरते सॉफ़्टवेयर विकास परिदृश्य में, संस्करण स्थिरता बनाए रखना और रिलीज़ प्रक्रिया को स्वचालित करना पहले से कहीं अधिक महत्वपूर्ण है। प्रवेश करना सिमेंटिक रिलीज : स्पष्ट और संरचित संस्करण सुनिश्चित करने के लिए डिज़ाइन किया गया एक उपकरण। सार्वजनिक गैर-स्कोप्ड पैकेजों का लाभ उठाने वाले डेवलपर्स के लिए, यह प्रक्रिया कठिन लग सकती है। हालाँकि, हमारी उंगलियों पर GitHub क्रियाओं की शक्ति के साथ, स्वचालन आसान हो जाता है।

यह आलेख एक विस्तृत और व्यापक मार्गदर्शिका प्रदान करता है, जो आपके वर्कफ़्लो में सिमेंटिक रिलीज़ को सहजता से एकीकृत करने के लिए चरण-दर-चरण निर्देश प्रदान करता है, विशेष रूप से सार्वजनिक गैर-स्कोप्ड पैकेज का उपयोग करने वालों के लिए तैयार किया गया है। इसमें गोता लगाएँ और सॉफ़्टवेयर रिलीज़ के लिए सुव्यवस्थित दृष्टिकोण की खोज करें।

जब मैंने अपना बनाया सार्वजनिक पैकेज , मुझे इसे एनपीएम पर निर्बाध रूप से प्रकाशित करने में बाधाओं का सामना करना पड़ा। सही कॉन्फ़िगरेशन सुनिश्चित करना एक चुनौती थी।

इसे समझने के लिए, आइए सार्वजनिक पैकेजों को उचित रूप से प्रकाशित करने के लिए चरण-दर-चरण अनुभव से गुजरें NPM .

सामग्री अवलोकन

• पैकेज को नाम दें
• एक पैकेज बनाएं
• पैकेज स्रोत
• टोकन
• GitHub क्रियाएँ सेटअप
• सिमेंटिक रिलीज
• प्रतिबद्ध प्रारूप
• प्रकाशित पैकेज
• निष्कर्ष

पैकेज को नाम दें

हमारे पैकेज को लागू करने से पहले, इसके लिए उचित नाम ढूंढना बेहतर होगा। यह सुनिश्चित करने के लिए कि नाम पहले ही नहीं लिया गया है - my_package_name जांचें और इसे अपने पैकेज के लिए लें। मैंने "टोकी" चुना। उस बिंदु से, पैकेज का नाम आरक्षित करना असंभव है। npm में नाम के लिए आपको पैकेज प्रकाशित करना होगा।

एक पैकेज बनाएं

इसका उद्देश्य एक सीधा पैकेज विकसित करना है जो सामग्री को कंसोल पर आउटपुट करता है। हमें यह सुनिश्चित करना होगा कि हम इसे स्थापित कर सकें और चला सकें। निर्माण प्रक्रिया के लिए, आइए सरल का उपयोग करें esbuild .

इस लेख के दौरान, मैं पैकेज tokky के नाम का उपयोग करूंगा। आइए प्रारंभिक डेटा के साथ package.json बनाएं।

 mkdir tokky && cd tokky && npm init -y

कमांड निष्पादित करने के बाद, सिस्टम ने प्रोजेक्ट के लिए एक डिफ़ॉल्ट package.json फ़ाइल तैयार की, जो इस तरह दिखती है:

 { "name": "tokky", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC" }

इस गाइड में, package.json फ़ाइल सही कॉन्फ़िगरेशन सुनिश्चित करने में महत्वपूर्ण भूमिका निभाती है। इस समय, आइए अपने पैकेज के लिए नोड संस्करण निर्दिष्ट करें:

 echo "v18" > .nvmrc

और निर्दिष्ट संस्करण को निम्नलिखित के साथ सक्रिय करें:

 nvm use

README.md फ़ाइल के लिए:

 echo "# Tokky\n\nA simple zero dependency logger for node js." > README.md

अंत में, विकास निर्भरताएँ स्थापित करें:

 npm i -D esbuild eslint prettier

हमारे प्रारंभिक कॉन्फ़िगरेशन में, हमें package.json में कई प्रमुख बिंदुओं को संबोधित करने की आवश्यकता है:

• main : यह मॉड्यूल के लिए प्राथमिक प्रवेश बिंदु निर्दिष्ट करता है।
• bin : यहां, आप अपने मॉड्यूल द्वारा प्रदान किए गए किसी भी निष्पादन योग्य को निर्दिष्ट करेंगे।
• files : इसमें फ़ाइल पैटर्न की एक श्रृंखला होनी चाहिए जिसे पैकेज पैक होने पर शामिल किया जाएगा और बाद में एनपीएम रजिस्ट्री में प्रकाशित किया जाएगा।
• private : सुनिश्चित करें कि यह false पर सेट है क्योंकि हमारा पैकेज सार्वजनिक होना है।
• publishConfig : इसके लिए एक्सेस को public पर सेट किया जाना चाहिए।

इन कॉन्फ़िगरेशन के बाद, आपका package.json निम्नलिखित जैसा होना चाहिए:

 { "name": "tokky", "version": "1.0.0", "description": "Node js logger package", "main": "dist/index.js", "scripts": { "build": "esbuild src/index.js --bundle --platform=node --format=cjs --minify --outfile=dist/index.js", }, "files": [ "dist" ], "bin": { "tokky": "./dist/index.js" }, "keywords": [ "logger", "nodejs", "tokky" ], "private": false, "author": { "name": "Anton Kalik", "email": "[email protected]", "url": "https://idedy.com" }, "publishConfig": { "access": "public" }, "license": "MIT", "engines": { "node": "18.xx" }, "devDependencies": { "esbuild": "^0.19.2", "eslint": "^8.49.0", "prettier": "^3.0.3" } }

प्रारंभिक सेटअप के बाद package.json

इसके अतिरिक्त, आइए दो इग्नोर फ़ाइलें जोड़ें:

 .idea node_modules dist

.gitignore

और एनपीएम के लिए:

 .idea /src/ /node_modules/ /test/ /.nvmrc .github/

.npmignore

अंत में, मैं ESLint के लिए अपने सेटअप की रूपरेखा तैयार करूंगा। हालाँकि, याद रखें कि कॉन्फ़िगरेशन आपके पैकेज की विशिष्ट आवश्यकताओं के आधार पर भिन्न हो सकता है।

 module.exports = { env: { browser: true, commonjs: true, es2021: true, node: true, }, extends: "eslint:recommended", overrides: [ { env: { node: true, }, files: ["src/**/*.js", ".eslintrc.{js,cjs}"], parserOptions: { sourceType: "script", }, }, ], parserOptions: { ecmaVersion: "latest", }, rules: {}, };

.eslintrc.js कॉन्फ़िगरेशन

इसके बाद, GitHub पर जाएं और एक नया रिपॉजिटरी स्थापित करें। इसे अपने पैकेज के नाम पर रखें.

निम्नलिखित आदेशों को निष्पादित करके आगे बढ़ें:

 git init git add . git commit -m "first commit" git branch -M main git remote add origin [email protected]:<your_github_username>/tokky.git git push -u origin main

पैकेज स्रोत

इसके बाद, आइए एक बुनियादी एप्लिकेशन तैयार करें और इसे निर्माण के लिए सेट करें। src फ़ोल्डर के अंदर, एक index.js फ़ाइल बनाएं और उसे निम्नलिखित सामग्री से भरें:

 #!/usr/bin/env node const os = require('os'); const username = os.userInfo().username; if (process.argv[2] === 'hi') { console.log(`Hello ${username}`); }

पैकेज उदाहरण के लिए सरल स्क्रिप्ट

अवधारणा सीधी है: my_package_name hi निष्पादित करने पर "हैलो [उपयोगकर्ता नाम]" प्रदर्शित होना चाहिए।

इस कार्यक्षमता को सत्यापित करने के लिए, सीधे अपने रिपॉजिटरी से कमांड निष्पादित करें:

 node src/index.js hi

यदि आउटपुट अपेक्षाओं के अनुरूप है, तो स्रोत बनाने का समय आ गया है:

 npm run build

इस कमांड को सफलतापूर्वक चलाने से एक dist फ़ोल्डर तैयार हो जाएगा जिसमें एक मिनिफाइड index.js फ़ाइल होगी।

टोकन

सिमेंटिक रिलीज़ निष्पादित करें, जो संस्करण बाधाओं को निर्धारित करेगा और प्रतिबद्ध संदेशों के आधार पर रिलीज़ प्रक्रिया को संभालेगा, सही ढंग से संचालित करने के लिए पर्यावरण चर ( GITHUB_TOKEN , NPM_TOKEN ) की आवश्यकता होती है। टोकन GitHub रहस्यों से प्राप्त किए जाते हैं, यह सुनिश्चित करते हुए कि वे गोपनीय रहें।

GITHUB_TOKEN सेट करने के लिए, यहां नेविगेट करें: https://github.com/settings/tokens

ड्रॉपडाउन का उपयोग करके टोकन जेनरेट करें। नए व्यक्तिगत एक्सेस टोकन (क्लासिक) पर क्लिक करें और चित्र के अनुसार अनुमति सेट करें।

नीचे दिखाए अनुसार अपने पैकेज नाम का उपयोग करें:

एक बार जेनरेट होने के बाद, टोकन मूल्य की प्रतिलिपि बनाएँ और इसे गोपनीय रखें - यह महत्वपूर्ण है कि इसे दूसरों के साथ साझा न करें। इस टोकन को अस्थायी रूप से सुरक्षित रूप से संग्रहीत करें, क्योंकि सिमेंटिक रिलीज़ सीएलआई के लिए हमें शीघ्र ही इसकी आवश्यकता होगी।

NPM_TOKEN जनरेट करने के लिए, आपको सबसे पहले एक खाते की आवश्यकता होगी एनपीएम की आधिकारिक वेबसाइट . यदि आपने अभी तक पंजीकरण नहीं कराया है, तो पंजीकरण प्रक्रिया से गुजरें। उसके बाद, यहां नेविगेट करें:

 https://www.npmjs.com/settings/<your_user_name>/tokens/new

और "प्रकाशित करें" विकल्प के साथ एक "क्लासिक" टोकन उत्पन्न करें।

टोकन के उत्पन्न मूल्य की प्रतिलिपि बनाएँ और GitHub रहस्यों पर नेविगेट करें:

 https://github.com/<your_user_name>/<your_repo_name>/settings/secrets/actions/new

और रिपॉजिटरी रहस्यों में NPM_TOKEN के रूप में नया रहस्य डालें:

अब हमारे रहस्य स्थापित होने के साथ, हम GitHub क्रियाओं को कॉन्फ़िगर कर सकते हैं।

GitHub क्रियाएँ सेटअप

अपनी प्रक्रियाओं को स्वचालित करने के लिए, हम GitHub Actions का उपयोग करने जा रहे हैं। यह GitHub के भीतर एकीकृत एक CI/CD उपकरण है। यह डेवलपर्स को अपने GitHub रिपॉजिटरी से सीधे वर्कफ़्लो को स्वचालित करने की अनुमति देता है, जैसे कि एप्लिकेशन बनाना, परीक्षण करना और तैनात करना। YAML फ़ाइलों में वर्कफ़्लो को परिभाषित करके, उपयोगकर्ता विशिष्ट घटनाओं जैसे पुश और पुल अनुरोधों या निर्धारित समय के आधार पर क्रियाओं को ट्रिगर कर सकते हैं, जिससे सॉफ़्टवेयर विकास प्रक्रिया अधिक कुशल और स्वचालित हो जाती है।

आरंभ करने के लिए, अपने प्रोजेक्ट के मूल में एक .github निर्देशिका बनाएं। इस निर्देशिका के भीतर, एक workflows सबफ़ोल्डर स्थापित करें।

यहां, हमारी कॉन्फ़िगरेशन फ़ाइल को release.yml नाम से तैयार करें और इसे निम्नलिखित सामग्री से भरें:

 name: Release package on: push: branches: - main jobs: release: runs-on: ubuntu-latest if: ${{ github.ref == 'refs/heads/main' }} steps: - name: Checkout uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: "18" - name: Install dependencies run: npm ci - name: Build run: npm run build - name: Semantic Release run: npm run semantic-release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

यह वर्कफ़्लो मुख्य शाखा में एक पुश इवेंट ट्रिगर करता है। इसे नवीनतम Ubuntu वर्चुअल मशीन GitHub पर कार्य चलाने के लिए कॉन्फ़िगर किया गया है। हालाँकि हर काम में गहराई से जाना ज़रूरी नहीं है, आइए कुछ विशिष्ट कामों पर प्रकाश डालें। अंत में, ध्यान दें कि हम निर्दिष्ट टोकन का उपयोग करके npm run semantic-release कैसे शुरू करते हैं।

सिमेंटिक रिलीज

स्वचालित रिलीज़ प्रक्रिया के लिए, हम सिमेंटिक रिलीज़ का उपयोग करने जा रहे हैं। यह उपकरण प्रतिबद्ध संदेश शब्दार्थ के आधार पर संस्करण और पैकेज प्रकाशन को संभालता है। यह संस्करण बाधाओं (प्रमुख, लघु, या पैच) को निर्धारित करने के लिए सिमेंटिक वर्जनिंग (सेमवीर) की परंपराओं का पालन करता है। प्रतिबद्ध संदेशों का विश्लेषण करके यह संस्करणीकरण के मैन्युअल चरणों को समाप्त करता है, सुसंगत संस्करण संख्या सुनिश्चित करता है, और रिलीज़ प्रक्रिया को सुव्यवस्थित करता है। आइए इसे सेट करें.

उस सेटअप के लिए, हम उपयोग करेंगे यह GitHub कोड और इसे अपने भंडार पर चलाएँ:

 npx semantic-release-cli setup

और प्रश्नों का पालन करें:

 % npx semantic-release-cli setup ? What is your npm registry? https://registry.npmjs.org/ ? What is your npm username? your_user_name ? What is your npm password? [hidden] ? What is your NPM two-factor authentication code? 00000000 ? Provide a GitHub Personal Access Token (create a token at https://github.com/s ettings/tokens/new?scopes=repo) ghp_your_token_here ? What CI are you using? Github Actions

आपके पास पहले से ही आपका व्यक्तिगत टोकन होना चाहिए। संकेत मिलने पर बस इसे इनपुट करें। इसी प्रकार, हमारे द्वारा स्थापित GitHub क्रियाएँ NPM_TOKEN उपयोग करेंगी जिन्हें हमने पहले रिपॉजिटरी रहस्यों में स्थापित किया है। यदि आप अब अपना package.json जांचते हैं, तो संस्करण इस प्रकार प्रदर्शित होगा:

 "version": "0.0.0-development",

और नई स्क्रिप्ट:

 "semantic-release": "semantic-release"

जो सिमेंटिक रिलीज़ सीएलआई द्वारा स्वतः उत्पन्न हुआ था। हमें इस स्क्रिप्ट को इस प्रकार बढ़ाने की आवश्यकता होगी:

 "semantic-release": "semantic-release --branches main"

यह इंगित करता है कि रिलीज़ केवल मुख्य शाखा से ही की जाएगी।

इसके अतिरिक्त, सिमेंटिक रिलीज़ आपके package.json में repository फ़ील्ड के आधार पर एक विवरण तैयार करता है। यह फ़ील्ड पैकेज के स्रोत कोड के स्थान के बारे में विवरण प्रदान करता है।

 "repository": { "type": "git", "url": "https://github.com/<your_github_username>/your_github_repo.git" }

अब, आइए अपने सभी परिवर्तनों को आगे बढ़ाएं:

 git add . && git commit -m "semantic release" && git push

प्रतिबद्ध प्रारूप

सिमेंटिक रिलीज़ संस्करण बम्प (प्रमुख, लघु, या पैच) के प्रकार को निर्धारित करने और चेंजलॉग उत्पन्न करने के लिए संरचित प्रतिबद्ध संदेशों के सम्मेलन पर निर्भर करता है। इस प्रतिबद्ध सम्मेलन को अक्सर "पारंपरिक प्रतिबद्धताएं" प्रारूप कहा जाता है।

इस कॉन्फ़िगरेशन के लिए, हमें कई प्लगइन्स की आवश्यकता होगी। सुनिश्चित करें कि आपके package.json में निम्नलिखित सामग्री शामिल है:

 "release": { "branches": [ { "name": "main" } ], "plugins": [ [ "@semantic-release/commit-analyzer", { "releaseRules": [ { "type": "feat", "release": "minor" }, { "type": "fix", "release": "patch" }, { "type": "refactor", "release": "patch" }, { "type": "build", "release": "patch" }, { "type": "chore", "release": "patch" }, { "type": "minor", "release": "patch" } ] } ], "@semantic-release/release-notes-generator", "@semantic-release/npm", "@semantic-release/github", [ "@semantic-release/changelog", { "changelogFile": "CHANGELOG.md" } ] ] }

package.json

सेटअप कमिट फॉर्मेट टूल के लिए, हम उपयोग करने जा रहे हैं प्रतिबद्ध . इसे स्थापित करने के लिए, इस आदेश का पालन करें:

 npx commitizen init cz-conventional-changelog --save-dev --save-exact

इस आदेश में कुछ मिनट लगेंगे. फिर अपने package.json एक नई स्क्रिप्ट के साथ अपडेट करें:

 "scripts": { // ... "commit": "cz" },

और अब उस स्क्रिप्ट का उपयोग करने का समय आ गया है। git add . , फिर npm run commit चलाएं और अपने कमिट के लिए आवश्यक विवरण प्रदान करें।

यह ऐसा दिखता है:

 ? Select the type of change that you're committing: feat: A new feature ? What is the scope of this change (eg component or file name): (press enter to skip) commit ? Write a short, imperative tense description of the change (max 86 chars): (14) add commitizen ? Provide a longer description of the change: (press enter to skip) ? Are there any breaking changes? No ? Does this change affect any open issues? No

उसके बाद, एक git push करें।

GitHub क्रियाओं में, आप देखेंगे कि हमारी प्रतिबद्धता विफल हो गई क्योंकि हमने अभी भी स्वचालित प्रतिबद्ध संदेश प्रक्रिया के लिए शेष पैकेज स्थापित नहीं किए हैं।

 npm i -D @semantic-release/commit-analyzer @semantic-release/release-notes-generator @semantic-release/npm @semantic-release/changelog

एक महत्वपूर्ण कदम, जिसे अधिकांश संदर्भों में अक्सर अनदेखा कर दिया जाता है, वर्कफ़्लो अनुमतियाँ सेट करना है। https://github.com/<your_user_name>/tokky/settings/actions पर नेविगेट करें और GitHub क्रियाओं को पढ़ने और लिखने दोनों की अनुमति देने के लिए अनुमतियों को कॉन्फ़िगर करें।

आगे, आइए चीजों को थोड़ा बदलें। अपने संदेश के बाद एक विशिष्ट कीवर्ड, feat: के साथ प्रतिबद्ध हों।

 git add . && git commit -m "feat: my feature commit" && git push

क्या आपको package.json के अंतर्गत releaseRules याद हैं? ये नियम तय करते हैं कि हम अपने पैकेज रिलीज़ के संस्करण को कैसे बढ़ाएँ। इसके साथ, आप विशिष्ट कीवर्ड जैसे feat , fix , refactor इत्यादि का उपयोग करके एक पुल अनुरोध बना सकते हैं। एक बार जब यह पुल अनुरोध स्वीकृत हो जाता है और बाद में मुख्य शाखा में विलय हो जाता है, तो यह एक ट्रिगर शुरू कर देगा। यह ट्रिगर फिर GitHub क्रिया को सक्रिय करता है, रिलीज़ प्रक्रिया को स्वचालित करता है, और सुनिश्चित करता है कि आपका पैकेज निर्बाध रूप से अपडेट किया गया है।

प्रकाशित पैकेज

पैकेज सफलतापूर्वक प्रकाशित कर दिया गया है, और दक्षता के लिए पूरी प्रक्रिया को स्वचालित कर दिया गया है। प्रकाशन की पुष्टि करने के लिए, अपनी एनपीएम सेटिंग्स https://www.npmjs.com/settings/<your_user_name>/packages पर जाएं और पैकेज अनुभाग के अंतर्गत देखें; वहां, आपको अपना नया प्रकाशित पैकेज मिलेगा।

अब, npx your_package_name hi जैसी सरल कमांड के साथ, आप तुरंत हमारे विकास परीक्षणों के परिणाम देख सकते हैं। इसके अतिरिक्त, पैकेज को npm i -g your_package_name कमांड का उपयोग करके विश्व स्तर पर स्थापित किया जा सकता है।

निष्कर्ष

जैसा कि हमने इस पूरे लेख में देखा है, जबकि प्रारंभिक सेटअप चुनौतियों से भरा हो सकता है, इनाम एक सुव्यवस्थित और सुसंगत रिलीज प्रक्रिया स्थापित करने में निहित है। GitHub क्रियाओं का लाभ उठाना इन जटिलताओं को सरल बनाता है, यह सुनिश्चित करते हुए कि डेवलपर्स लॉजिस्टिक जटिलताओं के बजाय कोड गुणवत्ता पर ध्यान केंद्रित कर सकते हैं।

चाहे आप अभी सार्वजनिक पैकेज के साथ अपनी यात्रा शुरू कर रहे हों या अपने प्रकाशन प्रयासों में असफलताओं का सामना कर रहे हों, एक संरचित, स्वचालित वर्कफ़्लो को अपनाने में निर्विवाद मूल्य है। सिमेंटिक रिलीज़ को एकीकृत करके, आप लगातार संस्करण सुनिश्चित कर रहे हैं और सॉफ़्टवेयर विकास के लिए भविष्य-उन्मुख दृष्टिकोण का समर्थन कर रहे हैं।

यहां निर्बाध प्रकाशन, कम सिरदर्द और उस कोड को बेहतर बनाने में अधिक समय लगता है जो हमारी डिजिटल दुनिया को आगे बढ़ाता है।

याद रखें, यह आवश्यक है कि NPM_TOKEN और GITHUB_TOKEN दोनों को GitHub क्रियाओं के अंतर्गत उचित अनुमतियाँ दी जाएं। इसके अतिरिक्त, आपके package.json publishConfig एक्सेस के लिए सेटिंग्स के साथ सही ढंग से कॉन्फ़िगर किया जाना चाहिए, और सुनिश्चित करें कि private कॉन्फ़िगरेशन false पर सेट है। यदि आपको कोई समस्या आती है या आपके पास अंतर्दृष्टि है, तो कृपया टिप्पणी करने में संकोच न करें।

संदर्भ

भंडार: https://github.com/antonkalik/tokky
सिमेंटिक रिलीज सीएलआई: https://github.com/semantic-release/cli
प्रतिबद्ध: https://github.com/commitizen/cz-cli