होम·एरर संदेश

एरर संदेश, समझाए हुए

104 एरर संदेश — मतलब, कारण और क्या करें।

सुधारों की क़ीमत होती है। git reset --hard बिना कमिट किया काम फेंक देता है, force push किसी और के कमिट मिटा सकता है, और docker system prune बेनाम volumes हटा देता है। जहाँ ऐसा है, वहाँ लिखा है।

Git29

git की लगभग हर त्रुटि एक इनकार होती है जिसका अर्थ है "इस स्थिति से वह काम करने पर कुछ खो जाएगा"; fatal: का मतलब है कि git ने कुछ भी बदले बिना रुक गया, और पहली पंक्ति के नीचे की hint: पंक्तियों में असली उपाय होता है।

fatal: refusing to merge unrelated historiesजिन दो पक्षों को आप मिला रहे हैं उनका कोई साझा पूर्वज नहीं है, यानी git की नज़र में ये दो अलग-अलग इतिहास हैं। यह आमतौर पर तब आता है जब आपने स्थानीय रूप से git init से शुरू किया, कुछ commit किए, और फिर ऐसा remote जोड़कर pull किया जिसमें पहले से अपने commit थे। --allow-unrelated-histories इन्हें मिला देता है, पर दो अजनबी इतिहास एक ही commit पर जुड़ जाते हैं और बाद में उन्हें अलग करना बहुत कठिन होता है; अगर स्थानीय commit गिने-चुने हैं तो remote को नया clone करके अपनी फ़ाइलें उसमें रख देना साफ़ रहता है।Your branch and 'origin/main' have divergedआपकी branch और origin/main दोनों के पास ऐसे commit हैं जो दूसरे के पास नहीं हैं, यानी इतिहास दो धाराओं में बँट गया है। ऐसा तब होता है जब आप स्थानीय रूप से commit कर रहे थे और कोई और push कर रहा था, या जब आपने पहले भेजे commit को amend या rebase से बदल दिया। git pull --rebase आपके commit को उनके ऊपर दोबारा रखकर इतिहास को एक लकीर में रखता है, पर आपके commit को नए hash देता है, इसलिए यदि वे पहले साझा हो चुके थे तो वही काम दो बार दर्ज हो जाता है; ऐसे मौके पर --no-rebase, जो एक merge commit छोड़ता है, अधिक सुरक्षित है।fatal: Need to specify how to reconcile divergent branches.git 2.34 से pull खुद तय नहीं करता कि शाखाएँ अलग होने पर merge करना है या rebase — यह सेटिंग माँग रहा है, किसी नुक़सान की सूचना नहीं दे रहा। यह तब दिखता है जब शाखाएँ अलग हो चुकी हों और pull.rebase कभी सेट न किया गया हो। pull.ff only सबसे सुरक्षित उत्तर है क्योंकि यह केवल fast-forward होने पर खींचता है और वरना कुछ भी बनाए बिना रुक जाता है; pull.rebase true हर बार आपके स्थानीय commit के hash बदल देता है, और false एक merge commit छोड़ता है।CONFLICT (content): Merge conflict in src/app.tsxदोनों पक्षों ने वही पंक्तियाँ अलग-अलग तरह से बदलीं और git तय नहीं कर सकता कि कौन सही है, इसलिए उसने दोनों रूप फ़ाइल के भीतर <<<<<<<, ======= और >>>>>>> चिह्नों के बीच लिख दिए और रुक गया। ऐसा तब होता है जब आप और कोई और एक ही हिस्से को बदलें, या जब rebase आपके commit को उन्हीं पंक्तियों के बदलाव के ऊपर ले जाए। फ़ाइल खोलें, उसे सही रूप दें, चिह्न मिटाएँ, फिर git add करके commit कर दें। git merge --abort आपको merge से पहले की हालत में ठीक-ठीक लौटा देता है — commit हो चुकी चीज़ों के लिए सुरक्षित, पर हाथ से सुलझाए हिस्से उसके साथ चले जाते हैं।Please commit your changes or stash them before you merge.जिन फ़ाइलों में आपके बिना commit किए बदलाव हैं, उन्हें आने वाले commit भी छूते हैं, और git ने उन्हें मिटाने के बजाय रुकना चुना। यह तब आता है जब आप गंदे working tree के साथ pull या merge करें। git stash push -u उन बदलावों को एक ओर रख देता है ताकि merge निकल सके, और -u untracked फ़ाइलों को भी साथ ले लेता है; पर वापस लाते समय git stash pop टकरा सकता है, और stash शाखाओं के साथ दिखता नहीं, इसलिए भूलकर खो देना आसान है — एक अस्थायी commit बना लेना अधिक सुरक्षित आदत है।error: Your local changes to the following files would be overwritten by checkout:आप दूसरी branch पर जाना चाहते हैं, पर जिन फ़ाइलों की सामग्री वहाँ अलग है उनमें अब भी बिना commit किए बदलाव पड़े हैं। यह तब आता है जब काम आधा हो और आप switch या checkout करें। git stash push -u या एक अस्थायी commit आपको पार करा देता है और बाद में लौटने भी देता है। खोज में आम तौर पर मिलने वाले git checkout --force और git switch --discard-changes आपको ले तो जाते हैं, पर बिना commit किए वे बदलाव हमेशा के लिए मिटा देते हैं — reflog में भी कुछ नहीं बचता, वापसी का कोई रास्ता नहीं।You are currently rebasing branch 'feature' on '8a3f21c'.एक rebase शुरू होकर बीच में रुका हुआ है, और HEAD आपकी branch पर नहीं बल्कि एक अस्थायी स्थिति पर टिका है। यह पंक्ति rebase के दौरान टकराव के बाद, या git rebase -i के edit या break पर रुकने के बाद दिखती है, जब आपने उसे पूरा किए बिना कोई दूसरा काम कर लिया। टकराव सुलझाकर git add करें और git rebase --continue से आगे बढ़ें, या उस commit को छोड़ना हो तो --skip लगाएँ। git rebase --abort आपको rebase से पहले की जगह पर ठीक-ठीक लौटा देता है, इसलिए commit हो चुका कुछ नहीं खोता, पर अब तक हाथ से सुलझाए टकराव उसके साथ चले जाते हैं।You are in 'detached HEAD' state.HEAD किसी branch के नाम की जगह सीधे एक commit की ओर इशारा कर रहा है, इसलिए यहाँ बनाए किसी भी commit से कोई नाम नहीं जुड़ता। यहाँ आप commit hash या tag का checkout करके, submodule के भीतर काम करके, या CI द्वारा किसी एक commit का checkout होने से पहुँचते हैं। किया हुआ काम रखना हो तो git switch -c नाम यहीं एक branch बना देता है और कुछ नहीं खोता। यदि आप सीधे git switch main कर दें, तो आपके commit की ओर कुछ भी इशारा नहीं करेगा: reflog उन्हें कुछ समय तक ढूँढ लेता है, फिर garbage collection उन्हें हटा देता है।Warning: you are leaving 1 commit behind, not connected to any of your branches:यह चेतावनी देता है कि आपने detached HEAD की स्थिति में commit किए और अब वहाँ से जा रहे हैं, जबकि उन commit की ओर कोई branch इशारा नहीं करती। ऐसा तब होता है जब आपने commit hash का checkout किया, काम किया, commit किया और फिर किसी branch पर लौट गए। संदेश में छपे hash का सीधा उपयोग करें: git branch rescue 8a3f21c उन्हें एक नाम से बाँध देता है, और यह command इसके सिवा कुछ नहीं बदलता, केवल एक नाम जोड़ता है। यदि आप निकल भी गए हैं, तो git reflog में वे अब भी सूचीबद्ध हैं, पर जिन commit की ओर कुछ इशारा नहीं करता वे garbage collection चलने पर हट जाते हैं — डिफ़ॉल्ट रूप से लगभग तीस दिन।error: failed to push some refs to 'https://github.com/user/repo.git'सर्वर ने आपका push ठुकरा दिया, और यह पंक्ति केवल सारांश है — असली कारण इसके ठीक ऊपर की ! [rejected] पंक्ति में है। आमतौर पर remote के पास ऐसे commit होते हैं जो आपके पास नहीं, पर संरक्षित branch, सर्वर की तरफ़ का hook या फ़ाइल आकार की सीमा भी यही सारांश देते हैं। पहले ऊपर का कारण पढ़ें; सामान्य स्थिति में git pull --rebase && git push से बात ख़त्म हो जाती है। सबसे ख़तरनाक काम है पढ़े बिना --force लगा देना, क्योंकि वह सर्वर से किसी सहकर्मी के commit मिटा सकता है।! [rejected] main -> main (fetch first)remote branch में ऐसे commit हैं जो आपके clone ने कभी देखे नहीं, इसलिए अभी push करना fast-forward नहीं होगा। ऐसा तब होता है जब किसी सहकर्मी ने पहले push कर दिया, या आपने बहुत पहले fetch किया था। git pull --rebase origin main उन commit को ले आता है और आपके commit को उनके ऊपर दोबारा रखता है, फिर push निकल जाता है। यहाँ --force कभी न लगाएँ: जिन commit को आप मिटा देंगे वे किसी और के हैं और आपके repository में मौजूद ही नहीं, इसलिए स्थानीय रूप से उन्हें लौटाने का कोई साधन नहीं।! [rejected] main -> main (non-fast-forward)आपकी branch remote branch की वंशज नहीं है, इसलिए वैसे ही push करने पर सर्वर पर मौजूद commit इतिहास से बाहर हो जाएँगे। ऐसा तब होता है जब आपने पहले भेजे commit को rebase, amend या reset से बदल दिया। यदि यह बदलाव जानबूझकर था और branch केवल आपकी है, तो git push --force-with-lease लगाएँ: यह तब मना कर देता है जब आपके पिछले fetch के बाद remote हिला हो, इसलिए सादे --force के उलट यह बीच में आए किसी सहकर्मी के push को चुपचाप नहीं मिटा सकता। यदि बदलाव जानबूझकर नहीं था, तो उत्तर force नहीं, pull --rebase है।Updates were rejected because the remote contains work that you do not have locally.यह ठुकराए गए push के पीछे का स्पष्टीकरण है: remote में ऐसा काम है जो आपके clone के पास नहीं, और अभी push करने पर वह हट जाएगा। यह तब आता है जब एक ही branch कई लोग साझा करें, या जब आपने web पर फ़ाइल बदलकर commit की हो और उसे नीचे न खींचा हो। पहले git pull --rebase origin main करें, फिर push — और वह सीधे निकल जाता है। इस सलाह की अवहेलना करके --force लगाना ठीक वही करता है जिसे रोकने के लिए सलाह मौजूद है: दूसरे व्यक्ति के commit सर्वर से गायब हो जाते हैं, और उनके push के बाद किसी ने fetch न किया हो तो वे कहीं भी नहीं बचते।error: src refspec main does not match anyजिस नाम को push करने के लिए कहा गया वह स्थानीय रूप से न branch के रूप में है न tag के रूप में, और जो नहीं है उसे भेजा नहीं जा सकता। यह बिल्कुल नए repository में होता है जहाँ अभी कोई commit नहीं और main नाम बना ही नहीं; या जब आपकी स्थानीय branch master है पर आपने main लिखा; या यह केवल टाइपिंग की चूक है। git push -u origin HEAD जिस branch पर आप वास्तव में खड़े हैं उसे उसके असली नाम से भेज देता है, जिससे नाम की गड़बड़ एक ही कदम में हल हो जाती है। यदि एक भी commit नहीं है तो पहले एक बनाएँ — ख़ाली repository के पास भेजने को कुछ नहीं होता।fatal: The current branch feature has no upstream branch.इस branch का कोई remote जोड़ दर्ज नहीं है, इसलिए बिना तर्क वाला git push या git pull नहीं जानता कि कहाँ जाए। ऐसा तब होता है जब आपने git switch -c से branch बनाई और उसे कभी भेजा नहीं। git push --set-upstream origin feature सर्वर पर वह branch बनाता है और जोड़ को एक बार दर्ज कर देता है; उसके बाद सादा git push काफ़ी है। यह command केवल एक पंक्ति स्थानीय configuration और सर्वर पर एक नई branch लिखता है, इसलिए कुछ नहीं मिटाता और बार-बार चलाना सुरक्षित है।error: cannot lock ref 'refs/remotes/origin/main': is at 8a3f21c but expected 1c2d3e4जैसे ही git किसी remote-tracking reference में नया मान लिखने चला, उसे वहाँ अभी-अभी पढ़े मान से भिन्न मान मिला, इसलिए उसने ऊपर लिखने से मना कर दिया। यह आम तौर पर तब होता है जब आपका editor पृष्ठभूमि में fetch कर रहा हो और आप भी fetch करें, या जब किसी ने force push किया हो और आपकी tracking reference बेताल हो जाएँ। fetch दोबारा चला देना आमतौर पर काफ़ी है। git remote prune origin उन tracking reference को हटाता है जिनकी शाखाएँ ऊपर अब नहीं हैं; यह केवल आपके repository के भीतर की प्रतियाँ मिटाता है और सर्वर की किसी branch को कभी नहीं छूता।fatal: not a git repository (or any of the parent directories): .gitइस डायरेक्टरी में और इसके ऊपर की किसी भी डायरेक्टरी में .git नहीं है, इसलिए git को कोई repository नहीं मिला। ऐसा तब होता है जब आप repository से एक स्तर ऊपर या नीचे खड़े हों, जब clone किसी और folder में उतरा हो, या जब आपने git init कभी चलाया ही न हो। पहले pwd से देखें कि आप कहाँ हैं, और git init केवल तब चलाएँ जब आप सचमुच यहाँ repository शुरू करना चाहते हैं। किसी मौजूदा repository के उप-folder में git init चलाने से भीतर दूसरा नत्थी repository बन जाता है जो बाहर वाले को चुपचाप ढक देता है, और उसके बाद उस folder की फ़ाइलें बाहर के commit में कभी नहीं जातीं।fatal: remote origin already exists.इस repository में origin नाम पहले से इस्तेमाल में है, इसलिए वही नाम दोबारा नहीं बनाया जा सकता। clone किए repository में origin शुरू से होता है, और यह संदेश तब आता है जब आप उसी के भीतर नए repository की गाइड पढ़कर git remote add origin चला दें। पहले git remote -v से देखें कि origin कहाँ इशारा कर रहा है; यदि आपको दूसरा URL चाहिए था तो git remote set-url origin केवल गंतव्य बदल देता है। यह सेटिंग .git/config की एक पंक्ति है, कभी भी पलटी जा सकती है और आपके commit पर कोई असर नहीं डालती।error: pathspec 'featue' did not match any file(s) known to gitgit को उस नाम की न कोई फ़ाइल मिली, न branch, न tag — उद्धरण के भीतर की जो पंक्ति है, वही उसने ढूँढी थी। यह टाइपिंग की चूक से होता है, या क्योंकि वह branch केवल सर्वर पर है और आपने fetch नहीं किया, या क्योंकि फ़ाइल आपकी सोच से अलग डायरेक्टरी में है। branch के लिए git fetch करके git branch -a से नाम आँख से मिलाएँ; फ़ाइल के लिए git status --short असली रास्ते दिखा देता है। ध्यान रखें कि git के command में रास्ते repository की जड़ से नहीं, बल्कि जिस डायरेक्टरी में आप खड़े हैं उससे पढ़े जाते हैं, और अकेले यही बात इनमें से बहुत से मामलों की जड़ है।git@github.com: Permission denied (publickey).ssh सर्वर तक पहुँच गया, पर उसने ऐसी कोई कुंजी पेश नहीं की जिसे सर्वर स्वीकार करे — यह प्रमाणीकरण की बात है, network की नहीं। ऐसा तब होता है जब आपने कुंजी बनाई ही न हो, या बनाई हो पर ssh-agent में डाली न हो, या सार्वजनिक कुंजी उस सेवा के आपके खाते में दर्ज न हो। ssh-add ~/.ssh/id_ed25519 इस सत्र भर के लिए कुंजी को agent में डाल देता है, और ssh -T git@github.com बताता है कि कौन-सी कुंजी आज़माई गई और आपको किस रूप में पहचाना जा रहा है। दोनों command केवल पढ़ते हैं; खोने को कुछ नहीं।remote: Support for password authentication was removed on August 13, 2021.GitHub ने 2021 में https पर खाते का पासवर्ड स्वीकार करना बंद कर दिया — आपका पासवर्ड ग़लत नहीं है, तरीक़ा ही अब स्वीकार नहीं होता। यह तब आता है जब सहेजा गया credential पुराना पासवर्ड हो, या आपने prompt पर पासवर्ड टाइप कर दिया हो। https पर बने रहना हो तो पासवर्ड के खाने में personal access token डालें; वरना git remote set-url origin से ssh पते पर चले जाएँ। remote पता बदलना आपके ही clone की एक पंक्ति की सेटिंग है, इसलिए यह किसी commit को नहीं छूता और कभी भी पलटा जा सकता है।fatal: Authentication failed for 'https://github.com/user/repo.git/'भेजा गया credential ठुकरा दिया गया — वह ग़लत है, बीत चुका है, या ऐसा token है जिसके पास इस repository के लिए ज़रूरी अधिकार नहीं। आम जाल है बीत चुका token जो आपके credential helper में अब भी रखा है: वह आपसे पूछे बिना भेज दिया जाता है, इसलिए हर बार वही पंक्ति मिलती है। सुधार में दी git credential reject वाली पंक्ति केवल उस सहेजी प्रविष्टि को हटाती है, ताकि फिर पूछा जाए और आप नया token चिपका सकें। यह केवल सहेजा credential मिटाती है और repository के किसी डेटा को नहीं छूती।fatal: Unable to create '/repo/.git/index.lock': File exists.git index लिखते समय .git/index.lock को ताले की तरह बनाता है, इसलिए वह फ़ाइल पहले से होना यह बताता है कि कोई दूसरा git चल रहा है या एक मरते समय उसे छोड़ गया। यह पीछे तब छूटती है जब कोई editor या IDE पृष्ठभूमि में git चला रहा हो, या आपने command को Ctrl+C से रोका या मार दिया हो। पहले पक्का करें कि कोई git नहीं चल रहा, फिर rm -f .git/index.lock से हटा दें। जब कोई git प्रक्रिया वाक़ई काम कर रही हो और आप हटा दें तो index बिगड़ सकता है, इसलिए जाँच पहले करें; index बिगड़ जाए तो git reset उसे HEAD से फिर बना देता है, और --hard न लगाएँ तो आपकी फ़ाइलें अछूती रहती हैं।nothing to commit, working tree cleanयह त्रुटि नहीं है: git बता रहा है कि पिछले commit से कुछ भी भिन्न नहीं, इसलिए उसने कुछ नहीं किया। यह तब दिखता है जब बदली गई फ़ाइल .gitignore की पकड़ में हो, जब आपने जिस जगह पर संपादन किया वह किसी दूसरे clone या worktree में हो, या जब आप commit कर चुके हों और भूल गए हों। git check-ignore -v <रास्ता> उस फ़ाइल को छिपाने वाली .gitignore की ठीक वही पंक्ति छाप देता है, और git log -1 दिखाता है कि बदलाव पहले ही चला गया या नहीं। दोनों command केवल पढ़ते हैं।error: unable to unlink old 'dist/main.js': Permission deniedcheckout किसी फ़ाइल को नए रूप से बदलना चाहता था और operating system ने पुरानी को हटाने से मना कर दिया। ऐसा तब होता है जब कोई दूसरा प्रोग्राम उस फ़ाइल को खोले रखे हो — Windows पर विशेष रूप से आम — या जब उस डायरेक्टरी में आपके पास लिखने का अधिकार न हो। जो उसे पकड़े है उसे बंद करें — dev server, editor, antivirus — और वही command दोबारा चलाएँ; Unix पर डायरेक्टरी की अनुमति ठीक करें। वही command दोहराना सुरक्षित है, पर ध्यान रखें कि git बीच में रुका है, इसलिए सफल होने तक working tree आधा-अधूरा अद्यतन रहेगा।fatal: bad object 8a3f21cआपने जो नाम दिया वह ऐसी किसी चीज़ में नहीं बदलता जिसे git पढ़ सके: या वह object इस repository में नहीं है, या है और बिगड़ा हुआ है। ऐसा किसी दूसरे clone या shallow clone से नक़ल किए hash पर, बहुत छोटे कटे hash पर, या डिस्क की गड़बड़ी के बाद सचमुच बिगड़े object पर होता है। git fsck --full केवल पढ़कर ग़ायब और टूटे object की रिपोर्ट देता है, और किसी और से मिला hash तब तक काम नहीं करता जब तक git fetch से वह object यहाँ न आ जाए। यदि fsck सचमुच बिगाड़ बताए तो मरम्मत के बजाय दोबारा clone करना तेज़ और पक्का है — बस बिना commit की फ़ाइलें पहले कहीं सुरक्षित रख लें।warning: LF will be replaced by CRLF in package.json.यह त्रुटि नहीं, सूचना है: core.autocrlf चालू है, इसलिए git commit में LF रखता है पर आपकी कार्य-प्रति में CRLF लिखेगा। Windows पर git को डिफ़ॉल्ट सेटिंग से लगाने पर autocrlf true हो जाता है, इसलिए उस मशीन पर हर add पर यह दिखता है। git config core.autocrlf input रखने से commit में LF जाता है और निकालते समय कोई बदलाव नहीं होता, और बेहतर उत्तर है repository में .gitattributes रखकर उसमें * text=auto eol=lf लिखना, जिससे हर clone एक जैसा बरताव करे। सेटिंग बदलने पर एक बार सारी फ़ाइलें बदली हुई दिख सकती हैं; यह एक बार फिर से निकालने की बात है, काम खोने की नहीं।The file will have its original line endings in your working directoryयह ऊपर की CRLF सूचना का दूसरा आधा हिस्सा है: यह कहता है कि डिस्क पर की फ़ाइल अपने मौजूदा line ending बनाए रखती है और केवल commit में सहेजी प्रति सामान्यीकृत होती है। यह उसी autocrlf सेटिंग से आता है, इसलिए अपने आप में कुछ टूटा नहीं है। पर यदि diff में पूरी-पूरी फ़ाइलें बदली दिखें तो यह संकेत है कि टीम के line ending अलग हैं: repository में .gitattributes रखकर नियम पक्का करें और एक बार git add --renormalize . चलाएँ। यह command केवल यह बदलता है कि line ending कैसे सहेजे जाते हैं, फ़ाइल की सामग्री नहीं।husky - pre-commit hook exited with code 1 (error)आपका commit बना ही नहीं: कोई hook — lint, test, formatter — शून्य से भिन्न कोड के साथ ख़त्म हुआ और git ने रोक दिया। असली कारण इस पंक्ति में नहीं, बल्कि इसके ऊपर hook के अपने output में है, आमतौर पर कोई lint नियम या type त्रुटि। hook ने जो बताया उसे ठीक करके दोबारा commit करना ही एकमात्र सच्चा उत्तर है। git commit --no-verify सभी commit hook छोड़ देता है और commit बना भी देता है, पर उसने जाँच पास नहीं की — उसने केवल असफलता CI पर टाल दी, और बिना format किया कोड सीधे आपके सहकर्मियों तक चला जाता है।

