Yarn: تم إعادة بناء الحزم الأصلية في كل مرة

لا يمكن إعادة إنتاج هذا في نظام التشغيل Mac OSX (10.11.6) ، لذا قد تكون مشكلة خاصة بـ Ubuntu؟

يمكنني إعادة النسخ على Windows 10 ، ولكن مرة واحدة فقط. في المرة الثانية التي قمت فيها بتشغيل "الغزل" ، لم تعيد بناء المكتبات المحلية. غريب.

كنت ألعب بها أكثر وتوصلت إلى بعض التفاصيل الإضافية:

1. إذا قمت بتشغيل yarn add leveldown bcrypt ، فسيتم تجميع leveldown كأول عنصر في القائمة وستكون التجزئة في node_modules/.yarn-integrity مساوية لـ 595306... عند الانتهاء (قص للإيجاز ؛ أفترض أن هذا مجموع اختباري يحدد ما إذا كان يجب القيام بشيء ما). الآن إذا قمت بتشغيل yarn مرة أخرى ، فسيتم إعادة بناء كلتا الحزمتين مع تجميع bcrypt كأولى الحزم في القائمة (الترتيب مختلف). المجموع الاختباري الناتج سيساوي cbe480... . الاستدعاء اللاحق لـ yarn لن يعيد بناء الحزم وسيبقى المجموع الاختباري كما هو. هذا يتناقض مع تقريري الأصلي (ربما ارتكبت خطأ في مكان ما) لكنه يتوافق مع ما كان يراه @ Daniel15 .
2. عندما أقوم بعكس ترتيب الحزم من البداية ( yarn add bcrypt leveldown ) ، سيكون bcrypt الأول في القائمة وسيساوي المجموع الاختباري الناتج cbe480... الفور. الاستدعاء اللاحق لـ yarn لن يعيد بناء الحزم.
3. ستنتهي الحزمة bcrypt دائمًا أولاً (كما هو متوقع نظرًا لأنه ليس هناك الكثير لتجميعه) بغض النظر عن الموضع في القائمة.

لست على دراية بالأمور الداخلية على الإطلاق ، لكن يبدو لي أن الترتيب الذي يتم تجميع الحزم به مهم ولا يتم فرزها عند التثبيت لأول مرة (ويتم فرزها عند استدعاء yarn لاحقًا) مما يؤثر على المجموع الاختباري بطريقة ما.

شكرا لك على التحقيق! هذا يبدو وكأنه قيادة جيدة. تمت كتابة التجزئة هنا: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. قد يكون من المفيد تصحيح هذا الرمز ومعرفة ما هو مختلف في ملف القفل ، حيث أن التجزئة في .yarn-integrity تستند إلى ملف القفل.

قد يكون من المفيد تصحيح هذا الرمز ورؤية ما هو مختلف في ملف القفل ، حيث أن التجزئة في .yarn-Integrity تستند إلى ملف القفل.

كنت أشك في ذلك ولكن ما طردني هو حقيقة أن ملف القفل لا يتغير ، فهو دائمًا كما هو. إنها مجرد التجزئة في .yarn-Integrity التي تتغير.

$ yarn add leveldown bcrypt
$ cat node_modules/.yarn-integrity
59530680cc0a4ee12feb373980b5abf2edf2fe2aefa16d556bfb531af8299e71
$ cp yarn.lock leveldown_bcrypt_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock leveldown_bcrypt_afterwards.lock
$ diff -s leveldown_bcrypt_initial.lock leveldown_bcrypt_afterwards.lock
Files leveldown_bcrypt_initial.lock and leveldown_bcrypt_afterwards.lock are identical

$ yarn add bcrypt leveldown
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_afterwards.lock
$ diff -s bcrypt_leveldown_initial.lock bcrypt_leveldown_afterwards.lock
Files bcrypt_leveldown_initial.lock and bcrypt_leveldown_afterwards.lock are identical

$ diff -s leveldown_bcrypt_initial.lock bcrypt_leveldown_initial.lock
Files leveldown_bcrypt_initial.lock and bcrypt_leveldown_initial.lock are identical

لدي نفس المشكلة: أنا أستخدم bcrypt أيضًا. في كل مرة أقوم فيها بتثبيت بعض الوحدات الجديدة أو ترقية وحدات موجودة ، يتعين علي تشغيل npm rebuild لجعل تطبيقي قابلاً للتشغيل.

macOS 10.12 && node v7.0.0 && yarn v0.16.1

لم يعد بإمكاني إعادة إنتاج الإصدار الأصلي. يبدو أنه قد تم إصلاحه: +1 :. @ Daniel15 هل يمكنك التأكيد؟

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

jiripospisil شكرًا ، لا بأس الآن بعد الترقية إلى الغزل v0.17.4.

ما زلت أرى هذا ، أو شيء مشابه جدًا ، على 0.18.1. بالمناسبة ، إنه أيضًا المستوى المنخفض الذي يستمر في إعادة بنائه بشكل متكرر. باستخدام leftpad كحزمة بدون أي تبعيات (وهذا لا يعتمد على المستوى) للأغراض التوضيحية ، تكون خطوات repro كما يلي:

mkdir test && cd test
echo '{ "name": "test", "version": "1.0.0" }' > package.json
yarn add leveldown 
yarn add leftpad
yarn remove leftpad

مخرجاتي عند تشغيل هذا يتبع. لاحظ أن إزالة اللوحة اليسرى تستغرق ما يقرب من 40 ثانية ، ومعظمها إعادة بناء لأسفل. يحدث هذا باستمرار ، مع وبدون المستوى أو اللوحة اليسرى في ذاكرة التخزين المؤقت للغزل ، على الرغم من أنه فقط خلال remove وليس add .

$ mkdir test && cd test
$ echo '{ "name": "test", "version": "1.0.0" }' > package.json
$ yarn add leveldown 
yarn add v0.18.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 145 new dependencies.
<... package list omitted for brevity ...>
✨  Done in 49.93s.
$ yarn add leftpad
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
✨  Done in 2.18s.
$ yarn remove leftpad
yarn remove v0.18.1
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
success Uninstalled packages.
✨  Done in 38.76s.
$ yarn why leftpad
<... just to confirm that leftpad and leveldown are entirely unrelated ...>
yarn why v0.18.1
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.30s.

إصدارات:

عقدة v7.3.0
غزل 0.18.1
OS X El Capitan (10.11.6)

يرجى إعادة الفتح لأن هذا لا يزال يحدث.
فعل للتو yarn add redux وأعاد إنشاء bcrypt و node-sass والعديد من الآخرين.

العقدة v6.9.4
غزل v0.20.3
نظام التشغيل Windows 10

seansfkelley لقد اتبعت خطواتك مع أحدث إصدار وقد

/tmp/tp-20170222100611/test ∴ echo '{ "name": "test", "version": "1.0.0" }' > package.json
/tmp/tp-20170222100611/test ∴ yarn add leveldown
yarn add v0.20.3
info No lockfile found.
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 54 new dependencies.
<cut>
warning [email protected]: No license field
✨  Done in 1.64s.
/tmp/tp-20170222100611/test ∴ yarn add leftpad
yarn add v0.20.3
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
warning [email protected]: No license field
✨  Done in 0.69s.
/tmp/tp-20170222100611/test ∴ yarn remove leftpad
yarn remove v0.20.3
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
warning [email protected]: No license field
success Uninstalled packages.
✨  Done in 0.66s.
/tmp/tp-20170222100611/test ∴ yarn why leftpad
yarn why v0.20.3
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.20s.

Nexxado هل يمكنك إضافة بعض خطوات الاستنساخ من فضلك؟ لقد جربت مجموعات قليلة لكنها نجحت.

العقدة 7.3.0
غزل 0.20.3
نظام التشغيل MacOS 10.12.3

jiripospisil ليس لدي أي خطوات لإعادة الإنتاج ،

إليك ناتج إضافة حزمة واحدة (ملف القفل موجود بالفعل):

ربط التبعيات:

إعادة البناء:

jiripospisil ما زلت أرى هذا أيضًا ، ولكن خلال فترة yarn add [email protected] بدلاً من yarn add leveldown ، يجب أن ترى نفس السلوك كما كان من قبل.

لدي تبعية غير مباشرة على ttf2woff2 ، والذي يعيد البناء أيضًا في كل مرة.

ومع ذلك ، فإنه يعيد البناء فقط في كل مرة عندما يكون هناك تغيير إلى yarn.lock . أي ، yarn مع yarn.lock ، yarn upgrade ، yarn upgrade-interactive . في حالة yarn upgrade-interactive ، إذا تم تحديث كل من devdeps و deps العادية ، فسيتم إعادة إنشاء ttf2woff2 مرتين (!).

أرى أيضًا هذه المشكلة ، على الرغم من أنني لم أتمكن من إعادة إنتاجها باستخدام الخطوات المذكورة أعلاه. ومع ذلك يمكنني إعادة إنتاجه باتباع الخطوات التالية:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

إضافة الغزل المشترك
""

ثم مرة أخرى فإنه يبني المستوى.

