Cli: [BUG] يثبت npm ci تبعية اختيارية تستهدف نظام تشغيل مختلفًا عن نظام التشغيل المضيف

تم إنشاؤها على ٥ ديسمبر ٢٠١٩  ·  32تعليقات  ·  مصدر: npm/cli

ماذا / لماذا

يبدو أن npm ci يقوم بتثبيت تبعية اختيارية لنظام التشغيل Linux عند التشغيل على نظام Mac ويبدو أنه يقوم بتثبيت التبعية الاختيارية لنظام التشغيل mac عند التشغيل على نظام التشغيل Linux.

متى

$ npm init -y; npm i [email protected]; npm ls; npm ci; npm ls
انقر لعرض إخراج الأمر أعلاه
 كتب إلى /private/tmp/d/package.json:

 {
 "اسم الشيئ"،
 "الإصدار": "1.0.0"،
 "وصف": ""،
 "main": "index.js"،
 "نصوص": {
 "test": "echo \" خطأ: لم يتم تحديد اختبار \ "&& exit 1"
 } ،
 "الكلمات الدالة": []،
 "مؤلف": ""،
 "ترخيص": "ISC"
 }



 > [email protected] postinstall / private / tmp / d / node_modules / oax
 > العقدة ./postinstall.js

 قام إشعار npm بإنشاء ملف قفل باسم package-lock.json. يجب عليك الالتزام بهذا الملف.
 npm تحذير [email protected] لا يوجد وصف
 npm WARN [email protected] لا يوجد حقل مستودع.
 npm تحذير تخطي الاعتماد الاختياري الاختياري: [email protected] (node_modules / oax / node_modules / oax-windows-64):
 npm WARN notsup تخطي الاعتماد الاختياري: نظام أساسي غير مدعوم لـ [email protected]: مطلوب {"os": "win32"، "arch": "x64"} (Current: {"os": "darwin"، "قوس": "x64"})
 npm تحذير تخطي الاعتماد الاختياري الاختياري: [email protected] (node_modules / oax / node_modules / oax-linux-64):
 npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: نظام أساسي غير مدعوم لـ [email protected]: مطلوب {"os": "linux"، "arch": "x64"} (current: {"os": "darwin"، "قوس": "x64"})

 + [email protected]
 تمت إضافة حزمتين وتدقيق 4 حزم في 1.1 ثانية
 وجدت 0 نقاط ضعف

 [email protected] / خاص / tmp / د
 └─┬ [email protected]
 ├── [email protected]
 ├── UNMET OPTIONAL DEPENDENCY [email protected]
 └── UNMET OPTIONAL DEPENDENCY [email protected]

 npm تحذير إعداد إزالة node_modules الموجودة / قبل التثبيت

 > [email protected] postinstall / private / tmp / d / node_modules / oax
 > العقدة ./postinstall.js

 تمت إضافة 3 عبوات في 0.722 ثانية
 [email protected] / خاص / tmp / د
 └─┬ [email protected]
 ├── [email protected]
 ├── [email protected]
 └── UNMET OPTIONAL DEPENDENCY [email protected]

أين

  • غير متوفر

كيف

السلوك الحالي

في الوقت الحالي ، يبدو أن npm ci معطل بسبب التبعيات الاختيارية التي تستخدم حقلي os و arch في package.json

خطوات التكاثر

$ npm init -y; npm i [email protected]; npm ls; npm ci; npm ls

يجب أن ترى أن npm i يعمل بشكل صحيح ويقوم بتثبيت تبعية اختيارية واحدة لـ oax.
يجب أن ترى أيضًا أن npm ci يعمل بشكل غير صحيح ويقوم بتثبيت اثنين من التبعيات الاختيارية لـ oax ، ولا يجب أن يحدث هذا أبدًا لأن كل تبعية اختيارية تستهدف نظام تشغيل مختلفًا وبنية مختلفة ، ويجب أن يكون من المستحيل أن يكون لديك أكثر من واحد من تثبيت التبعيات الاختيارية.