npm20

npm में कारण अंतिम छह npm ERR! पंक्तियों में नहीं, पहली code XXXX पंक्ति में लिखा होता है, और जब गड़बड़ी आपके कोड की जगह dependency के पेड़ या native build से आती है, तो node_modules मिटाकर फिर install करने से आधे मामले सुलझ जाते हैं।

npm ERR! ERESOLVE unable to resolve dependency treenpm 7 से peerDependencies की version सीमाएँ लागू होती हैं, और यह कह रहा है कि npm को ऐसा कोई संयोजन नहीं मिला जो सबको एक साथ संतुष्ट करे। यह आम है जब आप जो package लगा रहे हैं उसकी peer सीमा आपके पास पहले से मौजूद react या typescript के version को बाहर कर देती है — विशेषकर किसी major उन्नयन के तुरंत बाद। output की Found: और Could not resolve: पंक्तियाँ पढ़कर देखें कि कौन क्या माँग रहा है, फिर दोनों में से एक को अनुकूल version पर ले जाएँ: यही असली समाधान है। npm install --legacy-peer-deps peer सीमाओं को पूरी तरह अनदेखा करके लगा देता है, जिससे रास्ता खुल जाता है पर एक ऐसा पेड़ रह जाता है जिस पर package कभी राज़ी नहीं थे, इसलिए बेमेल version से आने वाली runtime त्रुटियाँ आपकी ज़िम्मेदारी हैं।npm ERR! Conflicting peer dependency: react@18.3.1यह पंक्ति ERESOLVE की रिपोर्ट के भीतर उस जोड़ी को चुनकर दिखाती है जो असल में टकरा रही है: यह package किसी peer का वह version माँगता है जबकि आपके पेड़ में दूसरा है। आमतौर पर इसका अर्थ है कि मुख्य library ने major छलाँग लगाई और उसका उपयोग करने वाला plugin अब तक पीछे है। npm ls react जैसे नाम से पूछने पर पेड़ के रूप में दिखता है कि किसने कौन-सा version माँगा, और वहीं साफ़ हो जाता है कि दोनों में से किसे हिलाना है। plugin को नए version पर लाना ही असली समाधान है; --force बेमेल पेड़ को फिर भी लिख देता है और समस्या को runtime तक छिपा रखता है।npm WARN react-dom@17.0.2 requires a peer of react@17.0.2 but none is installed.npm 6 peer निर्भरताओं के बारे में केवल चेतावनी देता था और उन्हें आपके लिए कभी नहीं लगाता था: package आ गया है, पर जिस साथी की उसे ज़रूरत बताई गई है वह नहीं। यह npm 6 पर बचे किसी project में दिखता है, या जब आप उस दौर का पुराना lockfile चला रहे हों। छपी सीमा के भीतर वाले version पर उस peer को स्वयं लगा दें, बात ख़त्म। अभी कुछ असफल नहीं हुआ क्योंकि यह केवल चेतावनी है, पर यह बाद में Cannot find module के रूप में, या एक ही library की दो प्रतियाँ बनकर बेतुकी त्रुटियों के रूप में लौट आती है।npm WARN deprecated request@2.88.2: request has been deprecatedpackage के लेखक ने उस version को अब अनुशंसित न होने का चिह्न दे दिया है: वह लग गया है और अब भी चलता है। यह आमतौर पर आपकी अपनी package.json की चीज़ नहीं, बल्कि आपके इस्तेमाल किए किसी package द्वारा खींच लाई गई परोक्ष निर्भरता है। npm ls request जैसे नाम से पूछने पर दिखता है कि आपकी कौन-सी सीधी निर्भरता उसे भीतर लाती है, और सुधार की जगह वही सीधी निर्भरता है, यह package नहीं। आज करने को कुछ नहीं है — deprecated कोई सुरक्षा दोष नहीं है, उसके बारे में npm audit बताता है।npm ERR! npm ci can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync.npm ci ठीक वही लगाता है जो lockfile में दर्ज है, और यह शुरू होने से पहले ही रुक गया क्योंकि package.json ऐसी चीज़ माँग रहा है जो lockfile में नहीं है। ऐसा तब होता है जब किसी ने package.json को हाथ से बदला या उसमें टकराव सुलझाया पर install न चलाया, या package.json को lockfile के बिना commit कर दिया। स्थानीय रूप से एक बार npm install चलाकर lockfile मिला लें, फिर उस lockfile को commit कर दें — यही पूरा सुधार है। इसे पार करने के लिए package-lock.json मिटा देने पर सारी निर्भरताएँ नए version पर दोबारा हल हो जाती हैं और आपके build की सामग्री चुपचाप बदल जाती है।npm ERR! The `npm ci` command can only install with an existing package-lock.json or npm-shrinkwrap.jsonnpm ci lockfile के बिना चलता ही नहीं, क्योंकि उसे बताने वाला कुछ नहीं होता कि कौन-से version लगाने हैं। ऐसा तब होता है जब package-lock.json .gitignore में हो, कभी commit ही न हुआ हो, या जिस डायरेक्टरी में आप खड़े हैं वह project की जड़ न हो। npm install --package-lock-only कुछ भी लगाए बिना केवल lockfile लिख देता है, और उसे commit करने से CI चल पड़ता है। package-lock.json को .gitignore में कभी न डालें: CI दो बार वही चीज़ बनाएगा — इसकी गारंटी उसी एक फ़ाइल पर टिकी है।npm ERR! Invalid Version:package.json का version क्षेत्र मान्य semver नहीं है, इसलिए npm उस package को पढ़ ही नहीं पाता। ऐसा 1.0, v1.0.0 या ख़ाली पंक्ति जैसे हाथ से लिखे मान पर होता है, विशेषकर उस फ़ाइल में टकराव ठीक से न सुलझने के बाद। npm pkg set version=1.0.0 सही तीन-हिस्सों वाला version वापस लिख देता है। यह command केवल package.json बदलता है और न node_modules को छूता है न lockfile को, इसलिए उसके बाद उस फ़ाइल को पढ़ने वाला हर command तुरंत फिर चलने लगता है।npm ERR! 404 Not Found - GET https://registry.npmjs.org/@acme/ui - Not foundregistry में उस नाम का कोई package नहीं है — 404 नाम के बारे में उत्तर है, आपके network या credential के बारे में नहीं। यह टाइपिंग की चूक पर, unpublish हो चुके package पर, या ऐसे निजी scope पर होता है जिसमें आपने login नहीं किया। पहुँच न रखने वाले के लिए निजी package बिल्कुल किसी अस्तित्वहीन package जैसा दिखता है, इसीलिए ये तीनों इसी एक पंक्ति में सिमट जाते हैं। npm view @acme/ui version पहले पुष्टि करता है कि वह नाम सार्वजनिक रूप से है या नहीं, और निजी scope के लिए देखें कि .npmrc में उस scope का registry और token लिखा है। दोनों जाँचें केवल पढ़ती हैं।npm ERR! request to https://registry.npmjs.org/express failed, reason: unable to verify the first certificateTLS संबंध विफल हुआ: सर्वर ने जो प्रमाणपत्रों की शृंखला पेश की वह ऐसी संस्था तक जाती है जिस पर node भरोसा नहीं करता। भारी बहुमत में यह ऐसा दफ़्तरी network होता है जिसका proxy आवागमन खोलकर अपने प्रमाणपत्र से फिर हस्ताक्षर करता है; कभी-कभी यह वह सर्वर होता है जिसने अपना मध्यवर्ती प्रमाणपत्र साथ नहीं भेजा। npm config set cafile से npm को अपनी कंपनी की जड़ बताना ही सही सुधार है। strict-ssl false से भी यह पंक्ति ग़ायब हो जाती है, पर वह प्रमाणपत्र की जाँच पूरी तरह बंद कर देता है, जिससे रास्ते में बैठा कोई भी आपको बदला हुआ package थमा सकता है — इसे न लगाएँ।npm ERR! code EINTEGRITYnpm ने जो tarball उतारा उसका hash lockfile में दर्ज मान से मेल नहीं खाता, इसलिए npm ने तय किया कि जो आया उस पर भरोसा नहीं किया जा सकता और वह रुक गया। यह बिगड़ी हुई cache प्रविष्टि है, या ऐसा proxy जिसने download बदल दिया, या कम बार ऐसा lockfile जिसका integrity मान हाथ से बदला गया या ठीक से merge न हुआ। npm cache clean --force स्थानीय cache ख़ाली कर देता है ताकि अगला install फिर से उतारे; यह केवल cache की प्रतियाँ मिटाता है और दोहराना सुरक्षित है। यदि यह किसी एक package पर लगातार हो, तो दर्ज integrity स्वयं ग़लत है और उस प्रविष्टि को npm install से फिर हल करना होगा।npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules'npm ने किसी ऐसी सिस्टम डायरेक्टरी में लिखने की कोशिश की जो आपके उपयोक्ता की नहीं है — package में कोई खोट नहीं, आपको वहाँ लिखने का अधिकार ही नहीं है। लगभग हमेशा यह ऐसे node पर npm install -g होता है जिसे operating system के package प्रबंधक ने /usr/local जैसी जगह पर रखा हो। npm config set prefix ~/.npm-global वैश्विक installation को आपकी home डायरेक्टरी में ले जाता है, और उसका bin PATH में आ जाने पर यह त्रुटि लौटती नहीं। sudo npm install -g चल भी जाता है, पर cache और node_modules में root के मालिकाने वाली फ़ाइलें छोड़ जाता है जो बाद में साधारण installation पर वही EACCES पैदा करती हैं; nvm जैसा version प्रबंधक इस पूरे वर्ग को मिटा देता है।npm ERR! enoent ENOENT: no such file or directory, open '/home/me/package.json'npm ने वर्तमान डायरेक्टरी और उससे ऊपर package.json ढूँढा और एक भी नहीं मिला — आपने npm का command ऐसी जगह चलाया जो project नहीं है। ऐसा तब होता है जब आप monorepo की जड़ पर खड़े हों और project किसी उप-folder में हो, जब आप clone किए folder के बग़ल में खड़े हों, या आप बस cd भूल गए हों। उत्तर है उस folder में जाना जिसमें package.json है, और ls से आँखों देख लेना सबसे तेज़ है। npm init -y केवल तब चलाएँ जब आप सचमुच यहाँ नया project शुरू करना चाहते हैं: ग़लत folder में चलाने पर छूटा हुआ package.json बाद में औज़ारों को भरमाता है।npm ERR! code ELIFECYCLEpackage.json का कोई script शून्य से भिन्न कोड के साथ ख़त्म हुआ — ELIFECYCLE उसके ऊपर npm का लपेटा है, कारण नहीं। कारण वह है जो आपके build या test script ने किया, और असली त्रुटि की पंक्तियाँ इससे ऊपर हैं। ऊपर जाकर पहली त्रुटि खोजें, या npm ERR! <pkg>@<ver> <script>: के बाद छपे असली command को हाथ से चलाकर देखें, तो npm के लपेटे के बिना उसका output दिखेगा। बाद में आने वाला exit code भी कुछ बताता है: 1 साधारण असफलता है, जबकि 137 का अर्थ है कि प्रक्रिया मार दी गई, आमतौर पर स्मृति के कारण।gyp ERR! build errorकिसी निर्भरता में C या C++ का हिस्सा है जिसे install के समय आपकी मशीन पर संकलित करना पड़ता है, और वह संकलन विफल हुआ — node-gyp को एक compiler और python चाहिए। ऐसा तब होता है जब कोई build toolchain लगी ही न हो, या जब package आपके node से पुराना हो और header मेल न खाएँ। toolchain लगाएँ: macOS पर xcode-select --install से command line tools, Debian या Ubuntu पर build-essential और python3, Windows पर Visual Studio का C++ workload। यदि package का नया version आपके node के लिए पहले से बना binary देता है, तो build वातावरण सुधारने से package को उन्नत करना बहुत तेज़ है।Error: Cannot find module 'express'node उस नाम को किसी भी फ़ाइल तक हल नहीं कर सका: वह node_modules में नहीं है, या आपने ऐसी डायरेक्टरी से चलाया जिसमें node_modules नहीं है। ऐसा तब होता है जब आपने install ही न किया हो, जब install बीच में विफल होकर आधा पेड़ छोड़ गया हो, या जब package devDependencies में हो और आपने --omit=dev से install किया हो। rm -rf node_modules && npm install lockfile से पेड़ फिर से बना देता है; यह सुरक्षित है, कुछ नहीं खोता, और लागत केवल उतारने का समय है। पर यदि उद्धरण के भीतर का नाम ./ से शुरू होने वाला सापेक्ष रास्ता है, तो कोई package ग़ायब नहीं — आपके ही कोड का रास्ता ग़लत है।Module not found: Error: Can't resolve './components/Button' in '/app/src'bundler को उस रास्ते पर वह फ़ाइल नहीं मिली — यह आपका ही import है, कोई package नहीं। ऐसा तब होता है जब सापेक्ष रास्ता एक स्तर खिसका हो, जब extension छूटा या ग़लत हो, या जब फ़ाइल के नाम का छोटा-बड़ा अक्षर import से अलग हो। अंतिम वाला सबसे कपटी है: macOS और Windows के filesystem छोटे-बड़े अक्षर में भेद नहीं करते, इसलिए आपकी मशीन पर चलता है और टूटता केवल Linux CI पर है। उस डायरेक्टरी का ls लें और import से अक्षर-दर-अक्षर, छोटे-बड़े अक्षर सहित मिलाएँ। यदि नाम रास्ता नहीं बल्कि package है तो उसे लगा दें; दोनों में से किसी भी हाल में कुछ मिटता नहीं।Error: error:0308010C:digital envelope routines::unsupportednode 17 के साथ OpenSSL 3 आया, जिसने एक पुराना hash algorithm डिफ़ॉल्ट से हटा दिया, और जो औज़ार अब भी उसे माँगता है वह उसी hash कॉल के भीतर गिर जाता है। यह लगभग हमेशा कोई पुराना webpack 4, या उसे भीतर समेटे कोई औज़ार, आधुनिक node पर चलने का मामला है। export NODE_OPTIONS=--openssl-legacy-provider उस प्रक्रिया भर के लिए पुराने algorithm फिर चालू कर देता है और build के लिए हानिरहित है। पर यह एक मरे औज़ार को ज़बरदस्ती ज़िंदा रखना है: webpack 5 या अपने framework के वर्तमान version पर जाने से इस विकल्प की ज़रूरत ही मिट जाती है।FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memoryV8 का heap अपनी ऊपरी सीमा से टकरा गया और node ने स्वयं हार मान ली — operating system ने उसे मारा नहीं, node ने तय किया कि वह और नहीं बढ़ सकता और रुक गया। कारण है कोई बड़ा type-check या bundle, बड़े project पर source map के साथ build, या रिसाव वाला कोड जैसे सब कुछ किसी array में जमा करते जाना। export NODE_OPTIONS=--max-old-space-size=4096 सीमा को 4 GB तक उठा देता है और अक्सर काफ़ी होता है, पर मशीन में उतनी RAM वास्तव में होनी चाहिए, और यदि किसी container की सीमा उससे कम हो तो इस बार operating system प्रक्रिया को मार देगा, जो exit code 137 के रूप में दिखता है। यदि संख्या बार-बार बढ़ानी पड़े, तो कारण सीमा नहीं, रिसाव है।npm WARN EBADENGINE Unsupported engineकोई package अपने engines में node या npm की ऐसी सीमा घोषित करता है जिसे आपका वातावरण पूरा नहीं करता — npm केवल चेतावनी देता है और लगा भी देता है। ऐसा तब होता है जब आप सिस्टम package के रूप में लगे पुराने node पर हों, या जब project आपके shell के node से नए node पर चला गया हो। अपने version प्रबंधक से node को छपी सीमा के भीतर वाले version पर बदल दें; भरोसे की चीज़ है project का .nvmrc या package.json का engines क्षेत्र। डिफ़ॉल्ट रूप से यह केवल चेतावनी है, पर .npmrc में engine-strict=true हो तो वही स्थिति installation रोक देने वाली त्रुटि बन जाती है।zsh: command not found: tscshell ने PATH छाना और उस नाम की कोई निष्पादन-योग्य फ़ाइल नहीं मिली — installation स्वयं सफल भी हो सकता है। ऐसा तब होता है जब npm की वैश्विक bin डायरेक्टरी PATH में न हो, जब आपने वैश्विक की जगह स्थानीय install किया हो और binary node_modules/.bin में चला गया हो, या जब shell पुराना PATH अपनी cache में पकड़े बैठा हो। npx tsc --version PATH को छुए बिना स्थानीय प्रति चला देता है, इसलिए वह एक पंक्ति "लगा नहीं है" और "PATH में नहीं है" को अलग कर देती है। यदि सचमुच वैश्विक install किया है, तो npm prefix -g के output के आगे /bin जोड़कर उस रास्ते को PATH में डालें और नया shell खोलें।