لا يبدو أنه يهم الحزمة التي أضيفها ، فهي دائمًا تعيد بناء المستوى.

أنا أستخدم Yarn v0.21.3 و Windows 10 و Node v7.7.1

أنا أرى هذا أيضًا. أنا أستخدم BuckleScript (BS-platform) ....

أواجه هذه المشكلة أيضًا مع sharp . في كل مرة أقوم بتشغيل yarn add أو yarn remove ، سيتم إعادة بناء sharp ، حتى مع الحزم غير الأصلية.

تم اختباره في الغزل v0.21.3 و Node 7.0.0 تحت Windows 10 و Ubuntu Linux 16.04.

إليك تبعيات package.json ، إذا كانت تساعد:

{
  "devDependencies": {
    "auto-reload-brunch": "^2.7.1",
    "babel-brunch": "^6.1.1",
    "babel-preset-env": "^1.2.1",
    "brunch": "^2.10.8",
    "chai": "^3.5.0",
    "clean-css-brunch": "^2.10.0",
    "css-brunch": "^2.10.0",
    "express-mysql-session": "^1.2.0",
    "javascript-brunch": "^2.10.0",
    "jquery": "^3.1.1",
    "less-brunch": "^2.10.0",
    "mocha": "^3.2.0",
    "nodemon": "^1.11.0",
    "npm-run-all": "^4.0.2",
    "postcss-brunch": "^2.0.5",
    "postcss-cssnext": "^2.9.0",
    "postcss-font-magician": "^1.6.1",
    "uglify-js-brunch": "^2.10.0"
  },
  "dependencies": {
    "body-parser": "^1.17.1",
    "connect-redis": "^3.2.0",
    "cookie-parser": "^1.4.3",
    "debug": "^2.6.1",
    "express": "^4.15.2",
    "express-session": "^1.15.1",
    "jstransformer-marked": "^1.0.2",
    "md5": "^2.2.1",
    "morgan": "^1.8.1",
    "multer": "^1.3.0",
    "node-mysql": "^0.4.2",
    "passport": "^0.3.2",
    "passport-local": "^1.0.0",
    "pug": "^2.0.0-beta11",
    "serve-favicon": "^2.4.1",
    "sharp": "^0.17.2"
  }
}

مشاهدة هذا أيضًا بـ bs-platform

تواجه هذا أيضًا مع ttf2woff2 كل مكالمة إلى yarn add تعيد إنشاء ttf2woff2 على الرغم من عدم نشرها منذ أكثر من عام.

لدي هذا مع الأريكة كذلك

تحرير: يبدو أنه تم إصلاحه في 0.23.2

لا يزال يحدث لي في 0.23.2 ( argon2 و node-sass يتم إعادة بنائها في كل مرة أقوم فيها بإضافة / إزالة بعض الحزم غير ذات الصلة مثل moment التي لا تحتوي على تبعيات)

نظام التشغيل: Windows 10
العقدة: 7.9.0
الغزل: 0.23.2

لإضافة المزيد من الألوان ، كان تصوري لهذا يحدث على yarn add <some-package> أكبر بكثير من الواقع حيث تم تشغيل العديد من الحالات بالنسبة لي من خلال الدمج مع yarn remove <unrelated-package> مباشرة قبل ذلك بسبب force: true على هذا الخط .

من المؤكد أنه من الملائم إعادة استخدام منطق التثبيت في الإزالة لإنشاء ملف القفل ، ولكن سيكون من الجيد إذا لم يكن مصحوبًا بكل أمتعة التثبيت القسري :)

بالنسبة لي ، بدأ هذا يحدث مرة أخرى عندما قمت بالترقية إلى 0.23.x. لقد عادت إلى 0.21.3 ولم يعد يبني في كل مرة. أدى هذا أيضًا إلى هذه المشكلة حيث تم حظر IP الخاص بي بواسطة unicode.org بعد ترقية بضع حزم متتالية https://github.com/dodo/node-unicodetable/issues/16

بينما لا يعيد 0.21.3 بناء جميع الحزم عند إضافة حزمة جديدة ، فإنه يعيد بناء جميع الحزم عند الإزالة. ويبدو أن الغزل لا يعتبره فشلًا إذا فشلت عملية إعادة البناء.

بالنسبة لي ، لم يساعد الرجوع إلى 0.21.3 . يتم إعادة بناء bs-platform عند كل إضافة / إزالة.

رؤية هذا على macOS مع Yarn 0.23.4. يعيد إنشاء sqlite3 كل مرة أشغل فيها yarn add .

$ yarn add gulp-rename gulp-notify gulp-sass -D                                                                                         1 ↵
yarn add v0.23.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 42 new dependencies.
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
$ install-app-deps
Rebuilding native production dependencies for darwin:x64
Rebuilding native dependency sqlite3
✨  Done in 56.61s.

رؤية هذه المشكلة مع Ubuntu 16.04LTS ، مع أحدث خيوط v0.24.6 ، مع العقدة 8.1.2

أرى gdal ، node-sass يعيد البناء في كل مرة أقوم فيها بإضافة وحدة ، وهذا يتسبب في أن تستغرق إضافة الخيوط وقتًا أطول من اللازم للتشغيل.

أرى هذا أيضًا ، إنه أمر مزعج للغاية على Raspberry Pi Zero W حيث يمكن أن يستغرق إنشاء الحزم (مثل bleno) عدة دقائق.

ما زلت ترى هذا مع Yarn v0.27.5 و uws . في كل مرة يتغير شيء في حزمتي ، يتم إعادة بناء uws.

الشيء الوحيد المثير للاهتمام الذي يمكنني رؤيته حول uws هو أنه لا يحتوي على حقل تبعيات في package.json .

لقد أصبح هذا محبطًا للغاية بالنسبة لي خلال الأيام القليلة الماضية. لقد قمت بتثبيت windows-build-tools عالميًا في مرحلة واحدة (تحتاج فقط إلى إنشاء نفسها مرة واحدة لإعداد بيئة تطوير Windows للحزم الأصلية) والتي استمرت في إعادة بناء نفسها في كل مرة أضفت فيها حزمة. كما يمكنك أن تتخيل ، فقد استغرق الأمر بعض الوقت وأدركت في النهاية أنني لست بحاجة إلى تثبيته بعد الآن وإزالته.

الآن يبدو أن node-sass يستمر في الرغبة في إعادة البناء على توقع آخر عند إضافة الحزم.

يحدث هذا السلوك في كل من yarn add و yarn remove بالنسبة لي. بالتأكيد ليس من الضروري إعادة البناء لهذه الخطوات حيث يتم إنشاء الحزم الأصلية مرة واحدة فقط وفقًا لإصدار Node؟

تحرير: استخدام Node v8.2.1 و Yarn v0.27.5 على نظام التشغيل Windows 10.

لا يمكنني حساب المرات التي أعيد فيها بناء uws لي :) لاحظ أن uws
لا يحتوي على أي تبعيات بل ويفقد الحقل في package.json

في الإثنين ، 31 يوليو 2017 ، الساعة 10:50 مساءً Paul Myburgh [email protected]
كتب:

لقد أصبح هذا محبطًا للغاية بالنسبة لي خلال الأيام القليلة الماضية. كان لدي
windows-build-tools المثبتة عالميًا في مرحلة واحدة (يحتاج فقط فعلاً إلى
بناء نفسه مرة واحدة لإعداد بيئة تطوير Windows لنظام التشغيل الأصلي
الحزم) التي استمرت في إعادة بناء نفسها في كل مرة أضفت فيها حزمة. مثل
يمكنك أن تتخيل أن ذلك استغرق بعض الوقت وأدركت في النهاية أنني لم أفعل
بحاجة إلى تثبيته بعد الآن وإزالته.

الآن يبدو أن node-sass تستمر في الرغبة في إعادة البناء على مسقطة أخرى
عند إضافة الحزم.

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
.

أنا على 0.27.5 وأظل أرى هذا السلوك باستخدام bs-platform .

هذا محبط للغاية ، كما هو الحال هنا مع bs-platform .

شعور لطيف بالاستحقاق هناك ... ماذا عن العلاقات العامة تيم؟

في الثلاثاء ، 22 أغسطس 2017 ، الساعة 10:44 صباحًا ، Tim Shnaider [email protected]
كتب:

يمكن إصلاح هذا FFS من فضلك.
على الأقل قم بتوفير خيار سطر أوامر أو إعداد env لتعطيله.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
.

لا يبدو أنه قد تم ذكره حتى الآن ، ولكن يمكنني أيضًا إعادة إنتاج هذا الخطأ باستخدام yarn global list .

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

1. استخدم بيئة عالمية جديدة:: تحذير: قم بتشغيل هذا فقط إذا كنت تعرف ما تفعله

   rm -rf ~/.config/yarn/
   