سلوك متوقع

يجب تثبيت oax-darwin عند التشغيل على darwin ويجب تثبيت oax-linux عند التشغيل على Linux

منظمة الصحة العالمية

  • غير متوفر

المراجع

  • غير متوفر
Bug
مصدر
picture JakeChampion
👍37

التعليق الأكثر فائدة

أنا مندهش من أن هذا لا يتم التعامل معه على أنه أكثر أهمية من الخطأ. هذا يجعله لا يمكننا استخدام "npm ci" على خوادم البناء الخاصة بنا في windows. هذه صفقة كبيرة.

picture tommck في ١١ فبراير ٢٠٢٠
👍33

ال 32 كومينتر

واجهت نفس المشكلة مع fsevents على Windows ، عند تثبيت حزمتين تعتمدان على إصدارات مختلفة من fsevents.

npm install chokidar --save

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 14 packages from 17 contributors and audited 19 packages in 1.668s
found 0 vulnerabilities

npm install webpack --save-dev

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\watchpack\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 327 packages from 195 contributors and audited 4246 packages in 16.581s

تعتمد أحدث حزمة ويب على watchpack التي تعتمد على [email protected] أقدم والذي يعتمد على [email protected] القديم

بينما يعتمد أحدث chokidar على

لكن تثبيت npm تخطى بشكل صحيح كلا الإصدارين من fsevents لأنهما غير متوافقين مع نظام التشغيل.

ومع ذلك:

 npm ci
npm WARN prepare removing existing node_modules/ before installation

> [email protected] install K:\SWS\test\node_modules\watchpack\node_modules\fsevents
> node-gyp rebuild


K:\SWS\test\node_modules\watchpack\node_modules\fsevents>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Traceback (most recent call last):
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\gyp_main.py", line 50, in <module>
    sys.exit(gyp.script_main())
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 554, in script_main
    return main(sys.argv[1:])
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 547, in main
    return gyp_main(args)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 532, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 2033, in GenerateOutput
    root_entries = _GatherSolutionFolders(
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1791, in _GatherSolutionFolders
    return _DictsToFolders('', root, flat)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1744, in _DictsToFolders
    for folder, contents in bucket.items():
AttributeError: 'MSVSProject' object has no attribute 'items'
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:210:5)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd K:\SWS\test\node_modules\watchpack\node_modules\fsevents
gyp ERR! node -v v12.14.0
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
added 275 packages in 9.344s

وإذا بحثت في node_modules ، فإن fsevents موجود ولا ينبغي أن يكون كذلك.
أيضًا ، npm ci --no-optional لا يعمل ، هذا مذكور هنا:

أنا أستخدم تثبيت Node 12 LTS ، npm -v => 6.13.4

coyoteecd picture coyoteecd في ٣١ ديسمبر ٢٠١٩
👍5

قد يعتمد ما إذا كان npm ci --no-optional على عوامل إضافية. انظر https://github.com/npm/cli/issues/637#issuecomment -570813804

لذلك بينما يفشل npm ci في بيئتي ، يعمل npm ci --no-optional . بيئتي:

  • نظام التشغيل Windows 10
  • Nodejs 12.13.1
  • نانوثانية في الدقيقة 6.13.4
ManfredLange picture ManfredLange في ٤ يناير ٢٠٢٠

بعد التحديث إلى أحدث عقدة و npm تواجه نفس المشكلة .. جميع المشاريع التي يوجد بها fsevent تفشل في التثبيت بـ npm ci ، لأنها تبني fsevents

  • نظام التشغيل Windows 10 Pro 1909
  • العقدة 12.14.1
  • نانومتر 6.13.6
padinko picture padinko في ١٣ يناير ٢٠٢٠
👀3

بعد التحديث إلى أحدث عقدة و npm تواجه نفس المشكلة .. جميع المشاريع التي يوجد بها fsevent تفشل في التثبيت بـ npm ci ، لأنها تبني fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

