मैं npm स्थापित करने के लिए package.json में टिप्पणी कैसे जोड़ूँ?

Question

मुझे एक साधारण पैकेज मिल गया है। फ़ाइल को खोलें और मैं एक टिप्पणी जोड़ना चाहता हूं। क्या ऐसा करने का कोई तरीका है, या इस काम को करने के लिए कोई हैक हैं?

{
  "name": "My Project",
  "version": "0.0.1",
  "private": true,
  "dependencies": {
    "express": "3.x",
    "mongoose": "3.x"
  },
  "devDependencies" :  {
    "should": "*"
    /* "mocha": "*" not needed as should be globally installed */
  }
}

ऊपर दिए गए उदाहरण की टिप्पणी npm के ब्रेक के रूप में काम नहीं करती है। मैंने भी कोशिश की है // शैली टिप्पणियाँ।

Comments

के संभावित डुप्लिकेट सकते हैं मैं एक JSON फ़ाइल टिप्पणी?

— येहुदा काट्ज़

@ YehudaKatz - मुझे नहीं लगता कि यह एक डुप्लिकेट है जिसमें यह प्रश्न package.jsonफ़ाइलों के लिए विशिष्ट है और package.jsonNodeJS मेलिंग सूची पर एक विशिष्ट उत्तर है।

— मार्क इवांस

कोर एनपीएम डेवलपर्स में से एक ने टिप्पणियों के समर्थन पर विचार करने से इनकार कर दिया है package.json। कृपया उस मुद्दे पर टिप्पणी करें - शायद हम यह दिखा सकते हैं कि टिप्पणी कितनी उपयोगी हो सकती है।

— डेन डैस्कलेस्कु

एक एकल टैग <व्यंग्य />। JSON5 टिप्पणियों का समर्थन करता है json5.org

— क्रिस्टियन ई।

Answer 1

यह हाल ही में नोड.जेएस मेलिंग सूची में चर्चा की गई है ।

इसहाक श्लोएटर के अनुसार जिन्होंने npm बनाया:

... "//" कुंजी कभी भी किसी भी उद्देश्य के लिए npm द्वारा उपयोग नहीं की जाएगी, और टिप्पणियों के लिए आरक्षित है ... यदि आप एक से अधिक पंक्ति टिप्पणी का उपयोग करना चाहते हैं, तो आप किसी सरणी, या एकाधिक "//" का उपयोग कर सकते हैं चांबियाँ।

अपने सामान्य उपकरणों (npm, यार्न, आदि) का उपयोग करते समय कई "//" कुंजियों को हटा दिया जाएगा। यह बच जाता है:

{ "//": [ 
  "first line", 
  "second line" ] } 

यह नहीं बचेगा:

{ "//": "this is the first line of a comment", 
  "//": "this is the second line of the comment" } 

Comments

वहाँ एक तरीका है जो 'निर्भरता' अनुभाग में प्रत्येक प्रविष्टि को डॉक्टर करने के लिए है? "//" चाल तब काम नहीं करती है जब इसकी 'निर्भरता' का एक समूह।

— रिनोप

ध्यान दें कि पहले उदाहरण के रूप में कई टिप्पणियों का उपयोग करने { "//": "first", "//": "second"}से आप npm versionअन्य कमांड लाइन के बर्तनों का उपयोग करने से रोकते हैं जो आमतौर पर पूरे JSON को रिप्रेजेंट करते हैं और प्रक्रिया में डुप्लिकेट कुंजियों को छोड़ देते हैं।

— जकूब। जी।

किसी को यह पता होना चाहिए कि "//" का उपयोग केवल वस्तु के मूल में किया जा सकता है package.json। उदाहरण के लिए { "dependencies": { "//": "comment?" }}अमान्य है लेकिन { "//": "comment!", "dependencies":{}}मान्य है।

— david_p

यहां तक ​​कि डगलस क्रॉकफोर्ड को JSON कॉन्फिग फाइलों में टिप्पणी डालने में कोई समस्या नहीं है। एनपीएम के साथ स्थिति कम से कम कहने के लिए मूर्खतापूर्ण है।

— मुहम्मद रेहान सईद

मेरे अनुभव में "//"कुंजी और उसके मूल्य को आखिरकार मिटा दिया गया। क्या स्थायी टिप्पणी करने का कोई तरीका है?

— प्रातः

Answer 2

यहाँ JSON में टिप्पणी जोड़ने के लिए एक और हैक है। जबसे:

{"a": 1, "a": 2}

के बराबर है

{"a": 2}

आप कुछ ऐसा कर सकते हैं:

{
  "devDependencies": "'mocha' not needed as should be globally installed",
  "devDependencies" :  {
    "should": "*"
  }
}