2. أضف حزمة بها مشكلات (_i.e._ zeppelin-solidity ):

   → yarn global add node-gyp zeppelin-solidity
   yarn global v0.27.5
   [1/4] Resolving packages...
   warning zeppelin-solidity > truffle-hdwallet-provider > web3-provider-engine > ethereumjs-block > merkle-patricia-tree > level-ws > xtend > [email protected]:
   [2/4] Fetching packages...
   [3/4] Linking dependencies...
   [4/4] Building fresh packages...
   success Installed "[email protected]" with binaries:
         - node-gyp
   warning "[email protected]" has no binaries
   Done in 20.53s.
   

3. قم بتشغيل yarn global list وشاهد بعض الحزم الأصلية التي يتم إعادة تجميعها

4. كرر بقدر ما تريد ، سيقوم yarn global list دائمًا بإعادة تجميع هذه الحزم الأصلية
5. 😭

آمل أن يساعد هذا.

ℹ️ MacOS 10.12.6 مع Yarn 0.27.5 مثبت عبر Homebrew.

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

لقد مر عام تقريبًا منذ أن تم الإبلاغ عنه لأول مرة.

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

تحرير: لقد قمت للتو بعمل yarn remove لحزمة عشوائية وحاولت وفشلت (هذه المرة) في إعادة بناء ثنائياتي. التأثير الجانبي هو أن ثنائياتي مفقودة تمامًا الآن ويبدو أن الطريقة الوحيدة لإصلاحها هي باستخدام npm rebuild . لذلك لا يبدو أن هذه المشكلة تؤدي فقط إلى عمليات إعادة بناء غير ضرورية - ولكن إذا فشلت هذه العملية ، فيبدو أنه يتعين عليك الرجوع إلى npm لإصلاحها مرة أخرى.

أرى نفس السلوك مثل zhangjyr وlostpebble. تشغيل yarn add يعمل بشكل جيد ولكن yarn remove يؤدي إلى إعادة بناء الحزم الأصلية.

ماك سييرا 10.12.6
غزل 0.27.5

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

لن أتمكن من العمل على هذا لبضعة أسابيع.

أنا أرى هذا أيضًا.
العمل في موقع البناء على غاتسبي. أي عملية غزل تؤدي إلى إعادة البناء.
حاول إنشاء موقع باستخدام gatsby والتزم به. أتمنى أن يساعدك هذا

رؤية هذا في مشروع باستخدام gatsby:
الغزل 1.0.2
العقدة 7.10.1
أوبونتو 16.04.2018

هذه القضية أصبحت خطيرة للغاية الآن. لا يتم إعادة بناء ثنائياتي دائمًا فقط. ولكن يحدث غالبًا أن تتم إزالة ثنائياتي تمامًا بعد yarn add أو yarn install (بعد تغيير أرقام إصدار الحزمة في package.json لتحديث / التراجع عن وحدة). وبغض النظر عن المبلغ الذي أديره yarn install أو yarn install --check-files بعد ذلك ، فإن هذه الثنائيات تضيع وتختفي ولن تعود أبدًا. الطريقة الوحيدة لاستردادها هي باستخدام npm rebuild .

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

هل تم إحراز أي تقدم في هذا الصدد؟

أعتقد أن إضافة الحقل artifacts إلى ملف تكامل الغزل بواسطة arcanis ستساعد في حل هذه المشكلة. لا يوجد تقدم بعد ولكن مفتوح للعلاقات العامة :)

لدي مشكلة مماثلة مع النظام الأساسي bs عند تثبيت الحزم في مشروع reasonml الخاص بي

نفس الشيء ... حرفيا كل yarn add سيعيد بناء مشروع gyp.

يحدث هنا أيضًا.
(غزل 1.2.1)

أرى هذا مع node-sass .

يحدث لي مع السرو على سبيل المثال.

عقدة الخامس
الإصدار 8.8.1
الغزل -v
1.2.1

✋ بدلاً من كتابة "أنا أيضًا" بدون معلومات إضافية ، استخدم ميزة +1 في Github في أعلى مشاركة . في كل مرة تكتب فيها تعليقًا "أنا أيضًا" يتم إخطار 35 مشتركًا دون داع.

+1

الرجاء فقط النقر فوق Subscribe إذا كنت تريد تلقي التحديثات. أتمنى أن يتم إعلام الجميع عندما يتم حلها ولكن ليس عندما يواجه شخص جديد هذه المشكلة أيضًا.

BYK ، هل يمكنك قفل الخيط وجعله متاحًا فقط لأصحابه.

أنا حاليًا أقوم بالتحقيق في هذه المشكلة وأحاول تلخيصها في الحد الأدنى من حالة الاختبار القابلة للتكرار. الحزمة "الرائعة" لإثبات هذه المشكلة هي htmlstrip-native - يستغرق تجميعها بضع دقائق حتى لا تفوتها.

أرغب في أن يجرب شخص آخر هذا package.json في مجلد فارغ:

{
  "name": "yarn-test",
  "version": "1.0.0",
  "dependencies": {
    "htmlstrip-native": "^0.1.3",
    "left-pad": "1.1.3"
  }
}

جرب تشغيل هذه الأوامر:

yarn
yarn upgrade [email protected]

على جهازي ، باستخدام أحدث خيوط 1.2.1 ، ينتج عن الأمر upgrade إعادة بناء htmlstrip-native وهو ما يستغرق إلى الأبد. لا ينبغي إعادة بناء هذا الغزل لأن ترقية left-pad ليس لها تأثير على htmlstrip-native أو تبعياتها.

جرب الآن npm :

rm -rf node_modules
npm install
npm install [email protected]

على جهازي ، لا ينتج عن الأمر الثاني (بشكل صحيح) إعادة بناء جديدة htmlstrip-native .

تحرير : من إعادة قراءة جميع المنشورات أعلاه ، يبدو أن هذه الحالة لن تكون مفاجأة لأي شخص - معظم الناس ، بمن فيهم أنا ، يجدون أن مجرد طلب الغزل للقيام بأي شيء يؤدي إلى إعادة بناء. أعتقد أن هذه ليست مشكلة أكبر في المجتمع لأن معظم الناس لا يستخدمون الحزم الأصلية التي تستغرق وقتًا طويلاً في بنائها - لذلك إما ليس لديهم خطوة إعادة البناء أو تنتهي بسرعة كبيرة من يهتم.

حسنًا ، بعد الكثير من التصحيح ، يبدو أن هذا السلوك مقصود. عند تتبع الشفرة ، يبدو ، على سبيل المثال ، نتائج yarn upgrade [email protected] في الخطوات التالية:

1) يتم استدعاء الوحدة النمطية upgrade ، والتي تقوم بتشغيل عملية new Add() لـ left-pad .
2) Add.init() يصل إلى الطبقة الممتازة ، Install.init()
3) Install.init() قوائم انتظار rebuildingPackages خطوة
4) في PackageInstallScripts.init() يقوم ببساطة بجمع _all_ الحزم وإضافتها إلى workQueue ليتم إعادة بنائها.
5) يكتشف PackageInstallScripts بعد ذلك أن هناك أمر تثبيت مقابل htmlstrip-native ويقوم بتشغيله فقط - هذا هو إعادة البناء الأصلية بطيئة للغاية التي نراها جميعًا.

من كل شيء رأيته حتى الآن ، يبدو أنه لا يوجد منطق ينوي تصفية الحزم التي لا "تحتاج" إلى إعادة بنائها. إنه ببساطة يعيد بناء كل شيء ، كما هو مذكور في إخراج وحدة التحكم.

أود أن يتناغم شخص ما من فريق Yarn هنا - إذا كان هذا السلوك مقصودًا حقًا ، فأنا أوصي بإغلاق هذه المشكلة!

بالنسبة لوضعي شخصيًا ، سأقوم فقط بتبديل تبعيتي htmlstrip-native حيث لا يوجد سبب يجب أن يستغرق بناؤها دقائق (مثل ، ملفان صغيران .c ). يتم بناء بقية مكاتب بلدي الأصلية بسرعة ، لذا فهي ليست مشكلة كبيرة إذا حدث ذلك طوال الوقت.

يبدو أنه تأثير جانبي غير مقصود للتصميم ، ولكن ربما يمكن لشخص ما في @ yarnpkg / core التعليق عليه. لا أعتقد أن الغرض منه هو إعادة بناء الحزم التي لا تحتاج إلى إعادة بنائها.

هذا ليس مقصودًا ، ربما يكون التنفيذ بهذه الطريقة أسهل.
هناك تعليق أعلاه من BYK يقول أن هذه المشكلة تبحث عن علاقات عامة:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

من المؤكد أن الحزم الأصلية الثقيلة ليست شائعة بدرجة كافية لتظهر كأولوية قصوى لـ Yarn ، لكن Yarn لديها القدرة على عدم إعادة بناء الحزم عند كل تثبيت.
يبدو أن هذا خطأ يجب أن يكون مستقيمًا للأمام لإصلاحه ، أرسل العلاقات العامة.
قد تكون هناك محاذير لأن Yarn لا يمكنها أن تعرف على وجه اليقين ما إذا كانت الحزمة المدمجة قد تعرضت للتلف ، وهذا هو السبب في أنها تعيد تشغيل نصوص التثبيت الآن بشغف.