padinko هل --no-optional ، أي npm ci --no-optional ؟ أي اختلاف؟

ManfredLange picture ManfredLange في ١٣ يناير ٢٠٢٠

بعد التحديث إلى أحدث عقدة و npm تواجه نفس المشكلة .. جميع المشاريع التي يوجد بها fsevent تفشل في التثبيت بـ npm ci ، لأنها تبني fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

padinko هل --no-optional ، أي npm ci --no-optional ؟ أي اختلاف؟

فشل npm ci مع هذه الحزم:

\node_modules\watchpack\node_modules\fsevents
\node_modules\webpack-dev-server\node_modules\fsevents
\node_modules\jest-haste-map\node_modules\fsevents

npm ci --no-optional يملك 2 منهم فقط:

\node_modules\webpack-dev-server\node_modules\fsevents
\node_modules\jest-haste-map\node_modules\fsevents

لذلك هناك فرق ، ولكن لا يزال تجميع fsevents

padinko picture padinko في ١٣ يناير ٢٠٢٠
👍3

paulmillr pipobscure كانت مشكلتي (# 658) نسخة مكررة من هذه التذكرة. تتبع هذا للبقاء على اطلاع.

guidobouman picture guidobouman في ١٦ يناير ٢٠٢٠

يمكنني تأكيد هذا الخطأ أيضًا على Ubuntu. npm ci تثبيت fsevents والذي يجب تثبيته فقط على نظام MacOS

padinko picture padinko في ٢٣ يناير ٢٠٢٠

mikemimik أو isaacs ، هل لديك أي مدخلات حول هذا الخطأ؟ نعم ، غيّر fsevents شيئًا ما يجعل هذه المشكلة الآن أكبر. لكن المشكلة الأساسية لا تزال ناتجة عن الآلية الوقائية الوطنية ، ويجب حلها هنا.

guidobouman picture guidobouman في ٢٩ يناير ٢٠٢٠

يبدو أن التغيير ذي الصلة هو أن fsevents بدأ في استخدام node-pre-gyp لسحب ثنائي مُجمَّع مسبقًا ، بدلاً من بنائه في مكانه ، مما أدى إلى خروج برنامج نصي postinstall بدون أخطاء على جميع الأنظمة الأساسية. نظرًا لأن npm ci يحاول فقط وضع كل ما هو موجود في ملف القفل دون التحقق مما إذا كان يدعم النظام الأساسي ، ويزيل فقط الأجزاء الاختيارية التي تفشل نصوص التثبيت الخاصة بها ، فإنه ينتج عنه تثبيت هذا القسم.

لن يكون لدى npm v7 هذه المشكلة. (أنا أعمل في الكود الذي سيفعل ذلك الآن.) لم أتحقق من مدى مشاركته في إصلاح هذه المشكلة لـ npm v6 ، ولكن هناك فرصة جيدة أن ينتهي الأمر به "ترقية" إلى الإصدار 7 للإصلاح ". في غضون ذلك ، أوصي باستخدام npm install بدلاً من npm ci إذا كان هذا يؤثر عليك.

isaacs picture isaacs في ٣٠ يناير ٢٠٢٠
👍4 😕3

نعم ، غيّر fsevents أسلوبهم. لكن الأمر في الواقع هو العكس. اعتادوا أن يكون لديهم ثنائيات مترجمة مسبقًا. التثبيت على Windows سيعطي 404 ، ثم تخطي. الآن يحاول البناء ، ثم يكسر البناء. لأن البناء لا ينبغي أن يبدأ. بغض النظر: تم تصميم npm ci لبيئات CI. كيف يمكننا استخدام npm i بدلاً من ذلك؟ نريد إجراء فحوصات صارمة على قفل الحزمة في CI.

أيضًا: هل سيهبط npm@7 في العقدة 14 ، في الوقت المناسب قبل LTS؟ هل أنا محق في افتراض أننا عالقون مع npm i أو قفل إصدار لمدة عام عندما نكون في مسار LTS؟

guidobouman picture guidobouman في ٣٠ يناير ٢٠٢٠
👍2

آسف لتغيير التكتيكات عليك. ومع ذلك فقدنا الوصول إلى S3 المستخدم أصلاً وأصبحت مشكلة أمنية خطيرة بشكل متزايد. لهذا السبب عدنا للبناء حسب الحاجة. خاصة بالنظر إلى أن الإصدار v2.x المستند إلى NAPI لا يحتاج إلى إنشاء العقدة v8.x + على الإطلاق

pipobscure picture pipobscure في ٣٠ يناير ٢٠٢٠

الآن يحاول البناء ، ثم يكسر البناء. لأن البناء لا ينبغي أن يبدأ.

أوه ، هذا غريب. أتوقع أن يتعامل npm ci مع فشل إنشاء من قسم اختياري كحدث نوع تحذير غير فادح ، وقم فقط بإزالة القسم المخالف.

بغض النظر: تم تصميم npm ci لبيئات CI. لماذا يجب أن نستخدم npm أنا بدلاً من ذلك؟ نريد إجراء فحوصات صارمة على قفل الحزمة في CI.

سؤال جيد.

لا تعني عبارة "مصمم لبيئات CI" دائمًا "الأفضل لبيئة CI المعينة ، لهذا التطبيق المعين".

في هذه الحالة ، هناك مشكلتان تواجههما npm ci.

  • لا يتعامل بشكل صحيح مع إخفاقات البناء للهيئات الاختيارية.
  • إنه غير قادر على التصفية المسبقة للوثائق بناءً على قيود نظام التشغيل / وحدة المعالجة المركزية ، لأنه _ فقط_ ينظر إلى package-lock.json ، حيث لا يتم تعقب هذه المعلومات. (أي أنه أسرع لأنه يتخطى بعض قراءات الملفات غير الضرورية عادة ؛ بما في ذلك ، بشكل غير صحيح ، الملف الوحيد الذي يحتوي على المعلومات المطلوبة لتجنب هذا الفشل بشكل صحيح.)

لذلك ، يجب عليك استخدام npm i بدلاً من npm ci لأنها ستنجح ، وتجنب كلا الخطأين.

نريد إجراء فحوصات صارمة على قفل الحزمة في CI.

إذا كنت تتحدث عن حقيقة أن قفل الحزمة يوفر عمليات التحقق من السلامة والدقة الموثوقة ، فإن الأخبار السارة: npm install يفعل ذلك أيضًا.

إذا كنت تتحدث عن التحقق من مزامنة package-lock و package.json مع بعضهما البعض ، فيمكنك إضافة "scripts": { "prepare": "npx lock-verify" } إلى package.json.

هل ستهبط npm @ 7 في العقدة 14 ، في الوقت المناسب قبل LTS؟

هذا هو توقعي ، نعم.

ولكن ، حتى لو كان LTS ، كان النهج المتبع في الماضي هو الحصول على إصدار LTS من npm في إصدار LTS من العقدة ، حتى لو كان ذلك يعني أنه يتغير ضمن الإطار الزمني LTS "المجمد" ، لذلك شحن npm v6 لمدة 4 سنوات ستكون فكرة سيئة للغاية لا أعتقد أن Node ستفعلها. وبما أن npm هو في الحقيقة شيء من مشروع منفصل ، وليس "تبعية" بطريقة تؤثر على وقت التشغيل ، فهذا عادة ما يكون جيدًا.

نظرًا لأن npm v7 سيشتمل على بعض التغييرات العاجلة (على الرغم من أننا نحاول تقليل هذه التغييرات قدر الإمكان) ، فقد تكون مشكلة إذا لم نحصل عليها في الوقت المناسب ، أو قد نقدم بعض التنازلات لتعيين التكوينات الافتراضية أو قم بأشياء أخرى بحيث يكون npm v7 الذي يأتي مع العقدة 14 LTS أقرب ما يمكن من npm v6.

isaacs picture isaacs في ٣٠ يناير ٢٠٢٠
👍2

أوه ، لقد راجعت للتو جدول lts العقدة ولاحظت أنني كنت مخطئًا بشأن الإطار الزمني hte. الإصدار _initial_ من Node 14 في غضون 3 أشهر ، لكنه لن يستمر في LTS حتى أكتوبر.

لذا ، نعم ، يجب أن نكون واضحين. أتوقع أن الإصدار الأولي من npm v7 سيكون متاحًا في الوقت المناسب للعقدة 14 ، وسيكون أكثر استقرارًا بما يكفي بحلول الوقت الذي يصل فيه الإصدار 14 إلى LTS. (الكلمات الأخيرة المشهورة وكلها ، لكن الثقة تزداد باطراد مع اقترابنا من القيام بالتكامل ، وليس لدي أي سبب للاعتقاد بأن هذا سيتغير قريبًا).

isaacs picture isaacs في ٣٠ يناير ٢٠٢٠
👍2

أنا مندهش من أن هذا لا يتم التعامل معه على أنه أكثر أهمية من الخطأ. هذا يجعله لا يمكننا استخدام "npm ci" على خوادم البناء الخاصة بنا في windows. هذه صفقة كبيرة.

tommck picture tommck في ١١ فبراير ٢٠٢٠
👍33

ليس فقط windows ، لا يمكنني استخدام npm ci على أي نظام

JakeChampion picture JakeChampion في ١٢ فبراير ٢٠٢٠

إذا كنت تتحدث عن حقيقة أن قفل الحزمة يوفر عمليات التحقق من النزاهة والدقة الموثوقة ، فإن الأخبار السارة: npm install يفعل ذلك أيضًا.

انتظر .. لقد كانت تجربتي أن npm install سيؤدي على الأرجح إلى تحديث ملف package-lock.json إذا كانت الحزم الجديدة متاحة والتي لا تزال تلتزم بالقواعد المحددة في ملف package.json.

هل تغيرت هذه الوظيفة isaacs ؟

tommck picture tommck في ١٤ فبراير ٢٠٢٠

tommck أعتقد أنه يتناول ذلك بهذا الجزء:

إذا كنت تتحدث عن التحقق من أن package-lock و package.json متزامنان مع بعضهما البعض ، فيمكنك إضافة "scripts": { "prepare": "npx lock-verify" } إلى package.json.

أعتقد أنه يمكنك استخدامه كتطبيق فقير لـ npm ci في بيئة CI الخاصة بك. يمكنك تشغيل npm install ؛ يؤدي هذا إلى تشغيل البرنامج النصي التحضيري الذي يتحقق مما إذا كان قفل الحزمة لا يزال متزامنًا مع package.json.

إذا لم أكن مخطئًا ، فهذه مشكلتان:

  • لا أرى كيف يعالج هذا تحديثات التبعيات غير المباشرة التي تفي بقيود تبعياتك المباشرة. سيتم تحديثها وسيتضمن التصميم الخاص بك رمزًا أحدث.
  • إذا اكتشف قفل التحقق تغييرات ، فإنك تحصل على بناء فاشل من اللون الأزرق. سيتعين عليك إعادة إنشاء حزمة lock.json المحدثة وتنفيذها. أرغب في أن تكون بناياتي متوقعة ، لا أن تفشل عندما يتم تحرير بعض التبعية.

نعم ، إنها مشكلة كبيرة - لحسن الحظ في حالتنا ، فإننا نبني على نظام Linux وما زالوا يعملون من أجل مجموعة الحزم الخاصة بنا ... الأشخاص الآخرون أقل حظًا.

coyoteecd picture coyoteecd في ١٤ فبراير ٢٠٢٠
👍3

coyoteecd إذن ... بافتراض أن ملف القفل كان جيدًا (صحيح / تم التحقق منه) ، فإن تشغيل "تثبيت npm" لا يزال من الممكن تعديل ملف قفل الحزمة بتبعيات جديدة؟

tommck picture tommck في ١٤ فبراير ٢٠٢٠

تشغيل "تثبيت npm" مازال من الممكن تعديل ملف قفل الحزمة بتبعيات جديدة؟

غير صحيح. لن تفعل ذلك.

لن يؤدي تشغيل npm install بدون وسيطات إلى إضافة أي تبعيات تختلف عما هو موجود في ملف القفل.

ما سيفعله npm install ، والذي لن يفعله npm ci ، هو _skip_ تنزيل التبعيات الموجودة في node_modules والتي تطابق بالفعل ما هو موجود في ملف القفل.

isaacs picture isaacs في ١٤ فبراير ٢٠٢٠
👎12

انتظر .. كانت تجربتي هي أن تثبيت npm من المحتمل أن يؤدي إلى تحديث ملف package-lock.json إذا كانت الحزم الجديدة متاحة والتي لا تزال تلتزم بالقواعد المحددة في ملف package.json.

هل تغيرت هذه الوظيفة isaacs ؟

أود أن أرى حالة يحدث فيها ذلك. ما لم تخبرها صراحةً بعدم احترام ملف القفل ، أو تشغيل npm update ، أو أن ملف القفل غير صالح (على سبيل المثال ، لم يتم تلبية تبعيات deps من خلال الشجرة التي تحددها) ، فقد تم قفل ملف lock npm install منذ أن تم طرحه في npm v5.

isaacs picture isaacs في ١٤ فبراير ٢٠٢٠

full-icu عبارة عن حزمة ، والتي تقوم أحيانًا بتغيير ملف القفل .. ولكن أعتقد أنها مشكلتهم ، وليس npm

تجربتي: عندما يكون لديك عقدة v12 ، ومطور آخر لديه حزمة بيانات icu للرجوع إلى إصدار أقدم من v10 للعقدة v10 ..

عندما يكون لديك قفل مع كل شيء ولا يوجد دليل node_modules وتشغيل npm i فإنه سيزيل بيانات icu من ملف القفل ، تحتاج إلى تشغيل npm i ثانية لإضافته مرة أخرى ..

كنا نستخدم npm ci ، بسبب هاتين المسألتين

padinko picture padinko في ١٤ فبراير ٢٠٢٠

بالنسبة لأي شخص آخر ينتهي به الأمر هنا بسبب fsevents ، هذا هو الحل npm ci من مشكلتهم المقابلة:

https://github.com/fsevents/fsevents/issues/301#issuecomment -572607085

jayoungers picture jayoungers في ١٣ مارس ٢٠٢٠
👍2

jayoungers FWIW ، هذا الحل لم ينجح بالنسبة لي. بطريقة ما ، لا يزال يتم إنشاء إصدار مختلف من fsevents npm ci . اضطررت إلى تغيير عمليات الإنشاء الخاصة بي لاستخدام npm i بدلاً من ذلك.

paulirwin picture paulirwin في ١٣ مارس ٢٠٢٠
👍4

هل هناك أي تحديثات على هذا؟ نحن أيضًا نتأثر بهذا الخطأ.

robinchrist picture robinchrist في ٨ أبريل ٢٠٢٠
👍8

لست متأكدًا مما إذا كان هذا مفيدًا ، لكنني واجهت هذه المشكلة عند تشغيل npm install في حزمة حيث تم إنشاء package-lock.json بالفعل في Linux (WSL في حالتي). بعد حذف package-lock.json وإعادة تشغيل npm install في Windows ، كنت بخير.

bduffany picture bduffany في ٢٢ أبريل ٢٠٢٠

يبدو أن Serverless Pro CI تغير من تثبيت npm إلى npm ci وتحدث هذه المشكلة أيضًا وتكسر البنية
أنا أرتكب من آلة النوافذ

build step: npm ci

> [email protected] postinstall /nuxt-serverless/node_modules/core-js
> node -e "try{require('./postinstall')}catch(e){}"


> [email protected] postinstall /nuxt-serverless/node_modules/ejs
> node ./postinstall.js


> [email protected] install /nuxt-serverless/node_modules/watchpack/node_modules/fsevents
> node-gyp rebuild

gyp
 ERR! build error 
gyp
 ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:13:12)