Comments

यह विशिष्ट पैकेज स्तर पर भी काम करता है। उदाहरण के लिए। "express": "makes routing better so I don't want to gouge my eyes out", "express": "3.x"। तो, हाँ, कॉलिन के रूप में "टक" कहते हैं, और कॉलिन के अनुसार "धन्यवाद" भी कहते हैं।

— जुआनपाको

ध्यान दें कि यह हैक आपको package.jsonप्रोग्रामेटिक तरीके से कभी भी बदलने से रोकता है , npm version 1.2.3संस्करण को टक्कर देने के लिए कहें - परिणामस्वरूप JSON से अनावश्यक प्रविष्टियों को हटा दिया जाएगा।

— jakub.g

यह बुरी सलाह है, क्योंकि जिस वस्तु की व्याख्या की जाती है, उसकी गारंटी नहीं होती है। उदाहरण के लिए, कुछ स्थितियों में, आपका उदाहरण 2 के बजाय 1 होने के साथ समाप्त हो सकता है

— जो स्प्रैग

@mpen जोखिम यह है कि कोई गारंटी नहीं है कि JSON कोडिंग कोड इसे क्रमिक रूप से करेगा।

— जो स्प्रैग

रिकॉर्ड के लिए, RFC स्पष्ट रूप से कहता है: "जब किसी ऑब्जेक्ट के भीतर नाम अद्वितीय नहीं होते हैं, तो सॉफ़्टवेयर का व्यवहार ऐसी वस्तु प्राप्त करता है जो अप्रत्याशित है। कई कार्यान्वयन केवल अंतिम नाम / मान जोड़े की रिपोर्ट करते हैं। अन्य कार्यान्वयन एक त्रुटि या विफलता की रिपोर्ट करते हैं। ऑब्जेक्ट को पार्स करने के लिए, और कुछ कार्यान्वयन डुप्लिकेट सहित सभी नाम / मूल्य जोड़े की रिपोर्ट करते हैं। "

— एलन टैम

Answer 3

जटिल और हैक किए गए समाधानों पर एक घंटे बर्बाद करने के बाद, मैंने अपने भारी निर्भरता अनुभाग में टिप्पणी करने के लिए सरल और वैध समाधान पाया है package.json। सिर्फ इस तरह:

{
  "name": "package name",
  "version": "1.0",
  "description": "package description",
  "scripts": {
    "start": "npm install && node server.js"
  },
  "scriptsComments": {
    "start": "Runs development build on a local server configured by server.js"
  },
  "dependencies": {
    "ajv": "^5.2.2"
  },
  "dependenciesComments": {
    "ajv": "JSON-Schema Validator for validation of API data"
  }
}

जब उसी तरह से हल किया जाता है, तो मेरे लिए यह बहुत आसान हो जाता है कि मैं इन निर्भरता / टिप्पणियों के इन युग्मों को ट्रैक करूँ या तो git कमिट में भिन्नता है या संपादक के साथ काम करते समय package.json।

और कोई अतिरिक्त उपकरण शामिल नहीं है, बस सादा और वैध JSON है।

आशा है कि यह किसी को भी मदद करता है।

Comments

इस तरह से अधिक समझ में आता है और चीजों को साफ रखना है।

— हितेश साहू

एक गैर-हैकी समाधान के लिए धन्यवाद जो तकनीकी रूप से मान्य और शब्दार्थ रूप से सहायक है।

— रॉय टिंकर

लिपियों के बारे में टिप्पणियों के लिए, "सहायता" स्क्रिप्ट क्यों नहीं प्रदान करें, उदाहरण के लिए "scripts": { "postinstall": "echo postinstall stuff goes here", "help-postinstall": "echo helpful stuff goes here" }

— पीक

@ धन्यवाद धन्यवाद! केवल नकारात्मक पक्ष यह है कि वास्तविक स्क्रिप्ट को टिप्पणियों के साथ मिश्रित किया जाएगा।

— गकॉंड

@ इसके लिए धन्यवाद। मुझे सबसे ज्यादा समझ में आता है।

— रॉबिन विंसलो

Answer 4

कई दिलचस्प विचार।

मैं यह कर रहा हूँ:

{
  ...
  "scripts": {
    "about": "echo 'Say something about this project'",
    "about:clean": "echo 'Say something about the clean script'",
    "clean": "do something",
    "about:build": "echo 'Say something about building it'",
    "build": "do something",
    "about:watch": "echo 'Say something about how watch works'",
    "watch": "do something",
  }
  ...
}

इस तरह मैं दोनों स्क्रिप्ट में "छद्म टिप्पणियाँ" पढ़ सकता हूं, और टर्मिनल में किसी तरह की मदद देखने के लिए, निम्नलिखित की तरह कुछ भी चला सकता हूं:

npm run about
npm run about:watch

इस चर्चा के लिए मेरे 2cents :)

Comments

चतुर, मुझे यह पसंद है

— कोर्रे डी

Answer 5

एनपीएस (नोड पैकेज लिपियों) ने मेरे लिए इस समस्या को हल किया। आपको अपनी NPM स्क्रिप्ट्स को एक अलग JS फाइल में डालने की सुविधा देता है, जहाँ आप टिप्पणी galore और किसी अन्य JS तर्क को जोड़ सकते हैं, जिसकी आपको आवश्यकता है। https://www.npmjs.com/package/nps

package-scripts.jsमेरी एक परियोजना का नमूना

module.exports = {
  scripts: {
    // makes sure e2e webdrivers are up to date
    postinstall: 'nps webdriver-update',

    // run the webpack dev server and open it in browser on port 7000
    server: 'webpack-dev-server --inline --progress --port 7000 --open',

    // start webpack dev server with full reload on each change
    default: 'nps server',

    // start webpack dev server with hot module replacement
    hmr: 'nps server -- --hot',

    // generates icon font via a gulp task
    iconFont: 'gulp default --gulpfile src/deps/build-scripts/gulp-icon-font.js',

    // No longer used
    // copyFonts: 'copyfiles -f src/app/glb/font/webfonts/**/* dist/1-0-0/font'
  }
}

मैंने अभी-अभी एक लोकल इंस्टाल किया npm install nps -save-devऔर इसे अपनी package.jsonस्क्रिप्ट में डाला ।

"scripts": {
    "start": "nps",
    "test": "nps test"
}

Answer 6

आप हमेशा इस तथ्य का दुरुपयोग कर सकते हैं कि डुप्लिकेट कीज़ ओवररेटेड हैं। यह वही है जो मैंने अभी लिखा है:

"dependencies": {
  "grunt": "...",
  "grunt-cli": "...",

  "api-easy": "# Here is the pull request: https://github.com/...",
  "api-easy": "git://..."

  "grunt-vows": "...",
  "vows": "..."
}