هناك شوكة غزل يستخدمها الفريق وراء السبب https://github.com/esy-ocaml/esy-install الذي يعمل على حل الكثير من مشكلات الترجمة الأصلية لأن تبعيات السبب / Ocaml تتطلب تجميعًا كثيفًا.
مع نضوج هذا النهج ، آمل أن يكون من الممكن دمج التغييرات في المنبع.

لذلك ، يتم إعادة بناء الحزم الأصلية بشكل أساسي لأن إما:

1) تم تعيين العلم force=true ، أو
2) تم تعليم الحزمة fresh=true .

يبدو أنه مع بعض الأوامر (مثل upgrade و remove ) ، تم تعيين علامة force على true "فقط في حالة". تعد هذه العلامة بـ "إعادة بناء جميع الحزم بغض النظر عما إذا كانت قد تغيرت" لذلك ليس من المنطقي إضافة بعض كود الكشف عن التغيير لأن ذلك من شأنه أن يخالف هذا الوعد.

لإصلاح هذا ، يبدو أننا سنحتاج إلى تحدي افتراضات الأماكن المختلفة في الكود التي تحدد force=true .

يحدث أول ما تتبعته عند تشغيل yarn upgrade whatever . تم تقديمه في هذا الالتزام كجزء من # 2780 بواسطةjuanca. تقول مذكرات ارتكاب:

"Ensure force flag is enabled when using `yarn upgrade` Otherwise exotic packages are not updated."

ربما يستطيعjuanca أو أي شخص أكثر دراية بتاريخ الغزل أن يتناغم مع المشكلة التي كان المقصود حلها؟

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

أفترض أنه تم تعيين العلم force بحيث لا يتخطى محلل الغزل التبعية الحالية لأن الإصدار القديم موجود في yarn.lock.

أعتقد أنه كان حلاً سريعًا لجعل الترقية تعمل.
الطريقة الصحيحة هي تمرير علامة أخرى تؤثر فقط على دقة الحزم المحددة ولن تكون نووية مثل force .
أرسل PR :)

ربما يستطيعjuanca أو أي شخص أكثر دراية بتاريخ الغزل أن يتناغم مع المشكلة التي كان المقصود حلها؟

صحيح ، كنت أعمل مع واجهة برمجة تطبيقات Add - لم تفعل شيئًا عند إضافة حزمة موجودة.

أوصي أيضًا باستخدام تقنية أفضل في التحكم في التدفق الإجرائي.

أنا أستخدم خيوط الغزل على raspberry pi zero في مشروع يعتمد على node-opencv. في كل مرة أقوم فيها بإضافة / إزالة / تحديث حزمة غير ذات صلة ، يجب أن أنتظر 35 دقيقة لإعادة البناء.

@ Torsten85 ، أنا أستخدمه في pi أيضًا ، نعم عمليات إعادة البناء غير الضرورية هي شيء نحتاج إلى معالجته.
هل يمكنك تقديم برنامج نصي لإعادة البناء لعمليات إعادة البناء الخاصة بك؟

نفس الشيء هنا ، في lubuntu 17.10 ، عندما أستخدم الغزل ، أطور باستخدام https://github.com/mui-org/material-ui

كل yarn add/remove (-D) <pkg> إعادة بناء كل شيء ، مثل تثبيت جديد ، يستغرق أكثر من دقيقة واحدة

هل هذه هي الطريقة التي يتعامل بها npm أيضًا؟ إذا لم يكن الأمر كذلك ، فهل سيكون من الممكن أن يتم التبديل مؤقتًا؟

يحدث هنا أيضًا

• العقدة 9.2.0
• غزل 1.4.0

في كل مرة أقوم بإضافة بعض التبعية ، يتم إعادة بناء وحدات مثل bcrypt أو couchbase في كل مرة

مرحبًا بالجميع ، أنا أعمل على اختراق صغير https://github.com/yarnpkg/yarn/pull/5314.
الفكرة هي تخزين حزمة مدمجة في مرآة غير متصلة بالإنترنت لتجنب تشغيل البرامج النصية للتثبيت طوال الوقت.

لذلك إذا كنت تستخدم نسخة متطابقة بلا اتصال وقمت بتشغيل yarn add node-sass :

1. ستقوم الغزل ببناء وتثبيت عقدة ساس كالمعتاد ،
2. بعد تشغيل البرامج النصية للتثبيت ، سيتم إنشاء node-sass-v4.7.2-darwin-x64-57.tgz من المجلد node_modules/node-sass المعدل
3. في المرة القادمة التي تقوم فيها بتشغيل yarn install على نفس النظام الأساسي ، سيتم فك ضغط node-sass-v4.7.2-darwin-x64-57.tgz بدلاً من البرنامج الأصلي ولن يتم تشغيل البرامج النصية للتثبيت

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

أحاول تثبيت الكتابة المطبوعة كحزمة عالمية ، ويقضي الغزل كل الوقت في إعادة بناء الأشياء بدلاً من تثبيت ما أحتاجه حقًا الآن.

انتقلت إلى الغزل معتقدة أنها أسرع وأفضل. أزلت أي أثر لـ npm (باستثناء ما يأتي مع تثبيت العقدة) ؛ وأعدت تثبيت جميع الحزم العالمية للغزل.

يختبر Yarn الآن صبري بجعلي أنتظر لمدة 1-15 دقيقة لتثبيت الحزمة البسيط. يجب أن يكون الغزل أكثر ذكاءً بما يكفي لتثبيت ما هو مطلوب أولاً قبل إعادة بناء العناصر الأخرى ما لم تعتمد الحزمة المطلوبة صراحةً على أي من الحزم الأصلية التي تتطلب إعادة البناء.

بيئة:

• العقدة: 9.4.0
• الغزل (عالمي): 1.3.2
• نظام macOS Sierra: 10.12.6
• ماك بوك برو 15 انش
  
  
  
  • الذاكرة: 16 جيجا بايت
  
  
  • وحدة المعالجة المركزية: 2 جيجاهرتز - Intel Core i7
  
  
  • التخزين: ماجنتيك (الكثير من المساحة الحرة)
  
  
  • التطبيقات التي تعمل وقت التثبيت: Firefox (6 علامات تبويب) و Mail.app و iTerm (مع علامتي تبويب)
  
  

السجلات

يستغرق جلب الحزم الكثير من الوقت

نسخة مطوية للترقية العالمية الغزل
الغزل العالمي v1.3.2
[1/4] حل الحزم ...
[2/4] جلب الحزم ...
[################################################## ############# -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

ربط التبعيات عالق دون أي تقدم لدقائق

نسخة مطوية للترقية العالمية الغزل
الغزل العالمي v1.3.2
[1/4] حل الحزم ...
[2/4] جلب الحزم ...
[3/4] 🔗 ربط التبعيات ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

إعادة بناء جميع الحزم - تستغرق الكثير من الوقت

نسخة مطوية للترقية العالمية الغزل
الغزل العالمي v1.3.2
[1/4] حل الحزم ...
[2/4] جلب الحزم ...
[3/4] 🔗 ربط التبعيات ...
[4/4] إعادة بناء جميع الحزم ...
[12/17] ⠐ websocket
[2/17] Expresso: التحقق من خيار مجلس التعاون الخليجي لقبول ISO C99 ...
[8/17] منفذ تسلسلي: استخدام [email protected] | داروين | إلى x64
[6/17] ⠐ الآن:> للحصول على شفرة المصدر ، تحقق من: https://github.com/zeit/now-cli

نسخة مطوية للترقية العالمية الغزل
الغزل العالمي v1.3.2
[1/4] حل الحزم ...
[2/4] جلب الحزم ...
[3/4] 🔗 ربط التبعيات ...
[13/17] ⠈ بدون خادم
[13/17] ⠂ بدون خادم
[14/17] ⠠ Solgraph
[14/17] ⠁ Solgraph
[14/17] ⡀ Solgraph
[- / 17] ⠈ الانتظار ...
[- / 17] ⠄ الانتظار ...
[- / 17] ⠠ الانتظار ...
[- / 17] ⠈ الانتظار ...
[- / 17] ⠄ الانتظار ...
[- / 17] ⢀ الانتظار ...
[- / 17] ⠈ الانتظار ...

ما زلت انتظر :-)

الآثار الجانبية آخر هو أن المكتبات التي التحميل ومخبأ precompiles أيضا الحصول على القضاء وقد ليتم تحميلها مرة أخرى: وهي nwjs-builder-phoenix الصورة مخبأ للتطوير البرامج بناء الهدف

1. يتم دائمًا إعادة بناء الحزمة الأصلية عند تحديث إصدار حزمة وهو حزمة غير أصلية.

هل يخزن الغزل الملف الثنائي للعالم مثل npm؟

لقد بدأ يحبطني قليلاً عندما أضطر إلى إعادة بناء nwjs في كل تثبيت بسيط. لا معنى له

أنا أرى هذا أيضًا. يتم إعادة بناء uws في كل مرة أقوم فيها بعملية إضافة / إزالة. v1.3.2 الغزل