JavaScript15

browser और node की त्रुटियाँ आमतौर पर यही बताती हैं कि क्या टूटा, यह नहीं कि वह मान ऐसा क्यों बना — आपने undefined पढ़ा, वह function नहीं था, वह JSON नहीं था — इसलिए सुधार की जगह उस पंक्ति से ऊपर है जिसने त्रुटि फेंकी, और ?. तथा डिफ़ॉल्ट मानों से केवल उस पंक्ति को चुप कराने पर वही समस्या और दूर जाकर, और कठिन रूप में लौट आती है।

Uncaught TypeError: Cannot read properties of undefined (reading 'name')बिंदु के बाईं ओर का मान undefined है और आपने उसका गुण पढ़ लिया; कोष्ठक में लिखा नाम वह गुण है जो आप चाहते थे, इसलिए ख़राब चीज़ उससे पहले का मान है। यह अभी न पहुँची response, किसी के न भेजी prop, data.user.name जैसी एक परत ज़्यादा गहराई, या ख़ाली array पर arr[0].id से आता है। जहाँ मान वाक़ई वैकल्पिक है, वहाँ user?.name रास्ता काट देता है; पर अगर वह मान होना ही चाहिए था, तो ?. त्रुटि को केवल एक undefined में बदलकर अगली पंक्ति पर टाल देता है — ऊपर जाकर खोजें कि वह undefined क्यों है। Chrome 78 से पहले यही त्रुटि Cannot read property 'name' of undefined लिखी जाती थी।TypeError: items.map is not a functionवह नाम मौजूद है पर function नहीं है — अगर वह होता ही नहीं, तो संदेश undefined की बात करता। आम कारण: जिसे आपने array समझा वह असल में object या NodeList है, API array की जगह {data: [...]} लौटाता है, या module के default export का रूप आपने ग़लत समझा। अनुमान से पहले छापें: एक console.log(typeof items, items) इनमें से आधे मामले वहीं ख़त्म कर देता है। NodeList या Set को केवल Array.from(items) चाहिए; पर अगर वह {data: [...]} था, तो लपेटना ग़लत है और सही सुधार items = res.data है।RangeError: Maximum call stack size exceededकॉल इंजन की सीमा से भी गहरे ढेर हो गए, और यह आमतौर पर गहरी recursion नहीं, अनंत recursion होती है। ऐसा function जिसकी रुकने की शर्त नहीं है या पहुँचती नहीं, दो function जो एक-दूसरे को बुलाते हैं, अपने आप को समेटे object पर JSON.stringify, या React में ऐसा render जो उसी state को बदलता है जिस पर वह निर्भर है। console की stack में दो-तीन frames दोहराते हैं — वही जोड़ी लूप है, और base case वहीं जाता है। यदि गणना को सचमुच गहराई चाहिए, तो recursion को loop या स्पष्ट stack में बदलना ही एकमात्र रास्ता है: browser में stack की सीमा बढ़ाई नहीं जा सकती।SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSONआपने JSON.parse को जो दिया वह HTML था, JSON नहीं। संदेश में उद्धृत <!DOCTYPE टुकड़ा इसका सबूत है, और इसका अर्थ है कि server ने HTML पृष्ठ लौटाया — कोई 404, 502, या login की ओर redirect — इसलिए असली गड़बड़ी parse से पहले, request में है। आम कारण: ग़लत URL, development server का ऐसा proxy जिसने API की जगह index.html दिया, या समाप्त हो चुका session जो login पृष्ठ पर ले गया। res.json() बुलाने से पहले res.ok देखें, और res.text() पढ़कर देखें कि असल में क्या आया; उस URL को curl -s से सीधे मारना सबसे तेज़ तरीक़ा है। Chrome 111 और Node 20 से पहले यही त्रुटि Unexpected token < in JSON at position 0 लिखी जाती थी।SyntaxError: Unexpected end of JSON inputparser JSON पढ़ते-पढ़ते दस्तावेज़ के अंत तक पहुँच गया, और लगभग हमेशा body ख़ाली ही था। 204 No Content या बिना body वाली त्रुटि response पर res.json() बुलाना, response body को दो बार पढ़ना जिससे दूसरी बार ख़ाली आता है, या लिखते-लिखते कटी फ़ाइल पढ़ना। पहले पाठ के रूप में लें और parse से पहले जाँचें — const t = await res.text(); if (!t) return null; — इससे सटीक निदान मिलता है। JSON.parse(text || 'null') से ढक देना ख़ाली response को सामान्य बना देता है, इसलिए पहले पता करें कि server ने ख़ाली body क्यों भेजा।TypeError: Failed to fetchrequest बिना response ख़त्म हुआ, और browser जान-बूझकर कारण छिपाता है: CORS की रोक, मरा हुआ पता, ग़लत प्रमाणपत्र, और विज्ञापन रोकने वाला extension — सब यही दो शब्द देते हैं। यह फेंकी गई त्रुटि है, कोई status नहीं, इसलिए 404 या 500 यहाँ तक कभी नहीं आते — server जवाब देने तक पहुँचा ही नहीं। अक्सर console में या Network टैब में इसके ठीक ऊपर एक और अधिक विशिष्ट पंक्ति होती है, पहले उसे पढ़ें; और उस URL को curl -i से मारना "server गिरा है" और "browser ने मना किया" को अलग कर देता है। Firefox में यही स्थिति NetworkError when attempting to fetch resource के रूप में आती है।Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.request server तक पहुँचा और response भी आया, पर उस response में इस origin को अनुमति देने वाला header नहीं था, इसलिए browser ने उसे आपके JavaScript को देने से मना कर दिया। यह नियम केवल browser लागू करते हैं, इसीलिए वही URL curl से चल जाता है — लगता है कि server ठीक है और गड़बड़ी सिर्फ़ browser में है। सुधार हमेशा server पर होता है: response में Access-Control-Allow-Origin: http://localhost:3000 जोड़ें। frontend कुछ नहीं कर सकता, और यदि server आपका नहीं है तो अपने server के ज़रिए कॉल भेजने वाला proxy ही एकमात्र रास्ता है। Allow-Origin: * उन requests पर काम नहीं करता जो cookie भेजते हैं; उनके लिए सटीक origin और साथ में Allow-Credentials चाहिए।SyntaxError: Cannot use import statement outside a modulenode या browser ने उस फ़ाइल को CommonJS script के रूप में पढ़ा, और उसमें ESM का शब्द import मौजूद था। कोई .js फ़ाइल CommonJS ही मानी जाती है जब तक package.json कुछ और घोषित न करे, और browser में वही बात तब होती है जब <script> पर type="module" न हो। npm pkg set type=module पूरे package को ESM घोषित कर देता है और यह सुलझ जाता है, पर उस क्षण से उस package की हर .js में require और __dirname नहीं रहते, इसलिए बचे हुए CommonJS फ़ाइलों को भी साथ बदलना पड़ता है — अगर केवल एक फ़ाइल बदलनी है तो उसका नाम .mjs कर देना अधिक सीमित और सुरक्षित बदलाव है।ReferenceError: require is not defined in ES module scope, you can use import insteadयह पिछली त्रुटि का ठीक उल्टा दर्पण है — फ़ाइल ESM के रूप में पढ़ी जा रही है और उसमें CommonJS का require है। यह लगभग हमेशा package.json में "type": "module" जोड़ने के तुरंत बाद होता है, जब पुरानी scripts अभी पेड़ में पड़ी हों। उस एक फ़ाइल को पुरानी दुनिया में ही रखना हो तो mv script.js script.cjs सबसे सीमित बदलाव है; और आगे ले जाना हो तो require को import करने के साथ __dirname तथा require.main === module भी सँभालने पड़ते हैं, जो ESM में नहीं होते।Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/app/src/util' imported from /app/src/index.jsजब Node, ESM चलाता है तो वह import के रास्तों को browser की तरह अक्षरशः फ़ाइल-नाम मानता है, इसलिए './util', './util.js' नहीं है — वह एक ऐसी फ़ाइल है जो मौजूद नहीं। CommonJS आपके लिए extension आज़मा लेता था, और TypeScript बिना extension वाले import को संकलन के बाद भी वैसा ही छोड़ देता है, इसीलिए tsc से बने project को पहली बार node से चलाने पर ये ढेरों निकलते हैं। सापेक्ष import में .js extension जोड़ें; TypeScript फ़ाइल के भीतर भी './util.js' ही लिखा जाता है, क्योंकि Node जो पढ़ेगा वह संकलित परिणाम है। node_modules के package नामों पर extension नहीं लगता।ReferenceError: window is not definedवह कोड browser में नहीं, server के Node के भीतर चला। Node में न window है, न document, न localStorage; इसलिए Next.js या Nuxt जैसे ढाँचे में, जहाँ पहले server पर render होता है, module लोड होते समय window छूने पर यहीं रुक जाता है — अक्सर यह component के बाहर पड़ी एक ही पंक्ति होती है, या किसी केवल-browser library का import ही। यदि काम केवल browser का है तो उसे typeof window !== 'undefined' से घेरें, या इससे बेहतर, उसे useEffect के भीतर ले जाएँ — क्योंकि effect केवल browser में चलता है। जब पूरी library केवल browser की हो, तो Next.js में dynamic(() => import('./C'), { ssr: false }) से उसे server render से बाहर रखना उत्तर है, इस क़ीमत पर कि वह हिस्सा server से बने HTML में नहीं होगा।Hydration failed because the initial UI does not match what was rendered on the serverserver ने जो HTML भेजा और browser ने अपने पहले render में जो बनाया, वे अलग हैं, इसलिए React दोनों को जोड़ नहीं सका। render के भीतर new Date() या Math.random() इस्तेमाल करना, localStorage पढ़ना, या window की चौड़ाई के अनुसार अलग बनाना — इनसे दो अलग उत्तर पक्के हैं; और वही बात उस markup की है जिसे browser चुपचाप सुधार देता है, जैसे <p> के भीतर <div>। नियम है: पहले चरण में ठीक वही render करें जो server ने किया, और बदलाव useEffect चलने के बाद करें; क़ीमत यह कि वह हिस्सा एक क्षण देर से दिखता है और server के HTML में नहीं होता। React 19 इसी स्थिति को "the server rendered HTML didn't match the client" लिखता है और क्या भिन्न था उसका diff भी दिखाता है।Objects are not valid as a React child (found: object with keys {name, id})जिस मान को आपने React से दिखाने को कहा वह string या संख्या नहीं, object है, और कोष्ठक में दी keys की सूची बताती है कि वह कौन सा object है। आमतौर पर जहाँ {user} लिखा है वहाँ {user.name} होना चाहिए, या आपने पूरा response ही दिखाने की कोशिश की। यदि keys की सूची के बजाय found: [object Promise] दिखे तो कारण अलग है: आपने किसी async function का परिणाम await किए बिना दिखा दिया। दिखाने के लिए फ़ील्ड चुनना ही उपाय है; debug करते समय JSON.stringify(user) एक झलक के लिए ठीक है, पर उसे परदे पर छोड़ें नहीं।Each child in a list should have a unique "key" prop.सूची के रूप में दिखाए गए सहोदर तत्वों पर key नहीं है, इसलिए अगले render में React उन्हें उन्हीं वस्तुओं से जोड़ नहीं सकता। आपने items.map(...) से तत्व बनाए और key छोड़ दिया; यह केवल चेतावनी है, परदा बन जाता है, पर सूची बदलने पर यह चुपचाप गड़बड़ी बनकर लौटता है — लक्षण यह कि किसी input का मान या कोई animation ग़लत पंक्ति पर रह जाता है। अपने डेटा से कोई स्थिर id दें। array के index को key बनाना केवल उसी सूची में सुरक्षित है जिसका क्रम कभी नहीं बदलता और जिसमें बीच में कुछ जोड़ा या हटाया नहीं जाता; वरना वह लगभग वही समस्या दोहराता है जो key न होने से होती है। React 19 से शुरुआत में लगने वाला Warning: हट गया है।Too many re-renders. React limits the number of renders to prevent an infinite loop.किसी render ने state बदला, उस state ने फिर render कराया, और React ने अनंत चक्र रोकने के लिए उसे काट दिया। लगभग हमेशा यह वहाँ function बुला देना होता है जहाँ उसे भेजना था: onClick={setOpen(true)} हर render पर चल जाता है, और होना चाहिए onClick={() => setOpen(true)}। दूसरे आम रूप हैं — render के मुख्य भाग में सीधे state बदलना, और ऐसा useEffect जिसकी dependency सूची में वही मान है जिसे वह अद्यतन करता है। state बदलने का काम event handler या useEffect के भीतर ले जाएँ, और यदि वह मान render के दौरान गणना से मिल सकता है तो सोचें कि उसे state होना ही चाहिए या नहीं।

