एडिटर, कमांड लाइन और ऑटोमेशन टूलचेन

सार: एडिटर परिदृश्य के अनुसार चुनें — utility sites और mobile के लिए CodeMirror 6, पूरा IDE अनुभव चाहिए तो ही Monaco; batch काम jq और syntax, structure व style के तीन CI checks को सौंपें, और arguments हमेशा jq --arg से पास करें।

हाथ से JSON जाँचने का युग खत्म हो जाना चाहिए: जो कुछ मशीन दोहरा सकती है, उसे इंसानी आँखों पर न छोड़ें।

1. Browser में एडिटर

1.1 न्यूनतम CodeMirror 6 integration

复制import { EditorView, basicSetup } from 'codemirror';
import { json, jsonParseLinter } from '@codemirror/lang-json';
import { linter, lintGutter } from '@codemirror/lint';

const view = new EditorView({
  parent: document.getElementById('editor')!,
  doc: '{"hello": "json"}',
  extensions: [
    basicSetup,
    json(),
    linter(jsonParseLinter()),
    lintGutter(),
    EditorView.updateListener.of((update) => {
      if (update.docChanged) {
        // भारी काम करने से पहले debounce करें; हर keystroke पर format न करें
        scheduleParse(update.state.doc.toString());
      }
    }),
  ],
});

चार बातें ध्यान देने योग्य:

1. json() syntax highlighting और bracket matching देता है — अपना खुद का न लिखें;
2. jsonParseLinter() line/column स्तर के error markers बनाता है; line numbers के बगल में icons दिखाने के लिए इसे lintGutter() के साथ जोड़ें;
3. updateListener debounce होना चाहिए; हर keystroke पर लाखों पंक्तियों को JSON.parse करने से स्पष्ट lag होगा;
4. बड़े documents को EditorView.lineWrapping से आगे optimizations चाहिए ताकि पूरा document एक बार में render न हो (CodeMirror 6 डिफ़ॉल्ट रूप से viewport के अनुसार render करता है, जो पुराने संस्करणों से सुधार है)।

1.2 Folding और outlines

CodeMirror 6 में folding अंतर्निहित है; JSON परिदृश्यों में आमतौर पर आप "object/array" के आधार पर fold करते हैं:

复制import { foldGutter, foldKeymap } from '@codemirror/language';
import { keymap } from '@codemirror/view';

foldGutter() और keymap.of(foldKeymap) के साथ, उपयोगकर्ता keyboard shortcut से लंबी arrays समेट सकते हैं।

1.3 CodeMirror और Monaco में चयन

Utility sites और mobile-first → CodeMirror; पूरा IDE अनुभव (multiple files, go-to-definition, completion) → Monaco।

2. कमांड लाइन: छह सबसे आम jq रेसिपी

jq JSON के लिए वही है जो sed + awk text के लिए हैं; उसके syntax का थोड़ा हिस्सा सीखना रोज़मर्रा की अस्सी प्रतिशत ज़रूरतें पूरी कर देता है।

复制# 1. fields चुनें (सबसे आम)
jq '.data.items[].name' response.json

# 2. Filter + reshape
jq '.data.items[] | select(.price < 10) | {id, price}' response.json

# 3. Aggregates (length, sum, max)
jq '[.items[] | .price] | {count: length, total: add, max: max}' response.json

# 4. Group और aggregate
jq '[.items[]] | group_by(.category) | map({category: .[0].category, count: length})' response.json

复制# 5. कई फ़ाइलों को एक array में मिलाएँ
jq -s '.' part-*.json > merged.json

# 6. JSON Lines को पंक्ति-दर-पंक्ति process करें
jq -c 'select(.level == "error")' app.jsonl

# सामान्य output switches
jq -r '.data.name'      # quotes हटाएँ ताकि shell में साफ़ pipe हो
jq -c '.'               # Compact output, एक पंक्ति
jq --arg id "$ID" '.id == $id'   # arguments सुरक्षित रूप से पास करें, concatenation से injection से बचें

--arg विशेष उल्लेख का हकदार है: किसी variable को सीधे expression में जोड़ना तब टूट जाता है जब मान में quotes हों, जबकि --arg escaping jq को संभालने देता है।

2.1 अन्य उपकरण एक नज़र में

gron के पीछे का विचार विशेष रूप से जानने योग्य है:

复制$ echo '{"a":{"b":[1,2]}}' | gron
json = {};
json.a = {};
json.a.b = [];
json.a.b[0] = 1;
json.a.b[1] = 2;