مرحبًا @ bestander. لقد جربنا # 5314 على monorepo لشركتنا ، ولكن لم يكن له أي تأثير على إيقاف إعادة بناء بعض التبعيات بالنسبة لنا. لقد قمنا بتمكين yarn-offline-mirror و pack-built-packages في .yarnrc كما هو موضح في الاختبارات المضافة.

الجوهر هو أن تشغيل yarn يستغرق دائمًا حوالي 40-50 ثانية بالنسبة لنا ، حتى لو كان الأمر الذي قمنا بتشغيله مباشرة من قبل هو yarn أيضًا.

@ bazyli-brzoska ، لقد غيرت العلم ليكون أكثر وضوحًا ونسيت تحديث الوصف.
هل يمكنك تجربة تعيين العلم experimental-pack-script-packages-in-mirror أنه "صحيح"؟

هل هناك أي تقدم في هذا؟ أرى أن طلب السحب مدمج بالفعل وأنه موجود في الإصدار الأخير 1.5.1. أنا على 1.5.1 ولم يتغير شيء بالنسبة لي. ومع ذلك ، أفكر في العودة إلى npm ، لأن انتظار 322.70s أو 282.69s أو حتى 683.41s (هذه هي آخر ثلاثة yarn add لديّ

سيكون من الرائع أن تكون مثل هذه التحذيرات الرئيسية على ملف README.md الخاص بك. يقوم المستخدمون بتثبيت الغزل لأنه يُزعم أنه "أسرع" ، ولا يعد إجراء هذا الانتقال من npm إلى الغزل خطوة صغيرة ، لذلك سيكون من الجيد إذا كان هناك أي تحذير مسبق للمطورين ، حتى يتمكنوا من التفكير فيه مرة أخرى قبل التحويل نصوصهم ، تلوث الكرة الأرضية وتعلم الغزل cli.

اعتقدت أن هذه مجرد مشكلة في جهاز 32 بت القديم الخاص بي ، لكن بعد رؤيته يحدث 237 مرة ، بحثت في Google ، ويا ​​، لم يكن الغزل أسرع. عظيم.

آسف لكونك لئيمًا على الأرجح ، لكن أعتقد أنك تشعر بالإحباط.

نحن نقبل المساهمات.

ومع ذلك ، هناك شيء يجب مراعاته بخصوص الحزم التي يتم إعادة بنائها عندما لا "تحتاج" إلى: تنفيذ خطوات الإنشاء بعد تثبيت التبعيات. بمعنى أنه يُسمح لنصوص البناء باستخدام تلك التبعيات. بمعنى أنه إذا تغيرت هذه التبعيات لأي سبب من الأسباب (والذي قد يحدث "عشوائيًا" ، على سبيل المثال إذا قمنا بتحسين نسختين متوافقتين من الحزمة في إصدار واحد) ، فإننا نحتاج في الواقع إلى إعادة تشغيل خطوات الإنشاء حتى لو لم تكن تلك التبعيات في الواقع تستخدم أثناء البناء (لأن كيف لنا أن نعرف؟).

لذلك فهي ليست مشكلة سهلة بالضبط. يأتي جزء من المشكلة على الأقل من تصميم package.json نفسه. قل لي عن الإحباط 🙂

arcanis لا أحصل على هذا الجزء:

حتى لو لم يتم استخدام هذه التبعيات فعليًا أثناء الإنشاء (لأنه كيف يمكننا معرفة ذلك؟).

اعتقدت أن تصميم YARN كان للحفاظ على التبعيات الثابتة + الإصدار (قفل الغزل) وبالتالي لن يكون هناك "تحديثات" عشوائية.
على الرغم من أن حزمة json تعطي شجرة كاملة ، فلماذا تقول "كيف يمكننا أن نعرف"؟ بمجرد حل الشجرة ، من السهل حقًا تحديد ما إذا كان أي من التبعيات (حتى تلك ذات المستوى العميق) قد تغير أم لا.

لنفترض أن لدي تبعية foo تعتمد على babel-core و left-pad@^1.0.0 ، وأن هذه التبعية foo لها نص بناء يقوم بتشغيل برنامج babel في ملف الفهرس الخاص به .

بعد تشغيل yarn add foo في مجلد مشروعي ، انتهى بي الأمر بالحصول على [email protected] في node_modules ، أليس كذلك؟ لنفترض الآن أنه تم إصدار إصدار جديد من اللوحة اليسرى ( 1.1.0 ) ، وأريد استخدامه في مشروعي. سأعمل على تشغيل yarn add left-pad ، والذي سينتهي بعد ذلك إلى latest ، أي 1.1.0 .

ما يمكن أن يحدث الآن هو أن الغزل "سيرى" أن هناك نسختين من اللوحة اليسرى في الشجرة ، وسيرى أيضًا أنه يمكن تحسينهما: بعد كل شيء ، يعتمد foo على left-pad@^1.0.0 ، لذا فإن 1.1.0 متوافق أيضًا. لذلك سيزيل الإصدار السابق ، ويستخدم فقط 1.1.0 . نظرًا لتغير التبعية ، نحتاج إلى تشغيل النص البرمجي للبناء مرة أخرى لأن Yarn ليس لديه طريقة لمعرفة أن left-pad هو تبعية وقت التشغيل وليس تبعية لوقت البناء .

الآن قد تسأل "ولكن لماذا لا نتخطى مجرد إعادة البناء عندما تغيرت التبعيات متعدية؟". الإجابة هي أن بعض الحزم (خاصة الحزم الأصلية) لها تبعيات تؤثر بشكل جذري على كيفية بنائها. عندما يحدث ذلك ، نريد حقًا إعادة بناء تلك الحزم ، أو سينتهي بنا الأمر بقطع أثرية غير متوافقة.

arcanis ، أعتقد أنك تسيء فهم المشكلة. تكمن المشكلة هنا في إعادة بناء هذه الحزم الأصلية _في كل مرة_ ، حتى عندما يتم تشغيل yarn مرتين (أو أكثر) في تتابع سريع. ليس لها علاقة بتحديث التبعيات - إنها تعيد البناء دائمًا.

Spongman أتفق مع تعليقك الأخير. ولكن كما ذكر Spongman بشكل صحيح ، تحدث إعادة البناء في كل مرة . حتى لو قمت بعمل yarn && yarn - ستحصل على عمليتي إعادة بناء كاملتين ، على الرغم من حقيقة أنه لم يتغير شيء في هيكل التبعية.

حاولت تشغيل yarn add leveldown bcrypt && yarn && yarn كما في OP وحصلت فقط على بنية واحدة: / هل لديك أمر يمكنني استخدامه لإعادة هذا السلوك؟

يمكنك أن تجرب على سبيل المثال:

mkdir foobar
cd foobar
yarn init
....
yarn add socket.io
      (5 native packages build)
yarn add react
      (5 native packages build again)
yarn remove react
      (5 native packages build again)

(هذا ضمن Ubuntu 14 LTS)

foobar billli$ yarn -v
1.3.2
foobar billli$ node -v
v8.9.1

yarn & yarn 

لا يتسبب في إعادة بناء اثنين ، ولكن المثال مع socket.io ، إضافة رد فعل ، وإزالة التفاعل يتسبب في عمليتي إعادة بناء

جربت مثال socket.io مع yarn v1.5.1 ولم أحصل على إعادة بناء عند استخدام الميزة الجديدة لتخزين البنيات الأصلية مؤقتًا. للقيام بذلك ، تحتاج إلى استخدام ذاكرة التخزين المؤقت دون اتصال. في ~/.yarnrc لدي:

experimental-pack-script-packages-in-mirror true
pack-built-packages true                                         
yarn-offline-mirror "/home/skomorokh/yarn-offline-cache"

عندما أحاول كمستخدم آخر بدون هذا التكوين ، فإنه يعيد البناء في كل مرة.

نعم ، لا إعادة بناء الآن عند إضافة هذه الخيارات.
ولكن إذا كان فقط experimental-pack-script-packages-in-mirror true ، فلا يزال يعيد البناء.
لماذا لا يتم تعيين yarn-offline-mirror إلى مسار افتراضي مثل "~ / .yarn / cache".

لا يزال تجريبيًا ، لكنه اقتراح مثير للاهتمام (cc @ bestander). أعتقد أن المشكلة التي أواجهها هي أنني شخصياً لا أحب فكرة تمكين الأشياء دون موافقة صريحة من المستخدم. كما أن لها آثارًا أخرى: ما الذي يعنيه تعيين yarn-offline-mirror على false ، و experimental-pack-script-packages-in-mirror إلى true ؟ هل يجب أن يستبدل experimental-pack-script-packages-in-mirror yarn-offline-mirror إعدادات

ومع ذلك ، فإن الخطأ في إعادة إنشاء uws عند إضافة left-pad مزعج نوعًا ما ، وإعدادات experimental-pack-script-packages-in-mirror هي حل بديل فقط. لست متأكدًا من أنه سيكون لدي النطاق الترددي للنظر في هذا في الأسبوع المقبل أو نحو ذلك ، ولكن إذا كان شخص ما مهتمًا بالحصول على إصلاح ، فسيكون ذلك مؤثرًا جدًا.

arcanis شكرا لك على الرد skomorokh في ملف README.md حتى يتم إصلاح ذلك. أو فقط قم بإزالة "سريع" من الوصف الخاص بك.

سأشعر بالإحباط نفسه ، إذا ذكر التمهيدي لـ angularjs repo أنه إطار خفيف الوزن. إنه ليس كذلك.

يكرر دائمًا تنزيل الملف الثنائي بعد yarn-offline-mirror config.

cd \tmp\t
yarn init
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node

سأحاول تصحيح هذا قليلا اليوم. أعتقد أنه في الواقع قد يكون بسيطًا مثل PackageInstallScripts عدم فحص pkg.fresh لإعادة بناء الحزم المثبتة حديثًا فقط. بدلاً من ذلك ، يبدو أنها تدور حولهم جميعًا.

بعد بعض العبث ، بدأت أعتقد أننا نعيد بناء الأشياء طوال الوقت في حالة شخص ما rm -rf node_modules أو تم حذف الوحدة من هناك.

لدينا قائمة بعناصر البناء المكتشفة في ملف .yarn-integrity ، لذلك أعتقد أن إعادة البناء يجب أن تحدث فقط إذا كان fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

لذلك فهي أكثر تعقيدًا قليلاً مما كنت أعتقد.

لدي فقط yarn add ed moment ، حزمة تبعية صفرية ، لتطبيق رد الفعل المحدث ، استغرق الأمر 377.97s .

فعل ذلك مرة أخرى بعد ذلك مباشرة ، استغرق الأمر 389.63s وأعاد بناء الثنائيات مرة أخرى.

للمقارنة فقط ، قمت بعد ذلك بحذف node_modules وأدخلت npm install :
added 1751 packages and updated 124 packages in 360.595s

العودة إلى npm الآن.

حسنًا ، بعض المعلومات الإضافية لجميع الأنظار حول هذه المشكلة ... لقد كنت العبث بهذا الشيء لمدة يوم ونصف الآن وأدركت أخيرًا بعض الأشياء.

أولاً ، تم إصلاح معظم مشكلات إعادة البناء هذه. يوجد بالفعل رمز في PackageInstallScripts يعيد تشغيل البرامج النصية فقط للحزمة ، هل تم وضع علامة "حديث" عليها :

    if (!ref.fresh && !this.force) {
      // this package hasn't been touched
      return false;
    }

على سبيل المثال ، إذا كنت تستخدم node-sass :

yarn add node-sass <-- builds sass because first install
yarn add left-pad <-- does NOT rebuild node-sass

أيضًا لا يتم إعادة بناء yarn install s المتتالية.

yarn add uws <-- builds because first install
rm -rf node_modules
yarn install <-- builds uws because dir was deleted
yarn install <-- does NOT rebuild uws

... لكن بالطبع هناك بعض الاستثناءات ...

في yarn remove علامة force (لإصلاح بعض الأخطاء الأخرى التي أفترضها ، لكنها كانت كذلك لمدة> 2 سنوات) لذلك تحدث عمليات إعادة البناء دائمًا.

ومع ذلك ، يمكن القول إن هذا "صحيح" لأنه ما يفعله npm أيضًا:

~/Projects/yarn-test 🐒   npm uninstall left-pad

> [email protected] install /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/install.js

Cached binary found at /Users/me/.npm/node-sass/4.7.2/darwin-x64-57_binding.node

> [email protected] postinstall /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/build.js

Binary found at /Users/me/Projects/yarn-test/node_modules/node-sass/vendor/darwin-x64-57/binding.node
Testing binary
Binary is fine
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

added 180 packages, removed 1 package and updated 7 packages in 4.03s

يمكنك ملاحظة أنه في uninstall من left-pad ، قامت npm بتشغيل البرامج النصية install و postinstall لـ node-sass .

الحزمة uws (التي تستخدمها عدد غير قليل من الحزم الأخرى ، مثل socket.io ، browser-sync ، إلخ ...

شيء ما أثناء عملية التثبيت يغير أحد الملفات (الحجم والطابع الزمني مختلفان).

~/Projects/yarn-test 🐒   ls -l /Users/me/Library/Caches/Yarn/v1/npm-uws-9.14.0-fac8386befc33a7a3705cbd58dc47b430ca4dd95/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  383636 Nov 21 00:43 uws_darwin_57.node

~/Projects/yarn-test 🐒   ls -l node_modules/uws/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  378672 Mar  4 11:18 uws_darwin_57.node

يرى الغزل ملفًا "تم تغييره" مقارنةً بذاكرة التخزين المؤقت ، لذا فهو يشير إلى الحزمة "حديثة" لإعادة التثبيت

يؤدي هذا بعد ذلك إلى تشغيل المنطق أعلاه الذي يعيد تشغيل نصوص التثبيت لأنها "حديثة". يحاول Yarn أن يكون مفيدًا و "يصلح" الملفات غير الصحيحة ، لكنه بالطبع لا يعرف أن الملف قد تغير بسبب البرنامج النصي للتثبيت. قد نضطر إلى التحقيق في طريقة ما لإصلاح ذلك ، ولكن هناك أيضًا حديث عن تغيير الطريقة التي تتم بها مقارنة هذه الملفات (توقف عن تشغيل الإحصائيات في كل ملف) ، لذلك قد يتم حلها من خلال هذا التعديل.

نأمل أن يشرح ذلك بعض الحالات هنا حيث يقول بعض الأشخاص أنها تعمل والبعض الآخر يقول أنها لا تعمل.

شكرا للتعمق هناك ، @ rally25rs.

1. إعادة: استخدام force في أمر الحذف.
   من الواضح أن هذا كان إصلاحًا سريعًا لخلل الركن الذي حقق التصحيح باستخدام نهج نووي IIRC https://github.com/yarnpkg/yarn/pull/323.
   لا ينبغي أن يكون من الصعب إزالة force والتغلب على المشكلة.

2. node_modules/uws/uws_darwin_57.node : يجب أن يكون هذا الملف في الحقل artifacts .yarn-integrity ثم لا يجب وضع علامة uws على أنها ليست حديثة أثناء الربط.
   ربما هناك خطأ ما هنا

@ bestander آه نقطة جيدة على 2. سأحاول معرفة ما إذا كان هناك طريقة عقلانية للعمل في هذا الاختيار.

stereokai في تعليقي أعلاه ، لاحظت أن npm تعيد أيضًا بناء الحزم عند إلغاء التثبيت / الإزالة ، لذلك يمكن القول إن هذه الحالة "صحيحة" إذا كنت تعتبر سلوك npm هو المعيار.

@ rally25rs شكرًا على الإشارة إلى ذلك :)

ومع ذلك ، أنا أعتبر هذا السلوك عربات التي تجرها الدواب بغض النظر عن مدير الحزم. من الصعب أن نفهم سبب أهمية هذا النوع من السلوك للتشغيل الصحيح. لا يقوم نظام التشغيل الخاص بك بإعادة تثبيت البرامج المحلية عند إضافة / إزالة برنامج آخر ، لأن التطبيقات موجودة بالفعل. لا أتوقع أي شيء آخر من مدير تبعية ثابت ، نحمين؟

stereokai أوافق إلى حد ما ، ولهذا السبب استخدمت عبارة "يمكن القول إنه صحيح" 😆
لا يغير نظام التشغيل الخاص بك أيضًا مكان تثبيت التطبيقات الأخرى عند إلغاء تثبيت تطبيق غير ذي صلة.

افترض أن لديك شجرة تبعية مثل:

myProj
  |- depA v1
  |    |-depB v2
  |- depB v1

إذا قمت بتثبيت هذا ، فإنه سيشكل نفس بنية الدليل تحت node_modules ، لأنه لا يمكنه رفع depB إلى الجذر.

myProj
  |- node_modules
       |- depA v1
       |   |- node_modules
       |        |-depB v2
       |- depB v1

لكن من منك yarn remove depB فإن الهيكل الجديد هو:

myProj
  |- depA v1
       |-depB v2

myProj
  |- node_modules
       |- depA v1
       |- depB v2

لذلك قد يتغير الدليل الفعلي حيث تم تثبيت depB v2 كلما تمت إضافة حزمة أو إزالتها. لا يتم نسخ هذه الدلائل فقط من موقع إلى آخر. يتم حذف القديم ويتم نسخ الجديد من ذاكرة التخزين المؤقت إلى الوجهة الجديدة ، مما يعني أن أدوات الإنشاء التي كانت في node_modules/depA/node_modules/depB لم تعد موجودة ، وستحتاج إلى إعادة بنائها في node_modules/depB .

وبالمثل ، فإن yarn add [email protected] سيغير المسار حيث تم تثبيت depB v2 (في الواقع يجب أن أختبر أن العلاقات العامة الخاصة بي لن أعيد البناء على yarn add تعمل بالفعل في هذه الحالة)

أظن أن هذا هو سبب إعادة بناء هذه الحزم في كل مرة.

حدث التغيير الفعلي في هذا الالتزام: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
مرة أخرى في عام 2016. تمت إضافة اسم الملف uninstall.js في ذلك الوقت ، ولكن تمت إضافة force: true إلى العلامات التي تم تمريرها إلى install . لا يبدو أن هناك أي شيء محدد في تعليق الالتزام للإشارة إلى _السبب_.

سيكون رائعًا إذا كانت هناك طريقة لتجنب إعادة البناء في بعض الحالات على الأقل.

نرحب بأي شخص للعمل على العلاقات العامة. 😸 كما أشرت أعلاه ، لا تحدث عمليات إعادة البناء بالفعل على yarn install و yarn add (في معظم الحالات). لديّ # 5470 مفتوحًا يجب أن يزيل عمليات إعادة البناء غير الضرورية لـ yarn add عندما يكون لديك uws في تبعياتك (أو الحزم الأخرى التي تغير ملفاتها الخاصة أثناء التثبيت). الحالة الوحيدة المتبقية التي أعرفها هي yarn remove .

بعد قراءة معظم هذا الموضوع ، لا أفهم ما يحدث هنا.

لدي العديد من الحزم الأصلية التي يتم إعادة بنائها في كل مرة أستخدم فيها yarn add لأي وحدة نمطية أخرى (غير ذات صلة). يستغرق الأمر حوالي 20 دقيقة من التحميل العالي جدًا على وحدات المعالجة المركزية (CPU) الموجودة على جهاز الكمبيوتر المحمول. أنا فقط لا أستطيع العمل بهذه الطريقة.

على ما يبدو ، من هذا الموضوع ، كانت مشكلة لمدة 19 شهرًا.

هل هذه حقيب؟ هل يتم العمل عليه؟ ايوجد اي عمل في هذه المنطقه؟ هل يجب أن أعود إلى npm؟

هل يجب أن أعود إلى npm؟

نعم ، حتى يتم تحرير # 5470.

تضمين التغريدة

على ما يبدو ، من هذا الموضوع ، كانت مشكلة لمدة 19 شهرًا.

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

هل هذه حقيب؟

يمكن. ما هي الحزم التي يتم إعادة بناءها؟ المشكلة الوحيدة التي أعرفها كانت مشكلة مستمرة هي uws ، لذا فإن معرفة المزيد سيكون مفيدًا.

هل يتم العمل عليه؟

الحالة المحددة التي ذكرتها أعلاه ثابتة في # 5470

ايوجد اي عمل في هذه المنطقه؟

إذا كانت الحزمة التي تضيفها لا تحتوي على أي برامج نصية للتثبيت ، فيمكنك استخدام --ignore-scripts

أو يمكنك التحقق من الفرع من العلاقات العامة أعلاه واستخدامه.

يستغرق حوالي 20 دقيقة

نجاح باهر. أنا فضولي ما هي الحزمة.

شكرا على الرد.

يتم إعادة تجميع الحزم noise-search و level-rocksdb و jq كل مرة أقوم فيها بإضافة أي حزمة غير مرتبطة بـ yarn add . جهاز الكمبيوتر المحمول الخاص بي قديم بعض الشيء ، لذا يستغرق تجميعها في نفس الوقت وقتًا طويلاً جدًا.

لقد استخدمت Yarn 1.5.1 و node 9.8.0.

vibl yeesh ، noise-search هو بالتأكيد الجاني وراء البنيات الطويلة ...

~/Projects/yarn-test 🐒   yarn add noise-search
yarn add v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 73 new dependencies.
✨  Done in 426.15s.

أكثر من 7 دقائق على MacbookPro 😢

على أي حال ، لقد قمت بتثبيت noise-search ثم قمت بتشغيل yarn add left-pad برمز من 5470 # ولم يتسبب ذلك في إعادة البناء ، لذلك أعتقد أنك يجب أن تكون جيدًا بمجرد دمجنا 👍

شكر :-)