Python18

Python का traceback उत्तर को दो हिस्सों में बाँटता है — अंतिम पंक्ति बताती है कि क्या ग़लत हुआ, और उसके ऊपर के frames बताते हैं कि कहाँ — इसलिए केवल अंतिम पंक्ति पढ़ने पर नाम मिलता है और जगह छूट जाती है; और NoneType तथा KeyError जैसी "मान नहीं है" वाली त्रुटियों में कारण लगभग हमेशा उस frame से ऊपर होता है जहाँ गिरा।

ModuleNotFoundError: No module named 'requests'Python ने sys.path की सारी डायरेक्टरी देख लीं और उस नाम का कोई module नहीं मिला। या तो वह कभी install ही नहीं हुआ, या किसी दूसरे interpreter के लिए हुआ — virtual environment के बाहर pip install करके अंदर चलाने पर ठीक यही होता है। python -m pip install लिखने पर वह उसी interpreter में जाता है जिसे आप असल में चला रहे हैं, और यह बेमेल ख़त्म हो जाता है।error: externally-managed-environmentयह Python operating system या Homebrew का है, और pip उसमें लिखने से मना कर रहा है (PEP 668)। आपने system के interpreter पर pip install चलाया; यह संदेश कह रहा है कि virtual environment बनाइए। --break-system-packages नाम के मुताबिक़ काम करता है और apt द्वारा सँभाली फ़ाइलों को टूटी हालत में छोड़ सकता है, इसलिए .venv बनाकर उसी में install करें।ImportError: cannot import name 'User' from partially initialized module 'models' (most likely due to a circular import)दो module एक-दूसरे को import करते हैं, इसलिए आपने ऐसे module से नाम माँगा जो अभी आधा ही लोड हुआ है। यह A, B को और B, A को import करने वाले ढाँचे से आता है, और फ़ाइल बाँटने के तुरंत बाद जब एक type hint के लिए import उलटी दिशा में लौट आता है, तब आम है। from y import Thing को import y कर दें और function के भीतर y.Thing लिखें: खोज बाद में होती है और चक्र मायने नहीं रखता।IndentationError: unexpected indentयह पंक्ति पिछली से ज़्यादा भीतर है, और ऊपर कुछ ऐसा नहीं है जिसने block खोला हो और यह अतिरिक्त स्तर जायज़ ठहराए। आमतौर पर आपने ऐसा कोड चिपकाया जो अपने साथ शुरुआती space लाया, या if की पंक्ति मिटा दी और उसका भाग indent में ही छोड़ दिया। त्रुटि जिस पंक्ति की ओर इशारा करती है, उसका शुरुआती whitespace हटा दें; फ़र्क़ न दिखे तो उस पंक्ति को cat -A से छापिए, space और tab दिख जाएँगे।TabError: inconsistent use of tabs and spaces in indentationएक ही block के भीतर tab और space मिल गए हैं, इसलिए Python तय नहीं कर पाता कि कौन सी पंक्ति ज़्यादा गहरी है। यह तब होता है जब आप tab डालने वाले editor से कोड चिपकाते हैं, या दो लोग अलग-अलग सेटिंग से वही फ़ाइल छूते हैं; परदे पर पंक्तियाँ एक जैसी दिखती हैं, आँख से नहीं मिलेगा। python -m tabnanny app.py गड़बड़ पंक्तियों के नंबर छापता है, और बाक़ी काम editor में उस फ़ाइल को पूरी तरह चार space पर लाना है।SyntaxError: invalid syntaxparser वहाँ मिली चीज़ से कोई कथन नहीं बना सका, और कारण अक्सर उस पंक्ति में नहीं जिस पर इशारा है, बल्कि उससे पहले वाली में होता है। बिना बंद किया कोष्ठक या उद्धरण, छूटा colon, या Python 2 का print "x" आम कारण हैं — कोष्ठक खुला रह जाए तो parser कई पंक्तियाँ आगे जाकर हार मानता है। python -m py_compile app.py कुछ चलाए बिना केवल वाक्य-रचना जाँचता है, और 3.10 से संदेश बहुत अधिक स्पष्ट हैं, इसलिए Python को नया करना ही एक जाँच है।TypeError: 'NoneType' object is not subscriptableजिस मान को आपने [...] से निकालने की कोशिश की, वह None है। ऊपर कहीं किसी चीज़ ने चुपचाप None लौटाया: अनुपस्थित key पर dict.get(), न मिलने वाला re.match, या उस रास्ते पर बिना return वाला function। दुर्घटनास्थल पर पहरा लगाने के बजाय ऊपर जाकर देखें कि None क्यों आया — None को छोड़ देने वाला एक if उसी त्रुटि को अगली पंक्ति पर सरका देता है।AttributeError: 'NoneType' object has no attribute 'get'बिंदु के बाईं ओर की वस्तु None है, इसलिए माँगा गया गुण या method मौजूद नहीं है। इसकी जड़ nonetype-not-subscriptable वाली ही है, और यह ख़ासकर तब दिखता है जब आप ऐसे function के परिणाम पर सीधे आगे लिखते हैं जो न मिलने पर None देता है, जैसे BeautifulSoup का find() या re.search()। पहले छापकर देखें कि वह function क्या खोज रहा था, और अगर कुछ न मिलना जायज़ स्थिति है तो उस शाखा को स्पष्ट रूप से सँभालें।KeyError: 'name'वह key dict में नहीं है, और उद्धरण के भीतर का पाठ ठीक वही key है जिसे खोजा गया — वहीं से शुरू करें, क्योंकि आमतौर पर यह टाइपिंग की चूक, बड़े-छोटे अक्षर का अंतर, या API उत्तर का ढाँचा आपकी कल्पना से अलग होना होता है। यदि मान वास्तव में वैकल्पिक है तो d.get("name") None देता है और d.get("name", 0) एक डिफ़ॉल्ट; पर अनिवार्य मान पर .get लगाने से त्रुटि की जगह एक None आपके कोड में बहता है और बहुत दूर जाकर फूटता है।IndexError: list index out of rangeआपने वह स्थान माँगा जो सूची में नहीं है। लंबाई n हो तो अंतिम वैध क्रमांक n-1 होता है, इसलिए range(len(x) + 1) और x[len(x)] हमेशा यहीं रुकते हैं, और ख़ाली सूची पर x[0] भी वही त्रुटि है — तब आम, जब ऊपर के किसी filter या split ने कुछ न छोड़ा हो। क्रमांक से घूमने की जगह for item in items: से घूमने पर यह पूरी श्रेणी की गड़बड़ी जड़ से मिट जाती है, और स्थान सच में चाहिए तो enumerate(items) दे देता है।ValueError: invalid literal for int() with base 10: '3.5'आपने int() को ऐसी string दी जिसे वह पूर्ण संख्या के रूप में नहीं पढ़ सकता, और उद्धरण के भीतर का पाठ वही string है। '3.5' जैसा दशमलव बिंदु, ख़ाली string, अंत में newline वाला इनपुट, या '1,000' जैसा हज़ार का विभाजक आम कारण हैं। दशमलव के लिए int(float(s)) दो चरणों में चलता है — पर यह गोल करने की जगह भिन्नात्मक भाग काट देता है — और किसी व्यक्ति द्वारा टाइप किए मान के लिए try/except ValueError में लपेटना ही ईमानदार उपाय है।UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byteआपने किसी फ़ाइल या byte श्रेणी को UTF-8 मानकर पढ़ा और ऐसा byte मिला जिसकी UTF-8 अनुमति नहीं देता; संदेश में स्थान और byte दोनों लिखे हैं। आमतौर पर फ़ाइल Windows से आई cp1252 या कोई पुरानी encoding होती है, या वह पाठ ही नहीं होती — कोई चित्र, zip, या बिना खोला gzip डेटा। सही उपाय असली encoding पता करके उसे encoding= में देना है; errors="replace" पढ़ाई पूरी करा देता है पर उन bytes को प्रश्नचिह्न बना देता है, और डेटा चुपचाप बिगड़ा हुआ आगे चला जाता है।ZeroDivisionError: division by zeroकिसी चीज़ को शून्य से भाग दिया गया — और व्यवहार में भाजक कोई अक्षरशः शून्य नहीं होता, वह गिनती होती है जो शून्य निकली। औसत निकालने वाला कोड जहाँ सूची ख़ाली रह गई, या ऐसा filter जिससे कुछ न मिला, इसका शास्त्रीय स्रोत है: विकास के डेटा पर यह हमेशा पास होता है और पहली बार production में गिरता है। भाग देने से पहले भाजक जाँचें और तय करें कि वहाँ शून्य का अर्थ क्या है; 0 लौटाना, None लौटाना, और अपवाद को ऊपर जाने देना तीन अलग निर्णय हैं, और हर एक कहीं सही है।RecursionError: maximum recursion depth exceededकिसी function ने अपने आप को डिफ़ॉल्ट सीमा 1000 frames से भी गहरा बुलाया। सचमुच गहरी गणना की तुलना में कहीं ज़्यादा बार इसका अर्थ है कि रुकने की शर्त नहीं है या उस तक पहुँचा ही नहीं जाता; अप्रत्यक्ष recursion भी इसमें आती है, जैसे कोई __getattr__ या property जो अपना ही गुण फिर पढ़ता है। पहले traceback में दोहराए जा रहे दो-तीन frames खोजिए और base case ठीक कीजिए। sys.setrecursionlimit() सीमा बढ़ा देता है, पर वह असली C stack पार करने देता है, और तब Python अपवाद उठाने के बजाय पूरा ही मर जाता है — recursion को loop में बदलना सुरक्षित उत्तर है।UnboundLocalError: cannot access local variable 'count' where it is not associated with a valueअगर किसी function के भीतर कहीं भी उस नाम को कुछ सौंपा जाता है, तो Python उस नाम को function का स्थानीय चर मान लेता है — और आपने उसे सौंपे जाने से पहले पढ़ लिया। यह तब दिखता है जब आपने उसी नाम का बाहरी मान दिखने की अपेक्षा की थी, या जब आप पहली बार count += 1 जैसी पढ़ने-लिखने वाली क्रिया लिखते हैं। function के भीतर count = 0 से शुरू करना आम उत्तर है; और अगर module स्तर का मान बदलना ही ज़रूरी हो तो global count वह करता है, इस क़ीमत पर कि उस मान को कौन बदलता है यह ट्रैक करना कठिन हो जाता है। 3.10 तक यही त्रुटि 'local variable referenced before assignment' लिखी जाती थी।TypeError: greet() takes 1 positional argument but 2 were givenआपने function की स्वीकार सीमा से एक तर्क अधिक भेजा, और जब अंतर ठीक एक का हो तो वह लगभग हमेशा self होता है। किसी class के भीतर method को def greet(name): के रूप में परिभाषित करें और obj.greet("x") बुलाएँ, तो Python obj को पहला तर्क बनाकर भेजता है — इससे दो हो जाते हैं। यदि यह method है तो उसे def greet(self, name): कर दें ताकि वह self ले; और यदि उसे instance की ज़रूरत ही नहीं, तो उस पर @staticmethod लगाएँ।PermissionError: [Errno 13] Permission deniedoperating system ने उस रास्ते पर वह काम करने से मना कर दिया। आप /var/log या /usr जैसी किसी और की जगह पर लिख रहे थे, या container में ऐसे mounted volume पर जिसका UID container के उपयोगकर्ता से मेल नहीं खाता, या — जो चूक जाता है — आपके पास फ़ाइल की नहीं, उस डायरेक्टरी की लिखने की अनुमति नहीं है, और नई फ़ाइल बनाने के लिए वही चाहिए। पहले ls -ld से स्वामी और mode देखें, और sudo की ओर बढ़ने से पहले रास्ते को ऐसी जगह ले जाने पर विचार करें जहाँ आप लिख सकते हैं: sudo से बनी फ़ाइल अगली बार sudo के बिना खोलने पर वही त्रुटि देगी।OSError: [Errno 98] Address already in usebind इसलिए विफल हुआ कि उस port को कोई दूसरी प्रक्रिया पहले से पकड़े है। या तो पिछला server पूरी तरह मरा नहीं, या किसी auto-reloader ने दो प्रतियाँ चला दीं, या कोई Docker container वही port पहले से प्रकाशित कर रहा है। lsof -i :8000 वह PID बता देता है जो उसे पकड़े है, ताकि आप केवल उसे हटाएँ — kill -9 करने से पहले प्रक्रिया का नाम पढ़ लें। errno हर system में अलग है: Linux यहाँ 98 छापता है, macOS 48।