Flatten होने के बाद, grep path ढूँढ सकता है, जो एडिटर में स्तर-दर-स्तर खोलने से कहीं तेज़ है।

3. CI में validation की तीन परतें

复制# Syntax: repository की हर json फ़ाइल batch में validate करें
find . -name '*.json' -not -path './node_modules/*' -print0 \
  | xargs -0 -n1 jq empty

# Structure: schema के विरुद्ध validate करें
npx ajv-cli validate -s schemas/order.json -d 'fixtures/orders/*.json' --strict=false

# Style: केवल जाँचें, बदलें नहीं
npx prettier --check "**/*.json"

तीनों परतें चाहिए, क्योंकि उनके error संदेश पूरी तरह अलग हैं: jq empty केवल कहता है "कौन-सी पंक्ति टूटी है", ajv कहता है "कौन-सा field कौन-से keyword का उल्लंघन करता है", और Prettier केवल कहता है "formatting असंगत है"।

4. pre-commit hooks

复制# .husky/pre-commit उदाहरण (excerpt)
npx lint-staged

复制{
  "lint-staged": {
    "*.json": ["prettier --write", "jq empty"]
  }
}

package.json और tsconfig.json जैसी tool configuration फ़ाइलों से सावधान रहें; Prettier को उन्हें लापरवाही से re-indent न करने दें — कुछ उपकरण formatting के प्रति संवेदनशील हैं (valid JSON नहीं होना चाहिए, लेकिन व्यवहार में इससे समस्याएँ हुई हैं)। आप उन्हें अलग से exclude कर सकते हैं।

5. Debugging सुझाव

1. jq -e को assertion की तरह इस्तेमाल करें: expression का परिणाम false या null होने पर exit code 1 होता है, इसलिए यह सीधे scripts में जाँच के रूप में जा सकता है;
2. jq 'paths' सभी paths सूचीबद्ध करता है, जिससे अपरिचित document की संरचना का जल्दी अवलोकन मिलता है;
3. jq '.. | objects | keys' हर key नाम ढूँढता है जो कभी आया है, जो असंगत spelling पकड़ने के लिए उपयोगी है;
4. एडिटर में तुलना से पहले format करें: unformatted diff शुद्ध शोर है; /diff जैसी structural तुलना अधिक सटीक है।

6. जाँच सूची

• [ ] एडिटर के error markers line और column तक सटीक हैं, और parsing debounce है;
• [ ] टीम scripts strings जोड़ने के बजाय jq --arg से arguments पास करती हैं;
• [ ] CI में तीनों validation परतें हैं (syntax/structure/style);
• [ ] pre-commit केवल staged फ़ाइलें process करता है, ताकि पूरा scan commits धीमे न करे;
• [ ] उपकरण संस्करण package.json या .tool-versions में pinned हैं।

सामान्य प्रश्न

CodeMirror 6 और Monaco में कैसे चुनें?

Utility sites और mobile के लिए CodeMirror 6 पसंद करें: यह छोटा, modular और mobile पर अच्छी तरह समर्थित है, और syntax highlighting, bracket matching व folding ज़रूरत के अनुसार जोड़े जा सकते हैं। Monaco तभी लें जब पूरा IDE अनुभव चाहिए, यानी multiple files, go-to-definition और completion — इसकी कीमत कई मेगाबाइट का bundle और अधिक customization मेहनत है।

CI को syntax, structure और style जाँचें एक साथ क्यों चाहिए?

तीनों परतें पूरी तरह अलग errors बताती हैं: jq empty कहता है कौन-सी पंक्ति टूटी है, ajv कहता है कौन-सा field कौन-से keyword का उल्लंघन करता है, और Prettier केवल कहता है कि formatting असंगत है। एक परत हटाने से बाकी की errors आसानी से गलत पढ़ी जा सकती हैं, इसलिए तीनों रखें और किसी परत के fail होते ही रुकें।

क्या CI में validate करने के बजाय pre-commit पर निर्भर रहना चाहिए?

नहीं। Hooks केवल staged फ़ाइलें process करते हैं, जो एक मिनट में feedback देता है पर पूरे repository या commit bypass करने वाले बदलावों को cover नहीं कर सकता। पूर्णता की ज़िम्मेदारी CI की है: pre-commit को staged फ़ाइलों पर रखें और पूरा scan CI के लिए छोड़ें।