gyp
 ERR! stack     at F (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:68:19)
gyp ERR! stack
     at E (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! 
stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/isexe/index.js:42:5
gyp ERR! stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/isexe/mode.js:8:5
gyp 
ERR! stack     at FSReqWrap.oncomplete (fs.js:154:21)
gyp ERR! 
System Linux 4.14.171-105.231.amzn1.x86_64
gyp ERR! command "/root/.nvm/versions/node/v10.13.0/bin/node" "/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /nuxt-serverless/node_modules/watchpack/node_modules/fsevents
gyp ERR!
 node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
dseeker picture dseeker في ٢٣ أبريل ٢٠٢٠

لا يعمل استخدام npm install --no-optional كحل بديل.

لحظة محددة على أنها اختيارية في package-lock.json :

"moment": {
      "version": "2.29.1",
      "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.1.tgz",
      "integrity": "sha512-kHmoybcPV8Sqy59DwNDY3Jefr64lK/by/da0ViFcuA4DH0vQg5Q6Ze5VimxkfQNSC+Mls/Kx53s7TjP1RhFEDQ==",
      "dev": true,
      "optional": true
 }

عندما أقوم بإزالة اللحظة من node_modules npm i ستعيدها:

rm -rf node_modules/moment
npm install --no-optional

ls node_modules | grep moment 
moment
Elijen picture Elijen في ٨ أكتوبر ٢٠٢٠

Elijen لا أعتقد أن هذه هي نفس المشكلة التي يدور حولها هذا الموضوع ، وهي أهداف نظام التشغيل للحزم. قد ترغب في تقديم مشكلة منفصلة إذا لم تكن موجودة بالفعل.

paulirwin picture paulirwin في ٨ أكتوبر ٢٠٢٠

حسنًا ، وبالمناسبة ، لم يعد لدى fsevents هذه المشكلة منذ 5 مايو:
https://github.com/fsevents/fsevents/issues/301

guidobouman picture guidobouman في ٩ أكتوبر ٢٠٢٠

isaacs هل هذه الأرض في npm@7 ؟

guidobouman picture guidobouman في ٩ أكتوبر ٢٠٢٠

paulirwin ربما أنت على حق. لقد رأيت العديد من المشكلات ومنشورات المنتدى التي تم إنشاؤها حول المشكلة التي ذكرتها وافترضت أن هذه المشكلة مجرد مشكلة تكميلية ناجمة عنها.

Elijen picture Elijen في ٩ أكتوبر ٢٠٢٠
👍1

أود أن أرى حالة يحدث فيها ذلك. ما لم تخبرها صراحةً بعدم احترام ملف القفل ، أو تشغيل npm update ، أو أن ملف القفل غير صالح (على سبيل المثال ، لم يتم تلبية تبعيات deps من خلال الشجرة التي تحددها) ، فقد تم قفل ملف lock npm install منذ أن تم طرحه في npm v5.

لقد رأيت تبعيات تحديث npm install بملف قفل صالح على الإصدار 6.14.8 ، عندما يتم تحديد إصدارات الحزمة بواسطة العلامة. مسجّل كـ # 2167.

والخبر السار هو أنه لا يبدو أنه يحدث في الإصدار 7.0.10: +1:

rcowsill picture rcowsill في ١٣ نوفمبر ٢٠٢٠
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

goldingdamien picture goldingdamien  ·  4تعليقات
DullReferenceException picture DullReferenceException  ·  4تعليقات
FaizenR picture FaizenR  ·  3تعليقات
1000i100 picture 1000i100  ·  3تعليقات
darcyclarke picture darcyclarke  ·  4تعليقات