बिल्ड और टाइप10

build की त्रुटियाँ किसी औज़ार का चलने से पहले मना कर देना हैं, इसलिए प्रकट होते समय वे कुछ तोड़ती नहीं — पर वे दो सवाल पूछती हैं: क्या आप type या रास्ता असली रूप के अनुसार सुधारेंगे, या as any अथवा दमन-टिप्पणी से उस एक पंक्ति को पार करा देंगे — और यहीं पहली बार वे चीज़ें सामने आती हैं जो केवल आपकी मशीन पर सही हैं: अक्षरों के बड़े-छोटे रूप, extension, और environment variables।

error TS2307: Cannot find module 'lodash' or its corresponding type declarations.tsc को न वह module मिला, न उसके लिए कोई type घोषणा, और यह मायने रखता है कि संदेश दोनों बातें कहता है — package पूरा ग़ायब हो सकता है, या स्थापित हो पर उसमें type न हों। यदि वह स्थापित है तो कमी type की है: npm i -D @types/lodash साथी package जोड़ देता है, हालाँकि आज के बहुत से package अपने type साथ लाते हैं और उनका @types ही नहीं होता। और यदि यह किसी सापेक्ष import पर आए तो अक्षरों के बड़े-छोटे रूप और tsconfig की paths देखें — आपकी ही फ़ाइलों की ओर जाने वाले रास्ते का @types से कोई नाता नहीं।error TS2339: Property 'user' does not exist on type 'Request'.वह type उस गुण की घोषणा नहीं करता। यह तब आता है जब आप library के type में न होने वाला कोई फ़ील्ड जोड़ते हैं (Express के Request पर user लगाना इसका उदाहरण है), या टाइपिंग की चूक हो, या बिना संकुचित किए union के केवल एक सदस्य पर मौजूद गुण पढ़ा जाए। असली रूप के अनुसार type सुधारना ही उत्तर है, और union हो तो 'x' in y या किसी विभेदक फ़ील्ड से संकुचित करने पर उस शाखा के भीतर पहुँच खुल जाती है। as any से चुप कराना केवल compiler का मुँह बंद करता है: वह जगह अब ग़लत हिज्जे वाला गुण-नाम भी पास कर देगी।error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.function जो type स्वीकार करता है और आपने जो type दिया, वे भिन्न हैं, और संदेश उन्हें क्रम से बताता है — पहले आपका दिया हुआ, फिर अपेक्षित। सबसे आम मामला यह है कि form के किसी field, URL की query string, या JSON से आया मान string के रूप में वहाँ पहुँचता है जहाँ संख्या अपेक्षित है। सीमा पर एक बार रूपांतरण करना उत्तर है, पर Number(value) विफल होने पर अपवाद नहीं, NaN लौटाता है, इसलिए उस NaN को आगे बहने से रोकना पड़ता है — Number.isFinite(n) वहीं की जाँच है।error TS18048: 'user' is possibly 'undefined'.वह मान undefined हो सकता है और आपने उस संभावना को सँभाला नहीं; यह tsc का आपके लिए भविष्य का Cannot read properties of undefined पकड़ लेना है। यह वैकल्पिक fields पर, array के find() के परिणाम पर, और उन environment variables पर आता है जो सेट न हों। उपाय यह तय करना है कि न होने पर क्या होगा: शुरू में ही if (!user) return null से काट दें, या user?.name से छोटा रास्ता लें। user!.name लिखकर चुप कराना यह घोषणा है कि आप गारंटी देते हैं — और गारंटी ग़लत निकले तो वह चलने के समय अपवाद बनकर लौटता है, उस सुरक्षा-जाल के बिना जो एक जाँच छोड़ जाती।error TS7006: Parameter 'req' implicitly has an 'any' type.उस parameter पर कोई type लिखा नहीं है और tsc के पास अनुमान लगाने का आधार भी नहीं था, इसलिए वह अंतर्निहित रूप से any बन गया — और noImplicitAny चालू हो तो उसे त्रुटि माना जाता है। यह JavaScript से लाए गए फ़ाइलों में, और तब आता है जब callback को अलग चर में निकाल लिया जाए; इसके उलट items.map(x => ...) की तरह inline लिखे callback को संदर्भ मिलता है, tsc अनुमान लगा लेता है और यह कभी नहीं आता। वहाँ type लिख देना ही उपाय है। आप स्पष्ट रूप से any भी लिख सकते हैं, पर वह उस parameter की जाँच पूरी तरह बंद करने का निर्णय है — जब पता न हो कि वह क्या है, तो unknown अधिक ईमानदार है और उपयोग से पहले संकुचित करने को बाध्य करता है।Parsing error: Unexpected tokenESLint उस फ़ाइल पर कोई नियम लगाने से पहले, वाक्य-रचना पढ़ने के चरण में ही रुक गया। कोड के वाक़ई टूटे होने से कहीं ज़्यादा बार इसका अर्थ है कि parser उस वाक्य-रचना को नहीं जानता — TypeScript फ़ाइल को डिफ़ॉल्ट parser से पढ़ना, JSX चालू न होना, या decorators और बहुत नई वाक्य-रचना पुराने parser को थमा देना। उस ठीक फ़ाइल पर npx eslint --print-config app.ts चलाने से दिख जाता है कि असल में कौन सा parser और कौन से parserOptions लागू हैं, इसलिए अनुमान से पहले वही देखें। TypeScript के लिए @typescript-eslint/parser चाहिए, और यदि उस फ़ाइल की जाँच ही नहीं होनी चाहिए तो उसे ignores में रखना सही उत्तर है।You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.यह वह पंक्ति है जो webpack, Module parse failed के बाद जोड़ता है, और इसका अर्थ है कि उसने उस फ़ाइल को JavaScript मानकर पढ़ने की कोशिश की और वह JavaScript नहीं थी। या तो आपने ऐसी चीज़ import की जिसे रूपांतरण चाहिए — TypeScript, JSX, CSS, कोई चित्र, कोई .vue फ़ाइल — और module.rules में उसका नियम नहीं है, या node_modules का कोई package बिना संकलित स्रोत भेजता है जबकि वह फ़ोल्डर आपके exclude में है। उस extension के लिए module.rules में एक loader नियम जोड़ना ही उपाय है, और किस फ़ाइल पर रुका यह संदेश के ऊपर छपा रास्ता बताता है। exclude: /node_modules/ मिटाकर इसे भगाने से पूरा build साफ़ तौर पर धीमा होता है; केवल उस एक package को अपवाद बनाना बेहतर सौदा है।Failed to resolve import "./utils" from "src/main.ts". Does the file exist?उस रास्ते पर कुछ नहीं मिला, और साथ छपा "Does the file exist?" उन तीन चीज़ों की ओर इशारा करता है जिन्हें असल में जाँचना चाहिए: अक्षरों के बड़े-छोटे रूप, extension, और tsconfig या vite.config का कोई alias। macOS और Windows के filesystem बड़े-छोटे अक्षर का भेद नहीं करते, इसलिए ./Utils आपकी मशीन पर चल जाता है और पहली बार CI या तैनाती पर टूटता है, जहाँ Linux भेद करता है — यह त्रुटि "मेरी मशीन पर तो चलता है" की सबसे आम पहचान है। git ls-files src | grep -i utils से दिखता है कि repository में असल में कौन-से हिज्जे हैं। @/utils जैसे alias के लिए vite.config का resolve.alias और tsconfig का paths दोनों मेल खाने चाहिए; केवल एक ठीक करने पर editor चुप रहता है और build टूटा ही रहता है।You're importing a component that needs useState. This React hook only works in a client component.App Router में हर component डिफ़ॉल्ट रूप से server component होता है, और किसी server component ने ऐसी फ़ाइल import की जो useState जैसा hook इस्तेमाल करती है, जिसका अर्थ केवल browser में है। निर्देश फ़ाइल के सबसे ऊपर 'use client' की एक पंक्ति है, और उसे लगाने पर वह फ़ाइल तथा वह जो कुछ import करती है, सब client के bundle में चला जाता है — इसीलिए पूरे पृष्ठ की जगह उस सबसे छोटे टुकड़े पर लगाना सस्ता विकल्प है जिसे state चाहिए। उलटी दिशा में, इस तरह बाँटना कि client component अपने children के रूप में server component ले, data लाने का काम server पर ही रखता है। Next.js 13 में यही स्थिति "It only works in a Client Component but none of its parents are marked with \"use client\"" लिखी जाती थी।The engine "node" is incompatible with this module. Expected version ">=20"जो package आप स्थापित कर रहे हैं, वह package.json के engines में बताता है कि उसे कौन-कौन से node संस्करण चाहिए, और आपका संस्करण उस दायरे से बाहर है। आगे आने वाले Expected और Got आवश्यकता तथा आपके संस्करण को साथ रखकर दिखाते हैं, इसलिए वही दो पंक्तियाँ पर्याप्त हैं — और यदि यह केवल CI पर होता है, तो वहाँ का node संस्करण आपकी मशीन से भिन्न है। nvm install 20 && nvm use 20 से node बढ़ाना सीधा उत्तर है, और वही संस्करण .nvmrc तथा CI विन्यास में लिख देने पर वे फिर अलग नहीं होते। yarn का --ignore-engines आगे बढ़ा देता है, पर वह चेतावनी हटाता है, संगतता नहीं बनाता: यदि वह package नई वाक्य-रचना इस्तेमाल करता है तो वह चलते समय syntax त्रुटि बनकर गिरेगा। npm इसी स्थिति को EBADENGINE चेतावनी के रूप में बताता है और डिफ़ॉल्ट रूप से स्थापना रोकता नहीं।