हालाँकि, यह स्पष्ट नहीं है कि JSON डुप्लिकेट कीज़ को अनुमति देता है (देखें कि क्या JSON सिंटैक्स किसी ऑब्जेक्ट में डुप्लिकेट कुंजियों की अनुमति देता है । यह npm के साथ काम करने लगता है, इसलिए मैं जोखिम लेता हूं।

अनुशंसित हैक "//"कुंजी ( नोड्ज मेलिंग सूची से ) का उपयोग करने के लिए है । जब मैंने इसका परीक्षण किया, तो यह "निर्भरता" वर्गों के साथ काम नहीं किया, हालांकि। इसके अलावा, पोस्ट में उदाहरण कई "//"कुंजियों का उपयोग करता है , जिसका अर्थ है कि npm डुप्लिकेट कीज़ के साथ JSON फ़ाइलों को अस्वीकार नहीं करता है। दूसरे शब्दों में, ऊपर की हैक हमेशा ठीक होनी चाहिए।

अपडेट: डुप्लिकेट की गई हैक का एक कष्टप्रद नुकसान यह है कि npm install --saveचुपचाप सभी डुप्लिकेट को समाप्त कर देता है। दुर्भाग्य से, इसे अनदेखा करना बहुत आसान है और आपकी सोची-समझी टिप्पणियां समाप्त हो गई हैं।

"//"हैक अभी भी सबसे सुरक्षित के रूप में यह लगता है। हालाँकि, बहु-पंक्ति टिप्पणियों को भी हटा दिया जाएगा npm install --save।

Comments

"//"हैक devDependencies अंदर काम नहीं करता। एनपीएम एक यूएनसी मार्ग को हल करने की कोशिश करता है।

— दिमित्री एस।

अद्यतन वाक्य के लिए धन्यवाद, लेकिन फिर से यह mochaविशेषता टिप्पणी नहीं कर सकता । बस इसे एक से अधिक जोड़ सकते हैं और npm द्वारा अंत में उपयोग किया जाएगा।

— 11

मैं इसे स्वीकार करने से नफरत करता हूं - लेकिन मुझे "//" से बेहतर यह पसंद है

— 1

Answer 7

मेरे पास एक मजेदार हैक आइडिया है।

के लिए टिप्पणी भाजक के रूप में उपयुक्त रूप से NPM पैकेज का नाम बनाएं dependenciesऔर devDependenciespackage.json में ब्लॉक, उदाहरण के लिएx----x----x

{
    "name": "app-name",
    "dependencies": {
        "x----x----x": "this is the first line of a comment",
        "babel-cli": "6.x.x",
        "babel-core": "6.x.x",
        "x----x----x": "this is the second line of a comment",
        "knex": "^0.11.1",
        "mocha": "1.20.1",
        "x----x----x": "*"
    }
}

नोट : *ब्लॉक में मान्य संस्करण के साथ अंतिम टिप्पणी विभक्त लाइन जोड़ना होगा ।

Comments

याय, यह वास्तव में उपलब्ध है: npmjs.com/package/x----x----x

— revelt

इस उत्तर के बारे में रोमांचित था, लेकिन जब मैं भाग गया npm install(npm 5 का उपयोग करके) तो मेरी डुप्लिकेट कुंजियाँ स्वतः ही हटा दी गईं :(

— एरिक मेजरस

@EricMajerus ~, npm5 मेरा दिल भी तोड़ दो :(

— लियाओ काई

Answer 8

इस धागे से प्रेरित होकर, यहां हम इसका उपयोग कर रहे हैं :

{
  "//dependencies": {
    "crypto-exchange": "Unified exchange API"
  },
  "dependencies": {
    "crypto-exchange": "^2.3.3"
  },
  "//devDependencies": {
    "chai": "Assertions",
    "mocha": "Unit testing framwork",
    "sinon": "Spies, Stubs, Mocks",
    "supertest": "Test requests"
  },
  "devDependencies": {
    "chai": "^4.1.2",
    "mocha": "^4.0.1",
    "sinon": "^4.1.3",
    "supertest": "^3.0.0"
  }
}

Answer 9

अब तक, अधिकांश "हैक" यहां JSON का दुरुपयोग करने का सुझाव देते हैं। लेकिन इसके बजाय, अंतर्निहित स्क्रिप्टिंग भाषा का दुरुपयोग क्यों नहीं किया जाता है?

संपादित प्रारंभिक प्रतिक्रिया के प्रयोग से सही पर विवरण डाल दिया गया था # add comments hereलपेट के लिए; हालाँकि, यह विंडोज पर काम नहीं करता है, क्योंकि झंडे (जैसे npm रन myframework - --myframework- झंडे) को नजरअंदाज किया जाएगा। मैंने अपनी प्रतिक्रिया को सभी प्लेटफार्मों पर काम करने के लिए बदल दिया, और पठनीय उद्देश्यों के लिए कुछ संकेत जोड़े।

{
 "scripts": {
    "help": "       echo 'Display help information (this screen)';          npm run",
    "myframework": "echo 'Run myframework binary';                          myframework",
    "develop": "    echo 'Run in development mode (with terminal output)';  npm run myframework"
    "start": "      echo 'Start myFramework as a daemon';                   myframework start",
    "stop":  "      echo 'Stop the myFramework daemon';                     myframework stop"
    "test": "echo \"Error: no test specified\" && exit 1"
  }
}

यह करेगा:

1. JSON अनुपालन नहीं तोड़ें (या कम से कम इसकी हैक नहीं है, और आपका आईडीई आपको अजीब, खतरनाक सामान करने के लिए चेतावनी नहीं देगा)
2. क्रॉस प्लेटफ़ॉर्म पर काम करता है (मैकओएस और विंडोज़ पर परीक्षण किया गया, यह मानते हुए कि यह लिनक्स पर ठीक काम करेगा)
3. दौड़ने के ढंग से नहीं मिलता npm run myframework -- --help
4. आउटपुट जानकारी सार्थक होगी जब चल रहा हो npm run(जो उपलब्ध स्क्रिप्ट के बारे में जानकारी प्राप्त करने के लिए चलाने के लिए वास्तविक कमांड है)
5. एक अधिक स्पष्ट सहायता आदेश प्रस्तुत करता है (यदि कुछ देवों को पता नहीं है कि npm रन इस तरह का आउटपुट प्रस्तुत करता है)
6. कमांड चलाते समय कमांड और उसका विवरण दोनों दिखाएगा
7. केवल खोलने पर package.json( कुछ lessया अपने पसंदीदा आईडीई का उपयोग करके ) कुछ पठनीय है

Comments

अर्घ, वास्तव में विंडोज पर यह सिर्फ झंडे को नजरअंदाज करेगा, इसलिए 3. सच नहीं है: /

— मार्क ट्रूडेल

इसे विंडोज़ सीएमडी के साथ संगत बनाएं: &&इसके बजाय ;पहले कमांड बन जाता है:"help": "echo 'Display help information (this screen)' && npm run",

— 20_20

हाँ, मैं यही कर रहा हूँ। अच्छी पकड़!

— मार्क ट्रुडेल

यह केवल scriptsअनुभाग में काम करता है । package.jsonकई अन्य चीजें हैं।

— रॉल्फ

सही बात। तो फिर, आपको वहां और क्या दस्तावेज की आवश्यकता महसूस होगी?

— मार्क ट्रूडेल

Answer 10

यहाँ मेरी टिप्पणी के भीतर ले लो package.json/ bower.json:

मेरे पास package.json.jsएक स्क्रिप्ट है जो वास्तविक निर्यात करती है package.json। स्क्रिप्ट चलाना पुराने को ओवरराइट करता है package.jsonऔर मुझे बताता है कि इसमें क्या बदलाव किए गए हैं, जो आपको किए npmगए स्वचालित परिवर्तनों पर नज़र रखने में मदद करने के लिए एकदम सही हैं । इस तरह मैं प्रोग्राम को भी परिभाषित कर सकता हूं कि मैं किन पैकेजों का उपयोग करना चाहता हूं।

नवीनतम ग्रंट कार्य यहाँ है: https://gist.github.com/MarZab/72fa6b85bc9e71de5991

Comments

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

— नोव

मैं इस विचार की तरह है, लेकिन के रूप में किसी को सार पर पूछा, मामले के बारे में क्या है जहाँ आप मूल package.json के माध्यम से संशोधित कर रहे हैं npm install --saveया --save-dev?

— २17 ’१

हाँ मैं उन टिप्पणियों को याद कर रहा हूं; theres कोई अच्छा उपाय नहीं है, मैं git diffs को देखता था और अद्यतन करने के बाद अपनी .js फ़ाइल को अपडेट करता था

— MarZab

Answer 11

मैं इस scriptsतरह समाप्त हुआ :

  "scripts": {
    "//-1a": "---------------------------------------------------------------",
    "//-1b": "---------------------- from node_modules ----------------------",
    "//-1c": "---------------------------------------------------------------",
    "ng": "ng",
    "prettier": "prettier",
    "tslint": "tslint",
    "//-2a": "---------------------------------------------------------------",
    "//-2b": "--------------------------- backend ---------------------------",
    "//-2c": "---------------------------------------------------------------",
    "back:start": "node backend/index.js",
    "back:start:watch": "nodemon",
    "back:build:prod": "tsc -p backend/tsconfig.json",
    "back:serve:prod": "NODE_ENV=production node backend/dist/main.js",
    "back:lint:check": "tslint -c ./backend/tslint.json './backend/src/**/*.ts'",
    "back:lint:fix": "yarn run back:lint:check --fix",
    "back:check": "yarn run back:lint:check && yarn run back:prettier:check",
    "back:check:fix": "yarn run back:lint:fix; yarn run back:prettier:fix",
    "back:prettier:base-files": "yarn run prettier './backend/**/*.ts'",
    "back:prettier:fix": "yarn run back:prettier:base-files --write",
    "back:prettier:check": "yarn run back:prettier:base-files -l",
    "back:test": "ts-node --project backend/tsconfig.json node_modules/jasmine/bin/jasmine ./backend/**/*spec.ts",
    "back:test:watch": "watch 'yarn run back:test' backend",
    "back:test:coverage": "echo TODO",
    "//-3a": "---------------------------------------------------------------",
    "//-3b": "-------------------------- frontend ---------------------------",
    "//-3c": "---------------------------------------------------------------",
    "front:start": "yarn run ng serve",
    "front:test": "yarn run ng test",
    "front:test:ci": "yarn run front:test --single-run --progress=false",
    "front:e2e": "yarn run ng e2e",
    "front:e2e:ci": "yarn run ng e2e --prod --progress=false",
    "front:build:prod": "yarn run ng build --prod --e=prod --no-sourcemap --build-optimizer",
    "front:lint:check": "yarn run ng lint --type-check",
    "front:lint:fix": "yarn run front:lint:check --fix",
    "front:check": "yarn run front:lint:check && yarn run front:prettier:check",
    "front:check:fix": "yarn run front:lint:fix; yarn run front:prettier:fix",
    "front:prettier:base-files": "yarn run prettier \"./frontend/{e2e,src}/**/*.{scss,ts}\"",
    "front:prettier:fix": "yarn run front:prettier:base-files --write",
    "front:prettier:check": "yarn run front:prettier:base-files -l",
    "front:postbuild": "gulp compress",
    "//-4a": "---------------------------------------------------------------",
    "//-4b": "--------------------------- cypress ---------------------------",
    "//-4c": "---------------------------------------------------------------",
    "cy:open": "cypress open",
    "cy:headless": "cypress run",
    "cy:prettier:base-files": "yarn run prettier \"./cypress/**/*.{js,ts}\"",
    "cy:prettier:fix": "yarn run front:prettier:base-files --write",
    "cy:prettier:check": "yarn run front:prettier:base-files -l",
    "//-5a": "---------------------------------------------------------------",
    "//-5b": "--------------------------- common ----------------------------",
    "//-5c": "---------------------------------------------------------------",
    "all:check": "yarn run back:check && yarn run front:check && yarn run cy:prettier:check",
    "all:check:fix": "yarn run back:check:fix && yarn run front:check:fix && yarn run cy:prettier:fix",
    "//-6a": "---------------------------------------------------------------",
    "//-6b": "--------------------------- hooks -----------------------------",
    "//-6c": "---------------------------------------------------------------",
    "precommit": "lint-staged",
    "prepush": "yarn run back:lint:check && yarn run front:lint:check"
  },

यहाँ मेरा इरादा एक लाइन को स्पष्ट करना नहीं है, बस बैकएंड, फ्रंटएंड, ऑल इत्यादि के लिए मेरी स्क्रिप्ट के बीच कुछ सीमांकक होना चाहिए।

मैं 1 ए, 1 बी, 1 सी, 2 ए, ... का बहुत बड़ा प्रशंसक नहीं हूं, लेकिन चाबियां अलग हैं और मुझे इस तरह से कोई समस्या नहीं है।

Answer 12

जैसा कि यह उत्तर बताता है, //कुंजी आरक्षित थी, इसलिए इसका उपयोग पारंपरिक रूप से टिप्पणियों के लिए किया जा सकता है। //टिप्पणी के साथ समस्या यह है कि इसका उपयोग dependenciesऔर devDependenciesसंस्करण बाधा के रूप में स्ट्रिंग के साथ नियमित निर्भरता के रूप में नहीं किया जा सकता है :

"dependencies": {
  "//": "comment"
}

एक त्रुटि ट्रिगर करता है,

npm ईआरआर! कोड EINVALIDPACKAGENAME

npm ईआरआर! अमान्य पैकेज नाम "//": नाम में केवल URL के अनुकूल वर्ण हो सकते हैं

हालांकि गैर-स्ट्रिंग मान वाली कुंजियों को अमान्य निर्भरता माना जाता है और कुशलता से अनदेखा किया जाता है:

"dependencies": {
  "//": ["comment"]
}

एक निर्भरता ही उसी तरह टिप्पणी की जा सकती है:

"dependencies": {
  "foo": ["*", "is not needed now"],
}

चूँकि निर्भरताएँ तब हल की जाती हैं जब package.json को NPM द्वारा संशोधित किया जाता है, इसलिए एक निर्भरता के ऊपर एक टिप्पणी देना अव्यावहारिक है जो इसे संदर्भित करता है:

"dependencies": {
  "bar": "*",
  "//": ["should be removed in 1.x release"]
  "foo": "*",
}

टिप्पणी कुंजी के अनुसार नामित किया जाना चाहिए अगर यह विशिष्ट लाइन को संदर्भित करता है, तो इसे स्थानांतरित नहीं किया जाएगा:

"dependencies": {
  "bar": "*",
  "foo": "*",
  "foo //": ["should be removed in 1.x release"]
}

एक टिप्पणी जो विशिष्ट निर्भरता पर लागू होती है, उसे सेमर के एक भाग के रूप में जोड़ा जा सकता है:

"dependencies": {
  "bar": "*",
  "foo": "* || should be removed in 1.x release"
}

ध्यान दें कि यदि पहला भाग ORमेल नहीं खाता है, तो एक टिप्पणी पार्स की जा सकती है, जैसे 1.x।

ये वर्कअराउंड सभी वर्तमान एनपीएम संस्करणों (6 और निम्न) के साथ संगत हैं।

Answer 13

चूंकि अधिकांश डेवलपर्स टैग / एनोटेशन-आधारित दस्तावेज़ों से परिचित हैं, इसलिए मैंने जिस कन्वेंशन का उपयोग शुरू किया है, वह समान है। यहाँ एक स्वाद है:

{
  "@comment dependencies": [
    "These are the comments for the `dependencies` section.",
    "The name of the section being commented is included in the key after the `@comment` 'annotation'/'tag' to ensure the keys are unique.",
    "That is, using just \"@comment\" would not be sufficient to keep keys unique if you need to add another comment at the same level.",
    "Because JSON doesn't allow a multi-line string or understand a line continuation operator/character, just use an array for each line of the comment.",
    "Since this is embedded in JSON, the keys should be unique.",
    "Otherwise JSON validators, such as ones built into IDE's, will complain.",
    "Or some tools, such as running `npm install something --save`, will rewrite the `package.json` file but with duplicate keys removed.",
    "",
    "@package react - Using an `@package` 'annotation` could be how you add comments specific to particular packages."
  ],
  "dependencies": {
    ...
  },
  "scripts": {
    "@comment build": "This comment is about the build script.",
    "build": "...",

    "@comment start": [
      "This comment is about the `start` script.",
      "It is wrapped in an array to allow line formatting.",
      "When using npm, as opposed to yarn, to run the script, be sure to add ` -- ` before adding the options.",
      "",
      "@option {number} --port - The port the server should listen on."
    ],
    "start": "...",

    "@comment test": "This comment is about the test script.",
    "test": "..."
  }
}

नोट: के लिए dependencies, devDependencies, आदि वर्गों, टिप्पणी एनोटेशन विन्यास ऑब्जेक्ट के अंदर अलग-अलग पैकेज निर्भरता सीधे ऊपर के बाद से नहीं जोड़ा जा सकता npmएक NPM पैकेज के नाम पर होने की कुंजी उम्मीद कर रही है। इसलिए का कारण @comment dependencies।

नोट: कुछ संदर्भों में, जैसे स्क्रिप्ट ऑब्जेक्ट में, कुछ संपादक / आईडीई सरणी के बारे में शिकायत कर सकते हैं। लिपियों के संदर्भ में, वीएस कोड एक मूल्य के लिए एक स्ट्रिंग की उम्मीद करता है - एक सरणी नहीं।

मुझे JSON में टिप्पणियां जोड़ने का एनोटेशन / टैग शैली तरीका पसंद है क्योंकि @प्रतीक सामान्य घोषणाओं से बाहर है।

Answer 14

इन सभी उत्तरों को संक्षेप में प्रस्तुत करने के लिए:

1. एक एकल शीर्ष-स्तरीय फ़ील्ड जोड़ें //, जिसमें टिप्पणी स्ट्रिंग शामिल है। यह काम करता है लेकिन यह बेकार है क्योंकि आप उस चीज के पास टिप्पणी नहीं कर सकते हैं जिस पर वे टिप्पणी कर रहे हैं।

2. कई शीर्ष-स्तरीय फ़ील्ड जोड़ें , जिनके साथ टिप्पणी स्ट्रिंग शामिल है। यह बेहतर है, लेकिन यह अभी भी आपको शीर्ष-स्तरीय टिप्पणियां करने की अनुमति देता है। आप व्यक्तिगत निर्भरता पर टिप्पणी नहीं कर सकते।////dependencies

3. echoआपके लिए कमांड जोड़ें scripts। यह काम करता है लेकिन यह बेकार है क्योंकि आप केवल इसका उपयोग कर सकते हैं scripts।

ये समाधान भी बहुत पठनीय नहीं हैं। वे दृश्य शोर का एक टन जोड़ते हैं और IDEs सिंटैक्स को टिप्पणियों के रूप में उजागर नहीं करेंगे।

मुझे लगता है कि एकमात्र उचित समाधान package.jsonदूसरी फ़ाइल से उत्पन्न करना है। सबसे आसान तरीका है कि अपने JSON को जावास्क्रिप्ट के रूप में लिखें और इसे लिखने के लिए नोड का उपयोग करें package.json। इस फाइल के रूप में सहेजें package.json.mjs, chmod +xयह, और फिर आप बस इसे चलाने के अपने उत्पन्न करने के लिए कर सकते हैं package.json।

#!/usr/bin/env node

import { writeFileSync } from "fs";

const config = {
  // TODO: Think of better name.
  name: "foo",
  dependencies: {
    // Bar 2.0 does not work due to bug 12345.
    bar: "^1.2.0",
  },
  // Look at these beautify comments. Perfectly syntax highlighted, you
  // can put them anywhere and there no risk of some tool removing them.
};

writeFileSync("package.json", JSON.stringify({
    "//": "This file is \x40generated from package.json.mjs; do not edit.",
    ...config
  }, null, 2));

यह //लोगों को इसे संपादित करने से आगाह करने के लिए कुंजी का उपयोग करता है। \x40generatedजानबूझकर है। यह में बदल जाता @generatedहै package.jsonऔर इसका मतलब है कि कुछ कोड समीक्षा प्रणालियां डिफ़ॉल्ट रूप से उस फ़ाइल को ध्वस्त कर देंगी।

यह आपके बिल्ड सिस्टम में एक अतिरिक्त कदम है, लेकिन यह अन्य सभी हैक्स को यहां धड़कता है।

Answer 15

जैसा कि डुप्लिकेट कमेंट कीज़ को पैकेजिंग रनिंग हटा दिया जाता है। जेसन टूल्स (एनपीएम, यार्न इत्यादि) मैं एक हैशेड संस्करण का उपयोग करने के लिए आया हूं जो कई लाइनों और कुंजियों की तरह बेहतर रीडिंग की अनुमति देता है

"//": {
  "alpaca": "we use the bootstrap version",
  "eonasdan-bootstrap-datetimepicker": "instead of bootstrap-datetimepicker",
  "moment-with-locales": "is part of moment"
},

जो रूट dependenciesआईडी के रूप में मेरी IDE के अनुसार 'मान्य' है, लेकिन इसके भीतर एक स्ट्रिंग मान की अपेक्षा की जाती है।

Comments

हाँ b / c आप वास्तव में नहीं कर सकते, लेकिन //हर जगह कुंजी, यह वास्तव में टिप्पणियों के लिए एक अच्छा विकल्प नहीं है, खासकर जब टिप्पणियों में एक संपादक आदि के साथ अच्छा वाक्यविन्यास हाइलाइट हो सकता है

— अलेक्जेंडर मिल्स

Answer 16

एक और हैक। मैंने package.jsonहैंडलबार्स टेम्पलेट के संदर्भ के रूप में पढ़ने के लिए एक स्क्रिप्ट बनाई ।

यदि कोई व्यक्ति इस दृष्टिकोण को उपयोगी पाता है तो नीचे दिया गया कोड:

const templateData = require('../package.json');
const Handlebars = require('handlebars');
const fs = require('fs-extra');
const outputPath = __dirname + '/../package-json-comments.md';
const srcTemplatePath = __dirname + '/package-json-comments/package-json-comments.hbs';

Handlebars.registerHelper('objlist', function() {
  // first arg is object, list is a set of keys for that obj
  const obj = arguments[0];
  const list = Array.prototype.slice.call(arguments, 1).slice(0,-1);

  const mdList = list.map(function(k) {
    return '* ' + k + ': ' + obj[k];
  });

  return new Handlebars.SafeString(mdList.join("\n"));
});

fs.readFile(srcTemplatePath, 'utf8', function(err, srcTemplate){
  if (err) throw err;
  const template = Handlebars.compile(srcTemplate);
  const content = template(templateData);

  fs.writeFile(outputPath, content, function(err) {
    if (err) throw err;
  });
});

हैंडलबार टेम्पलेट फ़ाइल package-json-comments.hbs

### Dependency Comments
For package: {{ name }}: {{version}}

#### Current Core Packages
should be safe to update
{{{objlist dependencies
           "@material-ui/core"
           "@material-ui/icons"
           "@material-ui/styles"
}}}

#### Lagging Core Packages
breaks current code if updated
{{{objlist dependencies
           "amazon-cognito-identity-js"
}}}

#### Major version change
Not tested yet
{{{objlist dependencies
           "react-dev-utils"
           "react-redux"
           "react-router"
           "redux-localstorage-simple"

}}}

Answer 17

Npm package.json के लिए 2 तरीके मिल गए हैं (इस वार्तालाप को पढ़ने के बाद):

  "devDependencies": {
    "del-comment": [
      "some-text"
    ],
    "del": "^5.1.0 ! inner comment",
    "envify-comment": [
      "some-text"
    ],
    "envify": "4.1.0 ! inner comment"
  }

लेकिन "- save" या "-save-dev" के साथ पैकेज के अद्यतन या पुनर्स्थापना के साथ, "^ 4.1.0 जैसी टिप्पणी करें! टिप्पणी "इसी स्थान पर हटा दी जाएगी। और यह सब npm ऑडिट को तोड़ देगा।

Comments

यह नामित पैकेज del-commentऔर स्थापित करने का प्रयास नहीं करेगा envify-comment?

— बेनी चेर्नियाव्स्की-पास्किन

Answer 18

मेरे JSON में कोई टिप्पणी नहीं की हताशा पर ले लो। मैं नए नोड्स बनाता हूं, जिनका नाम वे नोड्स के लिए देते हैं, लेकिन अंडरस्कोर के साथ उपसर्ग करते हैं। यह अपूर्ण है, लेकिन कार्यात्मक है।

{
  "name": "myapp",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "react": "^16.3.2",
    "react-dom": "^16.3.2",
    "react-scripts": "1.1.4"
  },
  "scripts": {
    "__start": [
        "a note about how the start script works"
    ],
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "__proxy": [
    "A note about how proxy works",
    "multilines are easy enough to add"
  ],
  "proxy": "http://server.whatever.com:8000"
}

Comments

का उपयोग start_commentकरना बेहतर होगा, क्योंकि तब यह वर्णानुक्रम में आदेश देगा

— अलेक्जेंडर मिल्स