هل يجب أن أتحقق من Yarn مرة أخرى في غضون أيام قليلة أو بضعة أسابيع أو بضعة أشهر؟

لقد اكتشفت للتو أن هذا الخطأ ، مع نفس المشروع بالضبط على نفس الكمبيوتر المحمول (التمهيد المزدوج) ، لا يحدث في نظام التشغيل Windows 10. ولكنه موجود عبر أحدث ثلاثة إصدارات من Debian ، Ubuntu و Arch Linux و Fedora. عجيب. لم تجرب نظام التشغيل MacOS حتى الآن ، ولكن يبدو أن بعض الأشخاص يواجهون أيضًا مشكلات هناك.

vibl لست متأكدًا من موعد

nnmrts نعم اكتشفت أنه شيء محدد لنظام التشغيل. من تعليقاتي في # 5470:

على لينكس مع العقدة 8 ، عندما يتم نسخ الملفات من ذاكرة التخزين المؤقت إلى node_modules ، يتم تحديث الطوابع الزمنية. يقرر الغزل أن الملفات مختلفة ويمثل المرجع جديدًا.
يبدو أن هذا يحدث فقط على لينكس عقدة 8.
وذلك لأن Node v8.5 قدم fs.copyFile مما جعل النسخ أسرع بكثير. IIRC الذي ينقل إلى نسخة نظام الملفات الأصلي ، بحيث يفسر ذلك سبب عمله بشكل مختلف عبر أنظمة التشغيل وفي العقدة 8 فقط.