Docker12

docker की त्रुटियाँ तभी पढ़ी जाती हैं जब आप उन्हें परत के हिसाब से बाँट लें — client का daemon तक न पहुँचना, registry का मना करना, build के दौरान किसी RUN का विफल होना, और container का चालू होते ही मर जाना — ये चार अलग समस्याएँ हैं; और build तथा चलने की परतों में पंक्ति स्वयं कारण नहीं होती: कारण उस आदेश के output में होता है जो भीतर चल रहा था, और हर उपाय की क़ीमत भी परत के अनुसार बदलती है।

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?docker आदेश ख़ुद कुछ नहीं करता — वह उस socket के ज़रिए एक daemon से काम कराता है, और कोई जवाब नहीं आया। या daemon चल नहीं रहा, या macOS/Windows पर Docker Desktop का शुरू होना पूरा नहीं हुआ, या Linux पर आपका उपयोगकर्ता docker समूह में नहीं है और socket खोल नहीं सकता; तीनों यही एक पंक्ति देते हैं। Linux पर sudo systemctl start docker से चालू करें; Desktop हो तो पहले ऐप खोलें। अनुमति का मामला हो तो sudo usermod -aG docker $USER और फिर नया login ठीक कर देता है — पर ध्यान रहे कि वह समूह व्यवहार में root के बराबर ताक़त देता है।Bind for 0.0.0.0:8080 failed: port is already allocatedआपने -p से host का वह port माँगा, और उसे कोई दूसरा container या प्रक्रिया पहले से पकड़े है। अधिकतर मामलों में पहले --rm के बिना चलाया गया container रुका हुआ या चलता हुआ वहीं पड़ा है, या compose अब भी कोई पुराना container थामे है। docker ps --filter publish=8080 सीधे उस container की ओर इशारा करता है जो उसे प्रकाशित कर रहा है; और अगर वह container न होकर host का कोई सामान्य कार्यक्रम निकले तो lsof -i :8080 उसे ढूँढ़ लेता है। केवल host की तरफ़ बदलना, जैसे -p 8081:80, आपको आगे बढ़ा देता है, पर पुराना container वहीं छोड़ देने का मतलब अगली बार भी वही टकराव है।Conflict. The container name "/api" is already in use by container--name से दिया गया नाम पहले से किसी दूसरे container का है। नाम केवल चलते container में नहीं, रुके हुए container में भी अनूठा होता है, इसलिए आमतौर पर कल मरा हुआ container उसे थामे रहता है — docker ps में नहीं दिखता, केवल docker ps -a में। docker rm -f api नाम मुक्त कर देता है, और साथ ही उस container की लिखने योग्य परत भी मिटा देता है (नाम वाले volume बचे रहते हैं)। एक बार के काम के container के लिए शुरू से docker run --rm लगाने पर यह स्थिति ही नहीं बनती।failed to register layer: Error processing tar file(exit status 1): no space left on deviceimage की परत खोलने के लिए डिस्क पर जगह नहीं है। आमतौर पर परियोजना बड़ी नहीं होती; Docker ही महीनों की पुरानी images, build cache और हटाए गए containers के volume थामे बैठा है। docker system df बताता है कि images, containers, volumes और build cache में कितना पड़ा है और उसमें से कितना वापस मिल सकता है, इसलिए कुछ भी मिटाने से पहले वही पढ़ें। docker system prune रुके containers, लटकती images, अप्रयुक्त networks और build cache हटाता है — वह cache जाने के बाद अगला build साफ़ तौर पर धीमा होता है — और --volumes जोड़ने पर वे volume भी मिट जाते हैं जो किसी container से जुड़े नहीं हैं, और ठीक यहीं लोग अपने database खोते हैं।pull access denied for myapp, repository does not exist or may require 'docker login'registry ने वह repository आपको नहीं दिखाया, और मुख्य बात यह है कि यह संदेश एक साथ दो कारण समेटता है — या नाम मौजूद नहीं है, या मौजूद है पर आपको देखने की अनुमति नहीं। या तो निजी repository के लिए आप login नहीं हैं, या नाम में उपयोगकर्ता/संगठन छूट गया है (myapp और myorg/myapp अलग repository हैं), या नाम ही ग़लत है। निजी image हो तो उस registry पर docker login करें; और यदि वह सार्वजनिक होनी चाहिए थी तो हिज्जे फिर पढ़ें। registry जान-बूझकर "नहीं है" और "नहीं दिखा सकते" में भेद नहीं करते — क्योंकि किसी नाम का होना ही एक सूचना है।manifest for myapp:v2 not found: manifest unknownrepository मिल गया, पर वह tag उसके भीतर नहीं है। pull access denied से उलट, यह संदेश बताता है कि नाम सही था, इसलिए अब देखना बस tag है — मिटाया या हटाया गया tag, ऐसी pipeline जिसने latest चढ़ाया पर v2 कभी बनाया नहीं, या ऐसा tag जिसमें आपकी architecture के लिए image नहीं है। docker manifest inspect myapp:v2 से पुष्टि होती है कि वह tag हल होता है या नहीं और उसमें कौन-कौन से platform हैं। आगे बढ़ने के लिए latest पर स्विच करना एक ऐसे build की क़ीमत लेता है जिसे दोहराया नहीं जा सकता, इसलिए tag ही ठीक करें।unauthorized: incorrect username or passwordregistry ने भेजे गए प्रमाण अस्वीकार कर दिए। ग़लत टाइप किए पासवर्ड से ज़्यादा आम यह है कि पासवर्ड ऐसे registry को भेजा गया जो अब खाते के पासवर्ड लेता ही नहीं — Docker Hub दो-चरणीय सत्यापन चालू होने पर केवल access token लेता है, और GitHub तथा GitLab के registry शुरू से token या deploy key ही चाहते हैं। docker logout सहेजा हुआ प्रमाण मिटा देता है, फिर token से दोबारा docker login करें। इसे echo $TOKEN | docker login -u user --password-stdin के रूप में देने पर token shell के इतिहास में नहीं रहता।failed to solve: process "/bin/sh -c npm ci" did not complete successfully: exit code: 1आपके Dockerfile की वह RUN पंक्ति शून्य से भिन्न स्थिति के साथ ख़त्म हुई। इस पंक्ति में इतना ही है कि कौन सा आदेश विफल हुआ और किस कोड से; असली कारण ऊपर उसी आदेश के output में है, जिसे BuildKit चरण पूरा होते ही समेट देता है। docker build --progress=plain से दोबारा चलाने पर हर चरण का पूरा output छपता है, और अगर कोई cache की परत पुरानी विफलता छिपा रही है तो --no-cache भी जोड़ें — क़ीमत यह कि सब कुछ पहले चरण से फिर बनता है। exit code: 1 कारण नहीं है, केवल यह तथ्य कि आदेश विफल हुआ।COPY failed: file not found in build context or excluded by .dockerignoreCOPY केवल build context के भीतर की चीज़ें ला सकता है, और वह फ़ाइल वहाँ नहीं है। context, docker build का अंतिम तर्क होता है, इसलिए आमतौर पर आपने ../x से किसी ऊपरी फ़ोल्डर की ओर इशारा किया, या .dockerignore ने उस फ़ाइल को छान दिया — यह तब क्लासिक है जब node_modules या *.env अनदेखा किया गया हो और फिर उसी के भीतर की फ़ाइल COPY की जाए। संदेश दोनों कारण गिनाता है, इसलिए पहले cat .dockerignore पढ़ें और रास्ता context की जड़ से लिखें। context चौड़ा करके हल करने का मतलब है पूरा फ़ोल्डर daemon को भेजना, जिससे हर build धीमा होता है।exec /usr/local/bin/entrypoint.sh: exec format errorkernel उस निष्पादनीय फ़ाइल का header पहचान नहीं सका, और आजकल यह लगभग हमेशा architecture का बेमेल होता है — Apple Silicon पर बनी arm64 image को amd64 host पर चलाना, या उलटा। जिस shell script की पहली पंक्ति #!/bin/sh छूट गई हो, वह भी यही शब्द देती है। docker build --platform=linux/amd64 से बनाना आम उत्तर है, पर वह बेमेल मिटाता नहीं, emulation से ढक देता है — QEMU से गुज़रने वाला सब कुछ मूल architecture से कई गुना धीमा होता है। जिस image को आप रखेंगे, उसके लिए buildx से दोनों architecture बनाना वह रास्ता है जो चलने के समय कोई क़ीमत नहीं लेता।standard_init_linux.go: exec user process caused: no such file or directorycontainer ने अपना entrypoint चलाने की कोशिश की और kernel ने कहा "no such file" — और जाल यह है कि फ़ाइल स्पष्ट रूप से वहीं है। script के पंक्ति-अंत CRLF हैं, इसलिए पहली पंक्ति #!/bin/sh\r के रूप में पढ़ी जाती है और kernel अक्षरशः sh\r नाम का interpreter खोजने लगता है; Windows पर clone करना या git का autocrlf चालू छोड़ना ठीक यही पैदा करता है। dos2unix entrypoint.sh उस एक फ़ाइल को बदल देता है (न हो तो sed -i 's/\r$//' entrypoint.sh), और .gitattributes में *.sh text eol=lf की पंक्ति इसे लौटने से रोकती है। #! में ऐसा interpreter लिखना जो image में नहीं है — alpine image में bash — वही शब्द देता है।OCI runtime create failed: exec: "bash": executable file not found in $PATH: unknowncontainer बन गया, पर उसके भीतर चलाने को कहा गया कार्यक्रम $PATH में नहीं मिला। alpine आधारित images में sh होता है, bash नहीं, इसलिए docker run -it myapp bash या CMD ["bash", ...] ठीक इसी त्रुटि पर ख़त्म होता है — और वही हाल उस औज़ार का है जिसे आपने image के भीतर मान लिया था पर वह केवल आपके host पर है। docker run --rm -it myapp sh से एक shell मिल जाता है, जिससे दिख जाता है कि image में असल में क्या है। अगर bash सचमुच चाहिए तो Dockerfile में RUN apk add --no-cache bash उसे जोड़ देता है, बड़ी image की क़ीमत पर।

एरर संदेश कैसे पढ़ें

  • पहली पंक्ति से पढ़ें। जितना नीचे जाएँगे उतना वह औज़ार के भीतर की बात है; कारण आम तौर पर सबसे ऊपर लिखा होता है।
  • फ़ाइल का नाम और पंक्ति संख्या दिखे तो वहीं से शुरू करें — stack का सबसे ऊपरी frame नहीं, बल्कि वह सबसे ऊपरी पंक्ति जिसमें आपकी लिखी फ़ाइल का नाम हो।
  • संदेश को जैसा है वैसा खोजें, पर पहले अपने paths और variable नाम हटा दें — वही खोज को अटकाते हैं।
  • वही स्थिति औज़ार के हर संस्करण में अलग शब्दों में आती है। नतीजे बेमेल लगें तो संस्करण संख्या भी जोड़ें।
  • कोई सुधार चिपकाने से पहले देख लें कि वह क्या फेंक देगा। इनमें कुछ पलटे नहीं जा सकते।

अक्सर पूछे जाने वाले सवाल

Q. एरर संदेशों का अनुवाद क्यों नहीं होता?

क्योंकि आप उन्हें खोजेंगे। औज़ार अंग्रेज़ी में छापता है, और अनुवाद किए संदेश से कुछ नहीं मिलता। भाषा सिर्फ़ अर्थ और उपाय की बदलती है।

Q. मेरी स्क्रीन पर शब्द ज़रा अलग हैं।

औज़ार हर संस्करण में शब्द बदल देते हैं। अपने paths और नाम हटाने के बाद ढाँचा वही हो तो वही एरर है। संस्करण अलग हो तो खोज में उसका नंबर भी जोड़ें।

Q. सुधार को वैसे ही चला सकते हैं?

पहले देखें कि वह क्या फेंकता है। git reset --hard, force push और docker system prune ऐसी चीज़ें हटाते हैं जो वापस नहीं आतीं — जहाँ ऐसा है वहाँ लिखा है।

Q. जो एरर यहाँ नहीं है उसे कैसे खोजें?

संदेश से अपने paths, नाम और अंक हटाकर बाक़ी खोजें। वह बाक़ी हिस्सा औज़ार के लेखकों का लिखा वाक्य है, और वही मेल खाता है।