@ rally25rsnnmrts إنه بالتأكيد ليس شيئًا محددًا لنظام MacOS. يحدث أيضًا على جهاز الكمبيوتر الخاص بي Win10

@ stereokai حسنًا ، هذه المشكلة برمتها ليست محددة. في بعض الأحيان تحتاج الحزم إلى إعادة بناء وما زال الناس يعتقدون أنها خطأ ونشرها هنا. بدون إعادة إنتاج قوية قابلة للتكرار لكل نظام تشغيل ، لا يمكننا معرفة أي شيء.

قد يساعد التخزين المؤقت للوحدات المبنية محليًا (من # 5314) ؟:

أضف .yarnrc إلى مشروعك بما يلي:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

بعد التثبيت الأول ، ستعيش الوحدات المنشأة مسبقًا في ./<your-offline-mirror-path>/prebuilt . yarn.lock أيضًا مع المتغيرات المنشأة مسبقًا

تم سحب أحدث 66a0143a753cd4ade1a0fffee2174890d564c129 ، ويبدو أنه يعمل بشكل صحيح😎

لا يزال تنزيل ثنائي بشكل متكرر.

• عقدة v6.13.1
• غزل v1.6.0-20180327.1507
• نظام التشغيل: Ubuntu 17.10 Linux 4.13.7-041307-generic
• ~ / .yarnrc:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

yarn add node-sass
yarn remove node-sass
yarn add node-sass

يوم الخميس ، 29 مارس ، 2018 الساعة 2:30 صباحًا ، Andrew Lane [email protected]
كتب:

وحدات بناء التخزين المؤقت محليًا (من # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) قد يساعد ؟:

أضف .yarnrc إلى مشروعك بما يلي:

غزل - غير متصل - مرآة ". /"
حزم البرامج النصية التجريبية في المرآة صحيح

بعد التثبيت الأول ، ستعيش الوحدات المنشأة مسبقًا في
.// تم إنشاؤه مسبقًا. يتم أيضًا تحديث yarn.lock
ث / المتغيرات سابقة البناء

سحبت أحدث 66a0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ،
ويبدو أنه يعمل بشكل صحيح😎

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
.

snowyu هل حذفت yarn.lock و node_modules و yarn cache clean ؟ هل ./yarn-offline-mirror/prebuilt يحصل على تثبيت بعد التثبيت؟

إنه مشروع جديد في درجة الحرارة. نعم يمكنني رؤية الملف node-sass-4.8.3.tgz في مجلد ذاكرة التخزين المؤقت.
الآن ، أقوم بتشغيل yarn cache clean . ولكن لا يزال تنزيل ثنائي بشكل متكرر * .

"" باش

الحرف الأول - y
إضافة الغزل عقدة ساس
إضافة الغزل v1.6.0-20180327.1507
معلومات لم يتم العثور على ملف قفل.
[1/4] حل الحزم ...
[2/4] إحضار الحزم ...
[3/4] ربط التبعيات ...
[4/4] إنشاء حزم جديدة ... تنزيل ثنائي من https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
النجاح المحفوظة lockfile.
تم حفظ 152 تبعيات جديدة.
حرر في 11.98 ثانية.

إضافة الغزل عقدة ساس
إضافة الغزل v1.6.0-20180327.1507
[1/4] حل الحزم ...
[2/4] إحضار الحزم ...
[3/4] ربط التبعيات ...
[4/4] إنشاء حزم جديدة ... تنزيل ثنائي من https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
النجاح المحفوظة lockfile.
تم حفظ تبعية جديدة واحدة.
معلومات التبعيات المباشرة
└─ [email protected]
معلومات جميع التبعيات
└─ [email protected]
حررت في 13.45 ثانية.
"

حسنًا ، لقد قمت بعمل git repo بسيطًا لإعادة إنتاج هذا الخطأ.

https://github.com/vlmonk/yarn-bug-test

غزل أداء لا لزوم لها إعادة بناء ttf2woff2 عندما أحاول إضافة صفر التبعية left-pad

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
yarn
[ ... building binary package here ... ]
yarn add left-pad
[ ... rebuilding binary packages here ... ]

يمكنني إعادة إنتاج هذا في كل من نظام OSX المضيف وفي حاوية عامل الإرساء بأحدث صورة node

يعمل NPM بشكل صحيح في هذه الحالة:

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
npm i 
[ ... building binary package here ... ]
npm i left-pad
[ ... don't rebuild binary packages here ... ]

إصدار الغزل الخاص بي 1.5.1

vlmonk هل https://github.com/rally25rs/yarn من @ rally25rs واستخدام الكود في # 5470 (الفرع fix-linking-rebuilding-uws-932 )؟

karlhorky نعم ، لا يزال الغزل ttf2woff2 بعد إضافة left-pad

# which yarn
yarn: aliased to node /Users/monk/work/yarn/lib/cli/index.js
# yarn --version
1.6.0-0

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

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

لقد تحققت من هذا مع تسجيل إضافي (https://github.com/sth/yarn/tree/trace-rebuild). عند التثبيت لأول مرة يظهر:

build artifacts for ttf2woff2
  modified file: build
  modified file: build/Makefile
  modified file: build/Release
  modified file: build/Release/.deps
  modified file: build/Release/.deps/Release
  modified file: build/Release/.deps/Release/addon.node.d
  modified file: build/Release/.deps/Release/obj.target
  modified file: build/Release/.deps/Release/obj.target/addon
  modified file: build/Release/.deps/Release/obj.target/addon/csrc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/addon.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/backward_references.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/block_splitter.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode_parallel.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/entropy_encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/histogram.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/literal_cost.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/metablock.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/streams.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/font.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/glyph.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/normalize.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/table_tags.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/transform.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/variable_length.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_common.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_enc.o.d
  modified file: build/Release/.deps/Release/obj.target/addon.node.d
  modified file: build/Release/addon.node
  modified file: build/Release/obj.target
  modified file: build/Release/obj.target/addon
  modified file: build/Release/obj.target/addon/csrc
  modified file: build/Release/obj.target/addon/csrc/addon.o
  modified file: build/Release/obj.target/addon/csrc/enc
  modified file: build/Release/obj.target/addon/csrc/enc/backward_references.o
  modified file: build/Release/obj.target/addon/csrc/enc/block_splitter.o
  modified file: build/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode_parallel.o
  modified file: build/Release/obj.target/addon/csrc/enc/entropy_encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/histogram.o
  modified file: build/Release/obj.target/addon/csrc/enc/literal_cost.o
  modified file: build/Release/obj.target/addon/csrc/enc/metablock.o
  modified file: build/Release/obj.target/addon/csrc/enc/streams.o
  modified file: build/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/obj.target/addon/csrc/woff2/font.o
  modified file: build/Release/obj.target/addon/csrc/woff2/glyph.o
  modified file: build/Release/obj.target/addon/csrc/woff2/normalize.o
  modified file: build/Release/obj.target/addon/csrc/woff2/table_tags.o
  modified file: build/Release/obj.target/addon/csrc/woff2/transform.o
  modified file: build/Release/obj.target/addon/csrc/woff2/variable_length.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_common.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_enc.o
  modified file: build/Release/obj.target/addon.node

يحتوي ملف الحزمة https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz بالفعل على تلك الملفات.

نرى هذا مع OS X أيضًا ، بإضافة أي حزمة بها yarn add تؤدي إلى إعادة تجميع أي حزم تابعة. لدينا حزمة node-gyp برمز أصلي ، ويستغرق الأمر أكثر من دقيقة واحدة في كل مرة تتم فيها إضافة حزمة أخرى ، ولا يوجد الكثير من التعليمات البرمجية في الوحدة النمطية الأصلية حتى الآن (ستزداد سوءًا). هذا مع الغزل 1.5.1.

نحن نستخدم yarn add ../a مع المسارات النسبية إذا كان ذلك يحدث فرقًا.

يرجى إعلامي إذا كان هناك أي حلول ، أو متى سيتم إصلاحه.

هذا مع الغزل 1.5.1.

تم إصلاح هذه المشكلة في الإصدار 1.6.0 والذي تم إصداره مؤخرًا.

ما زلت أرى هذا مع 1.6. منذ الانتقال من npm إلى yarn منذ وقت طويل uws كما هو الحال yarn تم تعليقه على uws لـ حوالي 5-10 ثوان).

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

1. غزل $ عفا عليه الزمن
2. اختر حزمة قديمة
3. $ yarn Upgrade [package]

grantila هل يمكنك تقديم package.json أو الريبو مع الخطوات التي تعيد إنتاج هذا باستخدام Yarn 1.6.0 ؟

لا يزال هذا يحدث عند 1.6.0

يمكنك استنساخ هذا باستخدام https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784

لدي مشروع بسيط وأرى هذا أيضًا. يبدو أن إضافة حزمة أو إزالتها يؤدي إلى إعادة بناء كاملة لحزمة واحدة على الأقل في كل مرة.

"dependencies": {
    "bufferutil": "3.0.4",
    "chance": "1.0.16",
    "discord.js": "11.3.2",
    "dog-facts": "1.0.3",
    "erlpack": "discordapp/erlpack",
    "flickr-sdk": "3.7.0",
    "html-entities": "1.2.1",
    "node-opus": "0.2.7",
    "snekfetch": "4.0.0",
    "sodium": "2.0.3",
    "utf-8-validate": "4.0.1"
  }

بعد تثبيتها ، أضفت الحزمة unescape ، والتي أدت إلى إعادة بناء sodium . ثم قمت بإزالته مما أدى إلى إعادة بناء ما بدا وكأنه كل حزمة تحتاج إلى تجميع. استغرقت إضافة هذه الحزمة البسيطة 36 ثانية وإزالتها استغرقت 100 ثانية!

EDIT: استخدام Node 8.11.1 و yarn 1.6.0 على Debian Stretch.

arcanis @ rally25rs pleaase أعد فتح المشكلة ، ولا تزال هناك تقارير متعددة عن هذا الأمر ، حتى مع الإصلاح المدمج.

أعتقد أن هذه مشكلة @ rally25rs :)

غرانتيلا upgrade سوف _always_ إعادة بناء الكل. هذا متعمد. npm يفعل الشيء نفسه (أذكر هذا في تعليق في مكان ما في هذا الموضوع الطويل.) على الرغم من أننا قد نحاول التوقف عن فعل ذلك. لست متأكدًا من تداعيات ذلك.

أي أحد غيره:

في # 5680 ، أشرت إلى أن هذا لا يزال يحدث إذا حذفت الحزمة ملفاتها الخاصة _ (لماذا يا لماذا يفعلون هذه الأشياء 😿) _ ولا يتتبع الغزل ذلك في أي مكان (نتتبع الملفات التي تم إنشاؤها أو تعديلها) ، لذلك تعتقد فقط أن الحزمة تفتقد الملفات وتعيد بنائها.

أفترض أنه يمكننا إعادة فتح هذا ، ولكن تم إصلاح هذا لمعظم الحزم. إذا أراد أي شخص إضافة "أنا أيضًا" إلى هذا ، _يرجى_ إما تقديم package.json الخاص بك ، أو ذكر بالتحديد الحزمة التي يتم إعادة بنائها باستمرار ، حيث قد يكون لديك بعض التبعيات التي تقوم بإعادة البناء والبعض الآخر لا يقوم بذلك.

نرحب بأي شخص لإجراء العلاقات العامة لهذا! (انظر تعليقاتي في تصحيح الأخطاء في # 5680)

آسف لإضافة المزيد من الضوضاء ، لكني أود أن أقترح قفل هذه المشكلة والإشارة إلى مشكلة جديدة بها أحدث المعلومات في الأعلى.

أعتقد أن المشكلة هنا قد تغيرت قليلاً وتم حلها جزئيًا على الأقل. مع كل المنشورات هنا ، يصعب على شخص جديد أن يكون على اطلاع دائم بما تم إصلاحه وما لا يزال يمثل مشكلة.

أتفق مع @ james-rabbit

نعم ، أنت على حق. سأقفل هذا حتى @ rally25rs مرئية.

إذا كانت لديك مشكلة مع الحزم الأصلية:

• إذا حدث ذلك مع كل تبعية أصلية ، فيرجى فتح مشكلة عامة. كان من المفترض حل هذه المشكلة ، لذلك لا أتوقع رؤية واحدة في أي وقت قريب - ومع ذلك ، إذا كان بإمكانك تقديم خطوات إعادة الإنتاج ، فلا تتردد في فتح مشكلة جديدة (ويمكنك الارتباط بهذه المشكلة إذا أردت).

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