yarn 🚀 - देशी पैकेज हर बार फिर से बनाए जाते हैं

मैक OSX (10.11.6) में इसे पुन: पेश नहीं किया जा सकता है इसलिए यह एक Ubuntu विशिष्ट मुद्दा हो सकता है?

jkimbo 12 अक्तू॰ 2016

मैं विंडोज 10 पर रिप्रो कर सकता था, लेकिन केवल एक बार। दूसरी बार जब मैंने "यार्न" चलाया, तो इसने देशी पुस्तकालयों का पुनर्निर्माण नहीं किया। अजीब।

Daniel15 13 अक्तू॰ 2016

मैं इसके साथ कुछ और खेल रहा था और कुछ और विवरणों के साथ आया:

यदि मैं yarn add leveldown bcrypt , leveldown सूची में पहली वस्तु के रूप में संकलित करूँगा और node_modules/.yarn-integrity में हैश समाप्त होने पर 595306... बराबर होगा (कट जाएगा) संक्षिप्तता के लिए; मेरा मानना है कि एक चेकसम है जो निर्धारित करता है कि क्या कुछ करने की आवश्यकता है)। अब अगर मैं yarn फिर से चलाता हूं, तो दोनों संकुल को bcrypt सूची में पहले के रूप में संकलित किया जा रहा है (ऑर्डर अलग है)। परिणामी चेकसम cbe480... बराबर होगा। yarn बाद के आह्वान से पैकेजों का पुनर्निर्माण नहीं होगा और चेकसम समान रहेगा। यह मेरी मूल रिपोर्ट का विरोधाभास करता है (मैंने शायद कहीं गलती की है) लेकिन जो @ डैनियल 15 देख रहा था उसके साथ संरेखित करता है।
जब मैं शुरू से ही पैकेजों के क्रम को उलट देता हूं ( yarn add bcrypt leveldown ), bcrypt पहले सूची में होगा और परिणामस्वरूप चेकसम cbe480... बराबर होगा। yarn बाद के आह्वान से पैकेजों का पुनर्निर्माण नहीं होगा।
bcrypt पैकेज हमेशा पहले ही खत्म हो जाएगा (जैसा कि उम्मीद है कि सूची में स्थिति की परवाह किए बिना बस इतना संकलन करने के लिए नहीं है)।

मैं इंटर्नल से बिल्कुल परिचित नहीं हूँ लेकिन यह मुझे लगता है कि जिस क्रम में संकुल संकलित किया जाता है और वे पहले क्रम में स्थापित होने पर सॉर्ट नहीं किए जा रहे हैं (और वे _are_ तब सॉर्ट करते हैं जब बाद में yarn ) जो किसी तरह से चेकसम को प्रभावित करता है।

jiripospisil 15 अक्तू॰ 2016

👍4

जांच के लिए धन्यवाद! यह एक अच्छा नेतृत्व की तरह लगता है। यहाँ हैश लिखा है: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/commands/install/js#L581 -L583। यह उस कोड को डीबग करने के लायक हो सकता है और यह देखना कि लॉकफ़ाइल में क्या भिन्न है, जैसा कि .yarn-integrity में हैश लॉकफ़ाइल से आधारित है।

Daniel15 15 अक्तू॰ 2016

यह उस कोड को डीबग करने के लायक हो सकता है और यह देखना कि लॉकफ़ाइल में क्या अलग है, जैसा कि हैश में .yarn-अखंडता लॉकफ़ाइल से दूर है।

मुझे संदेह था कि लेकिन जो मुझे फेंक दिया गया वह यह था कि लॉक फ़ाइल नहीं बदलती है, यह हमेशा एक ही है। यह सिर्फ हैश में .yarn- अखंडता है कि बदल जाता है।

$ 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

jiripospisil 15 अक्तू॰ 2016

मेरे पास एक ही मुद्दा है: मैं bcrypt का भी उपयोग करता हूं। हर बार जब मैं कुछ नए मॉड्यूल स्थापित करता हूं या अपग्रेड मौजूद होते हैं, तो मुझे अपने ऐप को चलाने योग्य बनाने के लिए npm rebuild चलाना होगा।

macOS 10.12 && नोड v7.0.0 और& यार्न v0.16.1

hustcer 30 अक्तू॰ 2016

मैं अब मूल मुद्दे को पुन: पेश नहीं कर सकता। ऐसा लगता है कि निश्चित किया गया है: +1:। @ डैनियल 15 क्या आप पुष्टि कर सकते हैं?

@ मुझे लगता है कि यह एक ही मुद्दा नहीं है। यदि आप अभी भी आपके लिए काम नहीं कर रहे हैं तो आप नवीनतम संस्करण के साथ परीक्षण कर सकते हैं और एक नया बग दर्ज कर सकते हैं।

jiripospisil 17 नव॰ 2016

@jiripospisil धन्यवाद, यार्न v0.17.4 के उन्नयन के बाद अब यह ठीक है।

hustcer 18 नव॰ 2016

मैं अभी भी इसे देख रहा हूं, या 0.18.1 पर कुछ समान है। संयोग से, यह भी पुराना है जो बार-बार पुनर्निर्माण करता रहता है। प्रदर्शनकारी उद्देश्यों के लिए कोई निर्भरता (और लेवल्डाउन पर निर्भर नहीं है) के साथ एक पैकेज के रूप में लेफ्टपैड का उपयोग करना, रिप्रो स्टेप्स इस प्रकार हैं:

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)

seansfkelley 25 दिस॰ 2016

कृपया फिर से खोलें क्योंकि यह अभी भी होता है।
बस yarn add redux और इसने bcrypt , node-sass और कई अन्य का पुनर्निर्माण किया।

नोड v6.9.4
यार्न v0.20.3
विंडोज 10

ndraiman 22 फ़र॰ 2017

👍3

@ 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 22 फ़र॰ 2017

@jiripospisil मेरे पास प्रदान करने के लिए कोई प्रजनन कदम नहीं है, बस एक अतिरिक्त पैकेज स्थापित करने से यार्न सब कुछ लिंक और पुनर्निर्माण करता है।

यहां एक पैकेज को जोड़ने का आउटपुट (लॉक फ़ाइल पहले से मौजूद है):

निर्भरता को जोड़ना:
linking dependencies

पुनर्निर्माण:
rebuilding

ndraiman 23 फ़र॰ 2017

@jiripospisil मैं अभी भी यह देख रहा हूं, लेकिन मेरे थर्रा गया क्योंकि यह leveldown (या एक निर्भरता) की तरह लग रहा है कि शायद एक OS X- संगत बाइनरी शिपिंग शुरू कर दिया है, इसलिए स्थापित समय 50s से 3s करने के लिए लगभग गिरा दिया। यदि आप OS X पर हैं और आप विशेष रूप से yarn add [email protected] बजाय केवल yarn add leveldown , तो आपको पहले जैसा ही व्यवहार देखना चाहिए।

seansfkelley 23 फ़र॰ 2017

मेरे पास ttf2woff2 पर एक अप्रत्यक्ष निर्भरता है, जो हर बार पुनर्निर्मित भी होती है।

हालाँकि, यह केवल हर बार पुनर्निर्मित होता है जब yarn.lock में कोई परिवर्तन होता है। अर्थात yarn एक नए yarn.lock , yarn upgrade , yarn upgrade-interactive । yarn upgrade-interactive मामले में, यदि दोनों अवमूल्यन और नियमित डिपो अपडेट किए गए थे, तो ttf2woff2 दो बार पुनर्निर्माण (!) हो जाता है।

Jessidhia 2 मार्च 2017

👍3

मैं इस मुद्दे को भी देख रहा हूं, हालांकि मैं इसे ऊपर के चरणों के साथ पुन: पेश नहीं कर सका। हालाँकि मैं इसे इन चरणों के साथ पुन: पेश कर सकता हूं:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

यार्न जोड़ें सह
`` `

तब यह फिर से लेवेल्डाउन बनाता है।

इससे कोई फर्क नहीं पड़ता कि मैं कौन सा पैकेज जोड़ता हूं, यह हमेशा leveldown का पुनर्निर्माण करता है।

मैं यार्न v0.21.3, विंडोज 10 और नोड v7.7.1 का उपयोग कर रहा हूं

jefftimlin 13 मार्च 2017

मैं यह भी देख रहा हूं। मैं BuckleScript (bs-platform) का इस्तेमाल कर रहा हूं ...।

jackalcooper 13 मार्च 2017

👍6

मैं sharp साथ भी इस समस्या का सामना कर रहा हूं। हर बार जब भी मैं yarn add या yarn remove , sharp चलता हूं, तब भी गैर-देशी पैकेज मिलेंगे।

विंडोज 10 और उबंटू लिनक्स 16.04 के तहत यार्न v0.21.3, नोड 7.0.0 में परीक्षण किया गया।

यहाँ 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"
  }
}

tkesgar 30 मार्च 2017

👍4

यह भी bs-platform साथ देख रहा है

svoynow 19 अप्रैल 2017

👍3

साथ ही ttf2woff2 हर कॉल के साथ yarn add रिबिल्ड करने का अनुभव ttf2woff2 भी यह एक वर्ष से अधिक समय में प्रकाशित नहीं हुआ है।

patrickhulce 20 अप्रैल 2017

👍2

काउचबेस के साथ भी मेरे पास यही है

संपादित करें: 0.23.2 में तय किया गया लगता है

technicallyfeasible 21 अप्रैल 2017

यह अभी भी मेरे साथ 0.23.2 पर होता है ( argon2 और node-sass हर बार जब भी मैं कुछ असंबद्ध पैकेज जैसे moment जोड़ / हटाता हूं, जिस पर कोई निर्भरता नहीं होती है)

ओएस: विंडोज 10
नोड: 7.9.0
सूत: 0.23.2

raleksandar 21 अप्रैल 2017

👍2

कुछ और रंग, पर हो रहा की मेरी धारणा को जोड़ने के लिए yarn add <some-package> के रूप में मेरे लिए कई मामलों वास्तव में साथ संयोजन के द्वारा ट्रिगर किया गया वास्तविकता की तुलना में काफी अधिक था yarn remove <unrelated-package> ठीक पहले की वजह से force: true इस लाइन पर force: true ।

निश्चित रूप से ताला लॉफ़ाइल उत्पन्न करने के लिए हटाने में स्थापित तर्क का पुन: उपयोग करने के लिए सुविधाजनक है, लेकिन यह अच्छा होगा अगर यह एक मजबूर इंस्टॉल के सभी सामान के साथ नहीं आया :)

patrickhulce 25 अप्रैल 2017

मेरे लिए यह तब होने लगा जब मैंने 0.23.x पर अपग्रेड किया। मैं 0.21.3 पर लौट आया और यह अब हर बार नहीं बनता है। इसके अलावा इस समस्या के कारण जहां मेरा IP unicode.org द्वारा कुछ पैकेजों को एक पंक्ति में अपग्रेड करने के बाद अवरुद्ध किया गया था https://github.com/dodo/node-unicodetable/issues/16

kriscarle 29 अप्रैल 2017

हालांकि 0.21.3 एक नया पैकेज जोड़ने पर सभी पैकेजों का पुनर्निर्माण नहीं करता है, यह सभी पैकेजों को हटाने पर पुनर्निर्मित करता है। और ऐसा लगता है कि यदि पुनर्निर्माण विफल रहता है तो यार्न इसे विफल नहीं मानता है।

zhangjyr 3 मई 2017

👍2

मेरे लिए, 0.21.3 डाउनग्रेड करने से मदद नहीं मिली। bs-platform हर ऐड / रिमूव पर फिर से बनता है।

akxcv 6 मई 2017

👍2

इसे यार्न 0.23.4 के साथ macOS पर देखना। 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.

EthanMichaels 16 मई 2017

👍2 👎1

इस समस्या को Ubuntu 16.04LTS के साथ, नवीनतम यार्न v0.24.6 के साथ, नोड 8.1.2 के साथ देखें

मैं हर बार जब भी एक मॉड्यूल जोड़ता हूं, तो मैं gdal , node-sass पुनर्निर्माण देख रहा हूं, इससे यार्न को अधिक से अधिक चलने का रास्ता मिल रहा है।

billxinli 21 जून 2017

👍4

मैं यह भी देख रहा हूं, यह रास्पबेरी पाई ज़ीरो डब्ल्यू पर सुपर कष्टप्रद है जहां बिल्डिंग पैकेज (ब्लेंनो की तरह) कई मिनट लग सकते हैं।

richkzad 22 जून 2017

👍1

फिर भी यार्न v0.27.5 और uws साथ इसे देखना। जब भी मेरे पैकेज में कुछ बदलता है, तो uws को फिर से बनाया जाता है।

केवल एक ही दिलचस्प बात मैं uws बारे में देख सकता हूं कि पैकेज में यह

wmertens 3 जुल॰ 2017

👍10

यह पिछले कुछ दिनों से मेरे लिए काफी हताशा बन रहा है। मेरे पास एक चरण में वैश्विक स्तर पर windows-build-tools स्थापित थे (केवल मूल पैकेजों के लिए विंडोज देव वातावरण स्थापित करने के लिए केवल एक बार खुद को बनाने की आवश्यकता थी) जो हर बार जब मैं एक पैकेज जोड़ता था, तो खुद को फिर से बनाता रहा। जैसा कि आप सोच सकते हैं कि इसमें काफी समय लगा और मुझे आखिरकार एहसास हुआ कि मुझे इसे अब और स्थापित करने की आवश्यकता नहीं है।

अब ऐसा लगता है कि node-sass संकुल जोड़ते समय किसी अन्य अनुमानित प्रोजेक्ट पर पुनर्निर्माण करना चाहता है।

यह व्यवहार मेरे लिए yarn add और yarn remove दोनों पर होता है। निश्चित रूप से इन चरणों के लिए कोई पुनर्निर्माण आवश्यक नहीं है क्योंकि देशी पैकेज केवल एक बार नोड संस्करण के अनुसार बनाए जाते हैं?

संपादित करें: विंडोज 10 पर नोड v8.2.1 और यार्न v0.27.5 का उपयोग करना।

lostpebble 31 जुल॰ 2017

मैं उस समय की गणना नहीं कर सकता हूं कि uws का मेरे लिए पुनर्निर्माण किया गया था :) ध्यान दें कि uws
शून्य निर्भरता है और यहां तक कि पैकेज में फ़ील्ड गायब है

सोम, जुलाई ३१, २०१ Paul, १०:५० PM पॉल म्यूर्बर्ग नोटिफिकेशन @github.com पर
लिखा था:

यह पिछले कुछ दिनों से मेरे लिए काफी हताशा बन रहा है। मैं था
विंडोज़-बिल्ड-टूल्स एक स्तर पर विश्व स्तर पर स्थापित किए गए हैं (केवल वास्तव में इसकी आवश्यकता है
देशी के लिए विंडोज देव वातावरण स्थापित करने के लिए एक बार स्वयं का निर्माण करें
संकुल) जो हर बार अपने आप को जोड़कर रखता था जब मैंने एक पैकेज जोड़ा था। जैसा
आप सोच सकते हैं कि इसमें काफी समय लगा और मुझे अंततः एहसास हुआ कि मैंने नहीं किया
अब इसे स्थापित करने और इसे हटाने की आवश्यकता है।
अब ऐसा लगता है कि नोड-एसएएस दूसरे अनुमानित प्रोजेक्ट पर पुनर्निर्माण करना चाहता है
पैकेज जोड़ते समय।
यह व्यवहार मेरे लिए यार्न ऐड और यार्न निकालने दोनों पर होता है। निश्चित रूप से नहीं
इन चरणों के लिए पुनर्निर्माण आवश्यक है क्योंकि देशी पैकेज केवल निर्मित होते हैं
नोड संस्करण के अनुसार एक बार?
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 , या म्यूट
सूत्र
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
।

wmertens 1 अग॰ 2017

मैं 0.27.5 पर हूं और bs-platform साथ इस व्यवहार को देखता रहूंगा।

johannth 8 अग॰ 2017

यह एक हताशा है, यहाँ bs-platform साथ डिटो।

constfun 13 अग॰ 2017

👍1

वहाँ एंटाइटेलमेंट का अच्छा अर्थ ... कैसे एक पीआर टिम के बारे में?

Tue पर, 22 अगस्त, 2017, 10:44 AM टिम स्नाइडर सूचनाएं @github.com
लिखा था:

एफएफएस कृपया इसे ठीक किया जा सकता है।
कम से कम एक कमांड लाइन विकल्प प्रदान करें या इसे अक्षम करने के लिए एनवी सेटिंग।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 , या म्यूट
सूत्र
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
।

wmertens 22 अग॰ 2017

👍4

ऐसा लगता है कि अब तक इसका उल्लेख नहीं किया गया है, लेकिन मैं yarn global list साथ इस बग को पुन: पेश भी कर सकता हूं।

प्रजनन करने कि प्रक्रिया:

एक ताजा वैश्विक env का उपयोग करें:: चेतावनी: इसे केवल तभी चलाएं जब आप जानते हैं कि आप क्या कर रहे हैं
```
rm -rf ~/.config/yarn/
```

एक समस्याग्रस्त पैकेज जोड़ें (_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.

yarn global list चलाएं और देखें कि कुछ देशी पैकेज पुनर्नवीनीकरण किए जा रहे हैं
जितना चाहें उतना दोहराएं, yarn global list हमेशा उन मूल पैकेजों को फिर से जोड़ेंगे
😭

आशा है कि ये आपकी मदद करेगा।

। मैकओएस 10.12.6 यार्न के साथ 0.27.5 होमब्रे के माध्यम से स्थापित किया गया।

michaelbaudino 22 अग॰ 2017

👍2

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

अब लगभग एक साल हो गया है क्योंकि यह पहली बार रिपोर्ट किया गया था।

मुझे आशा है कि मैं यह कहने में हकदार नहीं हूं कि ... मैं यह जोड़ना चाहूंगा कि मैं इस परियोजना के लिए बहुत आभारी हूं और यह उपयोगिता मेरे लिए पहले से ही है। यह मुद्दा मेरे साथ बहुत कम दर्द बिंदुओं में से एक रहा है।

संपादित करें: बस एक यादृच्छिक पैकेज के लिए yarn remove किया और यह कोशिश की और (इस बार) मेरे बायनेरिज़ के पुनर्निर्माण में विफल रहा। साइड-इफ़ेक्ट यह है कि मेरी बायनेरिज़ अब पूरी तरह से गायब हैं और इसे ठीक करने का एकमात्र तरीका npm rebuild । इसलिए न केवल यह प्रतीत होता है कि यह मुद्दा अनावश्यक पुनर्निर्माण का कारण बनता है - लेकिन अगर यह उस प्रक्रिया को विफल करता है, तो ऐसा लगता है कि आपको इसे फिर से ठीक करने के लिए npm का सहारा लेना होगा।

lostpebble 23 अग॰ 2017

👍13

मैं @zhangjyr और @lostpebble के समान व्यवहार देख रहा हूं। yarn add चलना ठीक काम करता है लेकिन yarn remove मूल पैकेजों को फिर से बनाने का कारण बनता है।

मैक सिएरा 10.12.6
सूत 0.27.5

farism 29 अग॰ 2017

मैं यह देखने की कोशिश करूंगा कि मैं इसके बारे में क्या कर सकता हूं क्योंकि यह मुझे भी प्रभावित करता है। उन्होंने कहा कि यार्न इतना मुश्किल नहीं है कि अगर कोई किसी को पीआर भेजना चाहे, तो कृपया उसे एक शॉट दें और हम आपको जितना संभव हो उतना समर्थन देने की कोशिश करेंगे।

मैं कुछ हफ्तों तक इस पर काम नहीं कर पाऊंगा।

BYK 29 अग॰ 2017

👍8

मैं यह भी देख रहा हूं।
साइट के निर्माण पर Gatsby पर काम करना। किसी भी यार्न ऑपरेशन के पुनर्निर्माण का कारण बनता है।
इसके साथ gatsby और yarning के साथ साइट बनाने का प्रयास करें। उम्मीद है की यह मदद करेगा

Rulikkk 11 सित॰ 2017

👍1

यह एक परियोजना में देख gatsby का उपयोग कर:
यार्न 1.0.2
नोड 7.10.1
ubuntu 16.04

AndyMoreland 16 सित॰ 2017

यह मुद्दा अब काफी गंभीर होता जा रहा है। न केवल मेरे बायनेरिज़ हमेशा फिर से निर्मित होते हैं। लेकिन अक्सर ऐसा होता है कि मेरे बायनेरिज़ को yarn add या yarn install ( package.json में एक पैकेज के संस्करण संख्याओं को बदलने / रोलबैक को अपडेट करने के लिए) के बाद पूरी तरह से हटा दिया जाता है। और कोई फर्क नहीं पड़ता कि मैं yarn install या yarn install --check-files बाद में भागता हूं, वे बायनेरिज़ बस खो गए और चले गए और कभी वापस नहीं आए। उन्हें पुनः प्राप्त करने का एकमात्र तरीका npm rebuild ।

यह महसूस करना शुरू कर रहा है कि यार्न के पास मूल पैकेज की स्थिति के बारे में बिल्कुल भी ज्ञान नहीं है। चाहे वे पहले से स्थापित / निर्मित हों, या यदि वे ठीक से स्थापित / निर्मित नहीं हैं।

क्या इस पर शायद कोई प्रगति हुई है?

lostpebble 27 सित॰ 2017

👍1

मुझे लगता है कि @arcanis द्वारा यार्न अखंडता फ़ाइल के अलावा हाल के artifacts फ़ील्ड इस मुद्दे को ठीक करने में मदद करेंगे। अभी तक कोई प्रगति नहीं है, लेकिन पीआर के लिए खुला :)

BYK 27 सित॰ 2017

👍1

मुझे अपने प्रॉजेक्ट एमएल प्रोजेक्ट में पैकेज स्थापित करने के दौरान bs-platform के साथ एक समान समस्या है

cullophid 3 अक्तू॰ 2017

👍1

समान ... शाब्दिक रूप से हर yarn add जिप परियोजना का पुनर्निर्माण करेगा।

MeirionHughes 13 अक्तू॰ 2017

👎1

यहां भी होता है।
(यार्न 1.2.1)

Okoyl 22 अक्तू॰ 2017

👎1

मैं इसे node-sass साथ देखता हूं।

jbrooksuk 25 अक्तू॰ 2017

👎1

उदाहरण के लिए सरू के साथ मेय करने के लिए होता है।

नोड -v
v8.8.1
यार्न -v
1.2.1

piehei 26 अक्तू॰ 2017

👎1

✋ बिना किसी अतिरिक्त जानकारी के "मी टू" लिखने के बजाय, शीर्ष पद पर जीथब में +1 सुविधा का उपयोग करें। हर बार जब आप "मुझे भी" टिप्पणी लिखते हैं, तो 35 ग्राहक अनावश्यक रूप से अधिसूचित होते हैं।

sandstrom 26 अक्तू॰ 2017

👍6

+1

HafizAhmedMoon 26 अक्तू॰ 2017

👎9 😄3 😕2

यदि आप अपडेट प्राप्त करना चाहते हैं तो कृपया Subscribe क्लिक करें। मुझे उम्मीद है कि हर कोई इसे हल किए जाने पर अधिसूचित करना चाहता है लेकिन तब नहीं जब किसी नए ने इस मुद्दे का सामना किया।

@ NYK आप कृपया थ्रेड लॉक कर सकते हैं, और इसे केवल मालिकों के लिए उपलब्ध

printercu 26 अक्तू॰ 2017

👍7

मैं वर्तमान में इस मुद्दे की जांच कर रहा हूं और इसे न्यूनतम प्रजनन योग्य परीक्षण के मामले में उबालने की कोशिश कर रहा हूं। इस मुद्दे को प्रदर्शित करने के लिए एक "महान" पैकेज 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 नए पुनर्निर्माण में परिणाम नहीं करती है।

संपादित करें : ऊपर से सभी पोस्टों को पढ़ने से ऐसा लगता है कि यह मामला किसी के लिए कोई आश्चर्य की बात नहीं होगी - ज्यादातर लोग, जिनमें खुद शामिल हैं, यह पा रहे हैं कि बस यार्न से _anything_ को फिर से बनाने के लिए कह रहे हैं। मैं यह अनुमान लगा रहा हूं कि यह समुदाय में एक बड़ा मुद्दा नहीं है क्योंकि अधिकांश लोग देशी पैकेज का उपयोग नहीं करते हैं जो निर्माण के लिए लंबा समय लेते हैं - इसलिए उनके पास या तो पुनर्निर्माण कदम नहीं है या यह इतनी जल्दी खत्म हो जाता है कि कौन परवाह करता है।

nfarina 26 अक्तू॰ 2017

👍4

ठीक है, इसलिए बहुत डिबगिंग के बाद, यह प्रतीत होता है कि यह व्यवहार जानबूझकर है। कोड के माध्यम से ट्रेसिंग, ऐसा लगता है, उदाहरण के लिए, निम्न चरणों में yarn upgrade [email protected] परिणाम:

1) upgrade मॉड्यूल को कहा जाता है, जो new Add() लिए left-pad new Add() ऑपरेशन चलाता है।
2) Add.init() अपने सुपरक्लास को Install.init() ,
3) Install.init() क rebuildingPackages कदम
4) PackageInstallScripts.init() यह केवल _all_ पैकेज इकट्ठा करता है और उन्हें workQueue के पुनर्निर्माण के लिए जोड़ता है।
5) PackageInstallScripts तब पता चलता है कि htmlstrip-native लिए एक इंस्टॉल कमांड है और बस इसे चलाता है - यह सुपर-स्लो देशी पुनर्निर्माण है जो हम सभी देख रहे हैं।

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

मैं यार्न टीम के किसी व्यक्ति को यहां झंकार देना पसंद करूंगा - यदि यह व्यवहार वास्तव में जानबूझकर है, तो मैं इस मुद्दे को बंद करने की सलाह दूंगा!

व्यक्तिगत रूप से मेरी स्थिति के लिए, मैं अपने htmlstrip-native निर्भरता की अदला-बदली करने जा रहा हूं क्योंकि कोई कारण नहीं है कि इसे बनाने में मिनट लग जाएं (यह पसंद है, एक युगल .c फाइलें)। मेरे बाकी मूल निवासी जल्दी से निर्माण करते हैं, इसलिए यदि यह हर समय होता है तो यह कोई बड़ी बात नहीं है।

nfarina 26 अक्तू॰ 2017

👍6

यह डिजाइन के एक अनजाने साइड इफेक्ट की तरह लगता है, लेकिन शायद @ यार्नपॉके / कोर पर कोई भी इसके बारे में टिप्पणी कर सकता है। मुझे नहीं लगता कि यह उन पैकेजों को फिर से बनाने का इरादा है जिन्हें फिर से बनाने की आवश्यकता नहीं है।

Daniel15 26 अक्तू॰ 2017

यह जानबूझकर नहीं है, शायद इस तरह से लागू करना आसान है।
BYK के ऊपर एक टिप्पणी है जो कहती है कि यह समस्या एक पीआर की तलाश में है:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

james-rabbit 26 अक्तू॰ 2017

निश्चित रूप से देशी-भारी पैकेज यार्न के लिए सर्वोच्च प्राथमिकता के रूप में सतह के लिए पर्याप्त नहीं हैं, हालांकि यार्न में हर इंस्टॉल पर पैकेजों का पुनर्निर्माण नहीं करने की क्षमता है।
यह एक बग की तरह लगता है जिसे ठीक करने के लिए सीधे आगे होना चाहिए, एक पीआर भेजें।
वहाँ चेतावनी हो सकती है क्योंकि यार्न यह सुनिश्चित करने के लिए नहीं जान सकता कि अगर एक निर्मित पैकेज को दूषित किया जा सकता था, यही कारण है कि अब यह उत्सुकता से स्थापित स्क्रिप्ट्स को पुन: स्थापित करना है।

एक यार्न कांटा है जो कि कारण https://github.com/esy-ocaml/esy-install के पीछे टीम द्वारा उपयोग किया जाता है जो बहुत सारे मूल संकलन मुद्दों के आसपास काम करता है क्योंकि कारण / Ocaml निर्भरता को भारी संकलन की आवश्यकता होती है।
जैसा कि दृष्टिकोण परिपक्व होता है मुझे उम्मीद है कि परिवर्तनों को ऊपर की तरफ विलय करना संभव होगा।

bestander 30 अक्तू॰ 2017

👍4

इसलिए मूल रूप से, देशी पैकेजों को फिर से बनाया जाता है क्योंकि या तो:

1) force=true झंडा सेट किया गया है, या
2) पैकेज को fresh=true चिह्नित किया गया है।

ऐसा लगता है कि कुछ आदेशों के साथ (जैसे upgrade और remove ), force ध्वज "केवल मामले में" सही पर सेट है। यह ध्वज "यदि वे बदल गए हैं, तो सभी पैकेजों को फिर से बनाने" का वादा करते हैं, इसलिए यह कुछ परिवर्तन का पता लगाने वाले कोड में जोड़ने का कोई मतलब नहीं है क्योंकि यह वादा तोड़ देगा।

तो इसे ठीक करने के लिए, ऐसा लगता है कि हमें कोड में विभिन्न स्थानों की धारणाओं को चुनौती देने की आवश्यकता होगी जो force=true ।

जब मैंने yarn upgrade whatever चल रहा था, तो पहला ट्रैक किया था। यह शुरू की गई थी में इस प्रतिबद्ध @juanca द्वारा # 2780 के भाग के रूप। प्रतिबद्ध नोट्स कहते हैं:

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

शायद @ संझा या कोई और जो यार्न के इतिहास से परिचित है, इस समस्या को हल कर सकता है?

nfarina 7 नव॰ 2017

👍9

@nfarina धन्यवाद, कि स्पष्टता लाता है। उन्नयन के लिए, शायद हम वास्तव में देशी पैकेजों को बलपूर्वक बनाना चाहते हैं (यदि वे उन्नत किए जा रहे हैं)। लेकिन इंस्‍टॉल (यार्न एड) के लिए, मैं कहूंगा कि हमें वैध रूप से चुनौती देने की जरूरत है, जैसा कि आपने कहा, यह धारणा जो पहले से स्‍थापित देशी पैकेज को पुन: स्‍थापित करती है जब कुछ और स्‍थापित होता है।

yawaramin 7 नव॰ 2017

👍2

मुझे लगता है कि force झंडा सेट किया गया है ताकि यार्न रिज़ॉल्वर मौजूदा निर्भरता को छोड़ न दे क्योंकि पुराना संस्करण यार्न में है।

मुझे लगता है कि उन्नयन कार्य करने के लिए यह एक त्वरित समाधान था।
एक उचित तरीका एक और ध्वज को पारित करना होगा जो केवल निर्दिष्ट पैकेजों के संकल्प को प्रभावित करता है और force रूप में परमाणु नहीं होगा।
एक पीआर भेजें :)

bestander 13 नव॰ 2017

शायद @ संझा या कोई और जो यार्न के इतिहास से परिचित है, इस समस्या को हल कर सकता है?

सही है, मैं सिर्फ Add API के साथ काम कर रहा था - यह एक मौजूदा पैकेज को जोड़ने पर कुछ नहीं करता है (किया?)।

मैं प्रक्रियात्मक प्रवाह को नियंत्रित करने में एक बेहतर तकनीक का उपयोग करने की भी सलाह देता हूं।

juanca 13 नव॰ 2017

मैं अपने रास्पबेरी पीआई ज़ीरो पर यार्न का उपयोग एक ऐसे प्रोजेक्ट में कर रहा हूं, जिसमें नोड-ओपेंसेव की निर्भरता है। जब भी मैं किसी असंबंधित पैकेज को जोड़ / हटा / अपडेट करता हूं, मुझे पुनर्निर्माण के लिए 35 मिनट इंतजार करना पड़ता है।

Torsten85 4 जन॰ 2018

👍7 😄2 ❤1

@ Torsten85 , मैं इसे पीआई पर भी उपयोग करता हूं, हाँ अनावश्यक पुनर्निर्माण कुछ ऐसी चीज़ है जिससे हमें निपटना होगा।
क्या आप अपने रेकॉर्ड्स के लिए रिप्रो स्क्रिप्ट दे सकते हैं?

bestander 4 जन॰ 2018

👍1

वही यहाँ, 17.10 को जुबां पर, जब मैं यार्न का उपयोग करता हूं, https://github.com/mui-org/material-ui के साथ विकसित करना

हर एक yarn add/remove (-D) <pkg> सब कुछ पुनर्निर्माण करते हैं, एक ताजा इंस्टॉल की तरह, 1 मिनट से अधिक समय लगता है

caub 12 जन॰ 2018

क्या यह है कि npm इसे कैसे संभालता है? यदि यह अस्थायी रूप से स्विच करने के लिए एक संभव समाधान नहीं होगा?

rightaway 21 जन॰ 2018

👎2

यहाँ भी हो रहा है

नोड 9.2.0
यार्न 1.4.0

हर बार जब मैं कुछ निर्भरता जोड़ता हूं, तो हर बार bcrypt या couchbase जैसे मॉड्यूल का पुनर्निर्माण किया जाता है

rkmax 29 जन॰ 2018

👍1

हे सब लोग, मैं एक छोटे से हैक https://github.com/yarnpkg/yarn/pull/5314 पर काम कर रहा हूं
हर समय स्क्रिप्ट स्थापित करने से बचने के लिए एक निर्मित पैकेज को ऑफ़लाइन दर्पण में कैश करने का विचार है।

इसलिए यदि आप ऑफ़लाइन-दर्पण का उपयोग करते हैं और yarn add node-sass चलाते हैं:

यार्न हमेशा की तरह नोड-एसएएस का निर्माण और स्थापित करेगा,
इंस्टॉल स्क्रिप्ट चलने के बाद यह संशोधित node_modules/node-sass फ़ोल्डर से node-sass-v4.7.2-darwin-x64-57.tgz उत्पन्न करेगा
अगली बार जब आप एक ही प्लेटफ़ॉर्म पर yarn install चलाते हैं तो यह मूल के बजाय node-sass-v4.7.2-darwin-x64-57.tgz अनपैक करेगा और इंस्टॉल स्क्रिप्ट नहीं चलाएगा

यह हर मामले के लिए काम नहीं करेगा, लेकिन यह ऑफ़लाइन CI सिस्टम के लिए एक समाधान हो सकता है जिसमें आप पैकेज को इंटरनेट तक पहुंचाना नहीं चाहते हैं और हर बार एक ही इंस्टॉल स्क्रिप्ट चला सकते हैं।

bestander 4 फ़र॰ 2018

❤2 👍1

मैं वैश्विक पैकेज के रूप में टाइपस्क्रिप्ट स्थापित करने की कोशिश कर रहा हूं, और यार्न हर समय पुनर्निर्माण सामान स्थापित करने के बजाय खर्च करता है जो मुझे वास्तव में अब चाहिए।

मैं यार्न के लिए सोच रहा था कि यह तेजी से, और बेहतर है। मैंने npm के किसी भी निशान को हटा दिया (नोड स्थापना के साथ जो आता है) को छोड़कर; और यार्न के लिए सभी वैश्विक पैकेजों को फिर से स्थापित किया।

यार्न अब मुझे साधारण पैकेज इंस्टॉलेशन के लिए 1-15 मिनट की प्रतीक्षा करके मेरे धैर्य का परीक्षण कर रहा है। यार्न को स्थापित करने के लिए पर्याप्त होशियार होना चाहिए कि अन्य सामान के पुनर्निर्माण से पहले क्या अनुरोध किया जाए जब तक कि अनुरोधित पैकेज स्पष्ट रूप से किसी भी देशी पैकेज पर निर्भर न हो, जिसे पुनर्निर्माण की आवश्यकता हो।

वातावरण:

नोड: 9.4.0
यार्न (वैश्विक): 1.3.2
macOS सिएरा: 10.12.6
मैकबुक प्रो 15 इंच
- मेमोरी: 16 जीबी
- CPU: 2GHz - Intel Core i7
- भंडारण: जादुई (बहुत सारी खाली जगह)
- स्थापना के समय चलने वाले ऐप्स: फ़ायरफ़ॉक्स (6 टैब), Mail.app और iTerm (2 टैब के साथ)

लॉग्स

पैकेज लाने में बहुत समय लगता है

यार्न ग्लोबल अपग्रेड टाइपस्क्रिप्ट
यार्न वैश्विक v1.3.2
[१/४] packages पैकेजों को हल करना ...
[2/4] ... पैकेज लाए जा रहे हैं ...
[################################################# ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] ६ /३ / 2166

जोड़ना निर्भरता मिनटों के लिए बिना किसी प्रगति के अटकी हुई है

यार्न ग्लोबल अपग्रेड टाइपस्क्रिप्ट
यार्न वैश्विक v1.3.2
[१/४] packages पैकेजों को हल करना ...
[2/4] ... पैकेज लाए जा रहे हैं ...
[३/४] 🔗 निर्भरता को जोड़ना ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

सभी पैकेजों को फिर से बनाना - बहुत समय लगता है

यार्न ग्लोबल अपग्रेड टाइपस्क्रिप्ट
यार्न वैश्विक v1.3.2
[१/४] 🔍 पैकेजों को हल करना ...
[2/4] ... पैकेज लाए जा रहे हैं ...
[३/४] 🔗 निर्भरता को जोड़ना ...
[४/४] 📃 सभी पैकेजों का पुनर्निर्माण ...
[१२/१⠐] ⠐ वेबसैट
[२/१cc] o एक्सप्रेसो: ISO C99 को स्वीकार करने के लिए gcc विकल्प की जाँच ...
[[/१⠐] port सीरियलपोर्ट: नोड@9.4.0 का उपयोग करना | डार्विन | 64
[६/१⠐]: अब:> स्रोत कोड के लिए, देखें: https://github.com/zeit/now-li

यार्न ग्लोबल अपग्रेड टाइपस्क्रिप्ट
यार्न वैश्विक v1.3.2
[१/४] packages पैकेजों को हल करना ...
[2/4] ... पैकेज लाए जा रहे हैं ...
[3/4] encies निर्भरता को जोड़ना ...
[१३/१⠈] ⠈ सर्वरहित
[१३/१⠂] ⠂ सर्वरहित
[१४/१⠠] ⠠ सॉलग्राफ
[१४/१⠁] ⠁ सॉलग्राफ
[१४/१⡀] ⡀ सॉलग्राफ
[- / १ 17] ⠈ प्रतीक्षा ...
[- / १ 17] ⠄ प्रतीक्षा ...
[- / १ 17] ⠠ प्रतीक्षा ...
[- / १ 17] ⠈ प्रतीक्षा ...
[- / १ 17] ⠄ प्रतीक्षा ...
[- / १ 17] ⢀ प्रतीक्षा ...
[- / १ 17] ⠈ प्रतीक्षा ...

मैं प्रतीक्षा में हूं :-)

abdul 5 फ़र॰ 2018

👍3

एक और दुष्परिणाम यह है कि लाइब्रेरियाँ जो डाउनलोड करती हैं और कैशे precompiles भी मिट जाती हैं और उन्हें फिर से डाउनलोड करना पड़ता है: अर्थात् nwjs-builder-phoenix का कैश ऑफ़ बिल्ड-टारगेट sdks

MeirionHughes 8 फ़र॰ 2018

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

क्या यार्न npm की तरह ग्लोबल को बाइनरी कैश करता है?

snowyu 13 फ़र॰ 2018

यह मुझे थोड़ा सा सरल स्थापना में nwjs पुनर्निर्माण करने के लिए शुरू होता है। कुछ समझ नहीं आया

LuisHCK 14 फ़र॰ 2018

मैं यह भी देख रहा हूँ। हर बार जब मैं एक ऐड / रिमूव ऑपरेशन करता हूं, तो uws को फिर से बनाया जाता है। यार्न v1.3.2

Spongman 16 फ़र॰ 2018

हाय @ एस्बेस्टेंडर। हमने अपनी कंपनी के मोनोरपो पर # 5314 की कोशिश की है, हालांकि हमारे लिए कुछ निर्भरता के पुनर्वित्त को रोकने पर इसका कोई प्रभाव नहीं पड़ा। हमने yarn-offline-mirror और pack-built-packages .yarnrc को सक्षम किया है जैसा कि जोड़े गए परीक्षणों में दिखाया गया है।

क्रूक्स यह है कि yarn चलना हमेशा हमारे लिए लगभग 40-50 सेकंड लेता है, भले ही हम जिस कमांड को पहले सीधे चलाते थे वह yarn भी था।

bbrzoska 19 फ़र॰ 2018

👍2

@ bazyli-brzoska, मैंने ध्वज को अधिक स्पष्ट होने के लिए बदल दिया है और विवरण को अपडेट करना भूल गया।
क्या आप ध्वज experimental-pack-script-packages-in-mirror "सत्य" के रूप में सेट करके देख सकते हैं?

bestander 21 फ़र॰ 2018

क्या इस पर कोई प्रगति हुई है? मैं देखता हूं कि पुल अनुरोध पहले ही विलय हो गया है और यह नवीनतम रिलीज 1.5.1 में है। मैं 1.5.1 पर हूं और मेरे लिए कुछ नहीं बदला। फिर भी, मैं npm पर वापस जाने पर विचार कर रहा हूं, क्योंकि 322.70s या 282.69s या 683.41s (ये वास्तव में मेरे अंतिम तीन yarn add s हैं) एक छोटा रोलअप प्लगइन या लॉश या अच्छी तरह से स्थापित करना, बहुत कुछ भी, बस पागल है।

यह बहुत अच्छा होगा अगर इन जैसे प्रमुख चेतावनी आपके README.md पर होगी। उपयोगकर्ता यार्न को स्थापित करते हैं क्योंकि यह कथित रूप से "तेज" है और npm से यार्न तक यह संक्रमण बनाना एक छोटा कदम नहीं है, इसलिए यह अच्छा होगा यदि डेवलपर्स के लिए कोई अग्रिम चेतावनी थी, इसलिए वे परिवर्तित करने से पहले इसके बारे में एक बार और सोच सकते हैं उनकी स्क्रिप्ट, उनके ग्लोबल्स को प्रदूषित करना और यार्न क्ली को सीखना।

मुझे लगा कि यह सिर्फ मेरी पुरानी 32 बिट मशीन के साथ एक समस्या है, लेकिन 237 वीं बार ऐसा होने के बाद, मैंने इसे देखा और ओह, यार्न अभी तेज नहीं है। महान।

शायद मतलब होने के लिए क्षमा करें, लेकिन मुझे लगता है कि आपको निराशा मिलती है।

nnmrts 28 फ़र॰ 2018

👍1

हम योगदान स्वीकार करते हैं।

कहा जा रहा है, कुछ ऐसे पैकेजों के बारे में ध्यान में रखना चाहिए जो तब बनाए जाते हैं जब उन्हें "आवश्यकता" की आवश्यकता नहीं होती है: निर्भरता स्थापित होने के बाद निर्माण चरणों को निष्पादित किया जाता है। मतलब यह है कि बिल्ड स्क्रिप्ट को उन निर्भरता का उपयोग करने की अनुमति है। इसका मतलब यह है कि अगर ये निर्भरताएँ किसी भी कारण से बदल जाती हैं (जो 'बेतरतीब ढंग से' हो सकती है, उदाहरण के लिए यदि हमने पैकेज के दो संगत संस्करणों को एक में अनुकूलित किया है), तो हमें वास्तव में बिल्ड चरणों को फिर से चलाने की आवश्यकता है, भले ही वे निर्भरता वास्तव में न हों। निर्माण के दौरान उपयोग किया जाता है (क्योंकि हम कैसे जान सकते हैं?)।

तो यह बिल्कुल आसान समस्या नहीं है। मुद्दे का कम से कम हिस्सा पैकेज से आता है। डिजाइन ही डिजाइन। मुझे निराशा के बारे में बताओ 🙂

arcanis 28 फ़र॰ 2018

@arcanis मुझे यह हिस्सा नहीं मिला:

यहां तक कि अगर उन निर्भरताओं का उपयोग वास्तव में निर्माण के दौरान नहीं किया जाता है (क्योंकि हम कैसे जान सकते हैं?)।

मुझे लगा कि YARN डिजाइन स्थिर निर्भरता + संस्करण (यार्न-लॉक) रखने के लिए था और इसलिए कोई यादृच्छिक "अपडेट" नहीं होगा।
हालांकि, पैकेज जोंस एक पूर्ण पेड़ देता है, तो आप क्यों कहते हैं "हम कैसे जान सकते हैं"? एक बार जब पेड़ को हल किया जाता है, तो यह कहना आसान है, अगर कोई निर्भरता (यहां तक कि गहरे स्तर के) एक्स को बदलने या नहीं बनाने के लिए।

Rulikkk 28 फ़र॰ 2018

मान लें कि मेरे पास एक निर्भरता foo जो babel-core और left-pad@^1.0.0 पर निर्भर करती है, और यह कि foo निर्भरता में एक बिल्ड स्क्रिप्ट होती है जो अपनी अनुक्रमणिका फ़ाइल पर बेबल चलाता है ।

मेरे प्रोजेक्ट फ़ोल्डर में yarn add foo चलने के बाद, मैं [email protected] नोड_मॉड्यूल्स में रखता हूं, सही? अब मान लीजिए कि एक नया लेफ्ट-पैड संस्करण जारी किया गया है ( 1.1.0 ), और मैं इसे अपने प्रोजेक्ट में उपयोग करना चाहता हूं। मैं yarn add left-pad , जो बाद में latest , यानी 1.1.0 हल हो जाएगा।

अब क्या हो सकता है कि यार्न "देख" करेगा कि पेड़ में बाएं-पैड की दो प्रतियां हैं, और यह भी देखेंगे कि उन्हें अनुकूलित किया जा सकता है: आखिरकार, foo left-pad@^1.0.0 पर निर्भर करता है 1.1.0 भी संगत है। तो यह पिछले संस्करण को हटा देगा, और केवल 1.1.0 । क्योंकि निर्भरता बदल गई है, हमें फिर से बिल्ड स्क्रिप्ट को चलाने की आवश्यकता है क्योंकि यार्न के पास यह जानने का कोई तरीका नहीं है कि left-pad बिल्ड-टाइम निर्भरता के बजाय एक रनटाइम निर्भरता है ।

अब आप पूछ सकते हैं "लेकिन क्यों न केवल पुनर्निर्माण को छोड़ दें जब सकर्मक निर्भरता बदल गई?"। इसका उत्तर यह है कि कुछ पैकेजों (विशेष रूप से देशी पैकेजों) में निर्भरताएं होती हैं जो मौलिक रूप से प्रभावित करती हैं कि वे कैसे निर्मित होती हैं। जब ऐसा होता है, हम वास्तव में, वास्तव में उन पैकेजों का पुनर्निर्माण करना चाहते हैं, या हम असंगत कलाकृतियों के साथ समाप्त हो जाएंगे।

arcanis 28 फ़र॰ 2018

@arcanis , मुझे लगता है कि आप इस मुद्दे को गलत समझते हैं। यहाँ समस्या यह है कि इन मूल पैकेजों को फिर से बनाया जा रहा है _every_ समय, तब भी जब yarn त्वरित उत्तराधिकार में दो बार (या अधिक) चलाए जाते हैं। इसमें _nothing_ निर्भरता को अद्यतन करने के साथ है - यह _always_ rebuilds है।

Spongman 28 फ़र॰ 2018

👍4

@Spongman मैं आपकी नवीनतम टिप्पणी से सहमत हूं। लेकिन जैसा कि @Spongman ने सही उल्लेख किया है, पुनर्निर्माण हर बार होता है । यहां तक कि अगर आप सिर्फ yarn && yarn - तो आपको दो पूर्ण पुनर्निर्माण मिलते हैं , इस तथ्य के बावजूद कि निर्भरता संरचना में कुछ भी नहीं बदला।

Rulikkk 28 फ़र॰ 2018

👍3

मैंने ओपी में yarn add leveldown bcrypt && yarn && yarn चलाने की कोशिश की और केवल एक निर्माण किया: / क्या आपके पास एक कमांड है जिसे मैं इस व्यवहार को रद्द करने के लिए उपयोग कर सकता हूं?

arcanis 28 फ़र॰ 2018

आप उदाहरण के लिए कोशिश कर सकते हैं:

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 के अंतर्गत है)

JesperWe 28 फ़र॰ 2018

👍1

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

yarn & yarn

दो पुनर्निर्माण का कारण नहीं है, लेकिन सॉकेट के साथ उदाहरण ।io, प्रतिक्रिया को जोड़ने, प्रतिक्रिया को हटाने से दो पुनर्निर्माण हो रहे हैं

billxinli 28 फ़र॰ 2018

मैंने यार्न v1.5.1 के साथ सॉकेट.आईओ उदाहरण की कोशिश की और देशी बिल्ड को कैश करने के लिए नई सुविधा का उपयोग करते समय पुन: प्राप्त नहीं किया। ऐसा करने के लिए आपको ऑफ़लाइन कैश का उपयोग करना होगा। मेरे ~/.yarnrc मेरे पास है:

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

जब मैं उस कॉन्फ़िगरेशन के बिना किसी अन्य उपयोगकर्ता के रूप में प्रयास करता हूं, तो यह हर बार फिर भी पुनर्निर्मित होता है।

skomorokh 28 फ़र॰ 2018

हां, इन विकल्पों को जोड़ने पर अब कोई पुनर्निर्माण नहीं होता है।
लेकिन अगर केवल experimental-pack-script-packages-in-mirror true , यह अभी भी पुनर्निर्मित करता है।
क्यों "~ / .yarn / cache" जैसे डिफ़ॉल्ट पथ पर yarn-offline-mirror सेट न करें।

snowyu 1 मार्च 2018

फिर भी प्रायोगिक, लेकिन यह एक दिलचस्प सुझाव है (cc @bestander)। मुझे लगता है कि मेरे पास यह मुद्दा है कि मुझे व्यक्तिगत रूप से उपयोगकर्ता की स्पष्ट सहमति के बिना चीजों को सक्षम करने का विचार पसंद नहीं है। इसके अन्य निहितार्थ भी हैं: yarn-offline-mirror सेट से false क्या अर्थ होगा, और experimental-pack-script-packages-in-mirror से true ? क्या experimental-pack-script-packages-in-mirror yarn-offline-mirror सेटिंग को अधिलेखित करना चाहिए? थोडा भ्रमित करने वाला imo।

किया जा रहा है ने कहा कि, पुनर्निर्माण की बग uws को जोड़ते समय left-pad वास्तव में थोड़े परेशान है, और experimental-pack-script-packages-in-mirror सेटिंग केवल किसी समाधान नहीं है। मुझे यकीन नहीं है कि मेरे पास अगले हफ्ते या तो इसे देखने के लिए बैंडविड्थ होगी, लेकिन अगर किसी को एक भूमि को खरीदने के लिए दिलचस्पी है तो यह बहुत प्रभावी होगा।

arcanis 1 मार्च 2018

👍1

@arcanis इस तरह की प्रतिक्रिया के लिए धन्यवाद। यार्न प्रस्तुत करने के तरीके से निराशा उत्पन्न होती है। फिलहाल यह सिर्फ "तेज" नहीं है, निश्चित रूप से वास्तविक दुनिया की परियोजनाओं में एनपीएम और थोड़े अनुपयोगी से तेज नहीं है। Imho, इस बारे में एक जानकारी होनी चाहिए या यहां तक कि @ README.md फ़ाइल में

मैं उसी हताशा को महसूस करूंगा, अगर एंगुलरज रेपो की रीडमी बताएगी कि यह एक हल्का ढांचा है। यह सिर्फ नहीं है।

nnmrts 1 मार्च 2018

यह हमेशा yarn-offline-mirror कॉन्फ़िगरेशन के बाद बाइनरी फ़ाइल डाउनलोड करने के लिए दोहराता है।

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

snowyu 2 मार्च 2018

आज थोड़ा इस में डिबग करने की कोशिश करने जा रहे हैं। मुझे लगता है कि यह वास्तव में PackageInstallScripts pkg.fresh जाँच न करके केवल नए स्थापित पैकेजों के पुनर्निर्माण के रूप में सरल हो सकता है। इसके बजाय ऐसा लगता है कि यह उन सभी पर सिर्फ लूपिंग है।

rally25rs 2 मार्च 2018

🎉3 👍1

चारों ओर कुछ गड़बड़ होने के बाद, मैं यह सोचना शुरू कर रहा हूं कि हम हर समय उन चीजों का पुनर्निर्माण करते हैं जो 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 होने पर एक पुनर्निर्माण होना चाहिए

इसलिए यह मेरे विचार से थोड़ा अधिक शामिल है।

rally25rs 2 मार्च 2018

मेरे पास अप-टू-डेट प्रतिक्रिया ऐप में yarn add ed moment , एक शून्य निर्भरता पैकेज है, इसमें 377.97s लगते हैं।

क्या इसके ठीक बाद फिर से, इसने 389.63s और फिर से बायनेरिज़ को फिर से बनाया।

तुलना के लिए, मैंने तब नोड_मॉड्यूल हटा दिया और npm install :
added 1751 packages and updated 124 packages in 360.595s

अब वापस npm पर स्विच किया गया।

nnmrts 3 मार्च 2018

ठीक है, इस मुद्दे पर सभी आंखों के लिए कुछ और जानकारी ... मैं एक और डेढ़ दिन के लिए इस चीज के साथ खिलवाड़ कर रहा हूं और आखिरकार कुछ चीजों का एहसास हुआ।

सबसे पहले, इन पुनर्निर्माण समस्याओं में से अधिकांश तय हो गई हैं। 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 साल के लिए ऐसा है) इसलिए rebuilds हमेशा होते हैं।

हालाँकि, यह यकीनन "सही" है क्योंकि यह वही है जो 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

यार्न एक फ़ाइल देखता है जो कैश की तुलना में "बदल गया" है इसलिए पैकेज को फिर से स्थापना के लिए "ताज़ा" चिह्नित करता है

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

उम्मीद है कि यहाँ कुछ मामलों की व्याख्या की गई है जहाँ कुछ लोग कहते हैं कि यह काम करता है और अन्य कहते हैं कि यह नहीं है।

rally25rs 4 मार्च 2018

👍9 ❤3

वहाँ गहरा गोता लगाने के लिए धन्यवाद, @ rally25rs।

हटाएं कमांड में force का उपयोग करते हुए।
यह स्पष्ट रूप से एक त्वरित कट कॉर्नर बग फिक्स था जिसने परमाणु दृष्टिकोण IIRC https://github.com/yarnpkg/yarn/pull/323 के साथ शुद्धता प्राप्त की
force को निकालना मुश्किल नहीं होना चाहिए और मुद्दे के आसपास काम करना चाहिए।
node_modules/uws/uws_darwin_57.node : यह फ़ाइल artifacts .yarn-integrity फ़ील्ड में होनी चाहिए और फिर लिंकिंग के दौरान uws को नए सिरे से चिह्नित नहीं किया जाना चाहिए।
यहाँ शायद कुछ गड़बड़ है

bestander 4 मार्च 2018

@bestander ah good point on 2. मैं यह देखने की कोशिश करूंगा कि क्या जाँच के लिए कोई समझदार तरीका है।

rally25rs 4 मार्च 2018

stereokai 19 मार्च 2018

@stereokai ऊपर की मेरी टिप्पणी में मैं ध्यान देता हूं कि npm भी अनइंस्टॉल / रिमूव पर संकुल का पुनर्निर्माण करता है, इसलिए यदि आप npm के व्यवहार को मानक मानते हैं तो यह मामला "सही" है।

rally25rs 19 मार्च 2018

@ rally25rs कि बाहर इशारा करने के लिए धन्यवाद :)

हालांकि, मैं पैकेज मैनेजर की परवाह किए बिना इस व्यवहार को छोटी बात मानता हूं। यह समझना मुश्किल है कि सही संचालन के लिए इस तरह का व्यवहार क्यों आवश्यक है। जब आप एप्लिकेशन पहले से ही जोड़ते / हटाते हैं तो आपका OS स्थानीय कार्यक्रमों को पुनर्स्थापित नहीं करता है। मैं एक स्थिर निर्भरता प्रबंधक, nahmean से कुछ और की उम्मीद नहीं है?

stereokai 20 मार्च 2018

👍1

@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 तब नई dep संरचना है:

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 स्थापित है (वास्तव में मुझे यह परीक्षण करना चाहिए कि मेरे PR yarn add पर पुनर्निर्माण न करें वास्तव में इस मामले में काम करते हैं)

मुझे संदेह है कि क्यों इन पैकेजों को हर बार फिर से बनाया जाता है।

इस कमिटमेंट में वास्तविक परिवर्तन हुआ: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
2016 में वापस। उस समय फ़ाइल को uninstall.js का नाम दिया गया था, लेकिन force: true को install पास किए गए झंडे में जोड़ा गया था। _Why_ को इंगित करने के लिए प्रतिबद्ध टिप्पणी में कुछ भी विशिष्ट प्रतीत नहीं होता है।

rally25rs 20 मार्च 2018

👍2

अगर कम से कम _some_ मामलों में पुनर्निर्माण से बचने का एक तरीका है, तो भयानक होगा।

lydell 20 मार्च 2018

👍1

किसी का भी पीआर पर काम करने के लिए स्वागत है। 😸एज़ मैंने ऊपर बताया, पहले से ही yarn install और yarn add (ज्यादातर मामलों में) पर नहीं होता है। मेरे पास # 5470 खुला है जो yarn add लिए अनावश्यक रूप से पुनर्निर्मितियों को समाप्त कर देना चाहिए जब आपके पास uws निर्भरता में yarn remove ।

rally25rs 20 मार्च 2018

👍3

इस सूत्र को अधिकांश पढ़ने के बाद, मुझे समझ नहीं आया कि यहाँ क्या हो रहा है।

मेरे पास कई देशी पैकेज हैं जिन्हें मैं हर बार yarn add किसी अन्य (असंबंधित) मॉड्यूल के लिए फिर से बनाता हूं। मेरे लैपटॉप पर CPU पर बहुत अधिक लोड होने में लगभग 20 मिनट लगते हैं। मैं बस उस तरह से काम नहीं कर सकता।

जाहिर है, इस धागे से, यह 19 महीनों के लिए एक मुद्दा रहा है।

यह एक बग है? क्या इस पर काम किया जा रहा है? क्या आसपास कोई काम है? क्या मुझे npm पर वापस जाना चाहिए?

vibl 26 मार्च 2018

👍1

क्या मुझे npm पर वापस जाना चाहिए?

हां, जब तक # 5470 जारी नहीं किया जाता।

Spongman 26 मार्च 2018

@vibl

जाहिर है, इस धागे से, यह 19 महीनों के लिए एक मुद्दा रहा है।

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

यह एक बग है?

शायद। कौन से पैकेज पुनर्निर्माण कर रहे हैं? केवल एक ही मुझे पता है कि एक निरंतर मुद्दा रहा है uws , इसलिए अधिक के बारे में जानना मददगार होगा।

क्या इस पर काम किया जा रहा है?

ऊपर उल्लेखित विशिष्ट मामला # 5470 में तय किया गया है

क्या आसपास कोई काम है?

यदि आप जो पैकेज जोड़ रहे हैं, उसमें कोई इंस्टॉल स्क्रिप्ट नहीं है, तो आप --ignore-scripts उपयोग कर सकते हैं

या, आप उपरोक्त पीआर से शाखा की जांच कर सकते हैं और इसका उपयोग कर सकते हैं।

इसमें लगभग 20 मिनट लगते हैं

वाह। मैं उत्सुक हूं कि वह कौन सा पैकेज है।

rally25rs 26 मार्च 2018

जवाब के लिए धन्यवाद।

पैकेज noise-search , level-rocksdb और jq हर बार जब मैं yarn add साथ किसी भी असंबंधित पैकेज को जोड़ता हूं। मेरा लैपटॉप थोड़ा पुराना है, इसलिए उन्हें एक ही समय में संकलित करने में बहुत लंबा समय लगता है।

मैंने यार्न 1.5.1 और नोड 9.8.0 का उपयोग किया।

vibl 26 मार्च 2018

@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 से अधिक मिनट over

वैसे भी, मैंने noise-search स्थापित किया, फिर # 5470 के कोड के साथ yarn add left-pad भाग लिया और इसने _not_ को फिर से बनाया, इसलिए मुझे लगता है कि एक बार जब हम विलय कर देते हैं तो आपको अच्छा होना चाहिए

rally25rs 26 मार्च 2018

धन्यवाद :-)

क्या मुझे कुछ दिनों, कुछ हफ्तों या कुछ महीनों में यार्न पर वापस जाँच करनी चाहिए?

vibl 26 मार्च 2018

मुझे अभी पता चला है कि एक ही लैपटॉप (डुअल बूट) पर एक ही सटीक प्रोजेक्ट के साथ यह बग विंडोज 10. पर नहीं होता है, लेकिन यह नवीनतम तीन डेबियन संस्करणों, उबंटू, आर्क लिनक्स और फेडोरा में है। अजीब। अभी तक MacOS की कोशिश नहीं की, लेकिन ऐसा लगता है कि कुछ लोगों को वहाँ भी समस्या है।

nnmrts 27 मार्च 2018

@vibl मुझे यकीन नहीं है कि हमारी अगली रिलीज़ कब होगी (मैं उस योजना में शामिल नहीं हूं)

@nnmrts हाँ मुझे पता चला कि यह एक ओएस विशिष्ट बात है। # 5470 में मेरी टिप्पणियों से:

नोड 8 के साथ लिनक्स पर, जब फ़ाइलों को कैश से नोड_मॉड्यूल्स में कॉपी किया जाता है, टाइमस्टैम्प अपडेट किए जाते हैं। यार्न तय करता है कि फाइलें अलग-अलग हैं और संदर्भ को ताज़ा करती हैं।
यह केवल लिनक्स नोड 8 पर ही लगता है।
ऐसा इसलिए है क्योंकि Node v8.5 ने fs.copyFile की शुरुआत की, जिससे प्रतियां बहुत तेज़ी से बढ़ीं। IIRC जो मूल फाइलसिस्टम कॉपी की ओर जाता है, ताकि यह समझा सके कि यह OS पर और केवल नोड 8 में अलग तरह से काम करता है।

rally25rs 27 मार्च 2018

👍1

@ rally25rs @nnmrts यह सबसे निश्चित रूप से एक MacOS विशिष्ट बात नहीं है। मेरे Win10 पीसी पर भी होता है

stereokai 28 मार्च 2018

@stereokai खैर, यह पूरा मुद्दा विशिष्ट नहीं है। कभी-कभी पैकेजों को फिर से बनाने की आवश्यकता होती है और लोग अभी भी सोचते हैं कि यह एक बग है और इसे यहां पोस्ट करें। प्रत्येक ओएस के लिए एक ठोस प्रतिलिपि प्रस्तुत करने योग्य रेपो के बिना, हम कुछ भी नहीं जान सकते हैं।

nnmrts 28 मार्च 2018

स्थानीय रूप से निर्मित मॉड्यूल (# 5314 से) कैशिंग मदद कर सकता है?

निम्नलिखित के साथ अपनी परियोजना में .yarnrc जोड़ें:

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

पहली स्थापना के बाद, प्रीबिल्ट मॉड्यूल ./<your-offline-mirror-path>/prebuilt में रहेंगे। yarn.lock भी w / prebuilt वेरिएंट अपडेट किया गया है

नवीनतम 66a0143a753cd4ade1a0fffee2174890d564c129 खींचे, और यह ठीक से काम करता प्रतीत होता है

theandrewlane 28 मार्च 2018

अभी भी बाइनरी को दोहराने के लिए डाउनलोड करें।

नोड v6.13.1
यार्न v1.6.0-20180327.1507
ओएस: उबंटू 17.10 लिनक्स 4.13.7-041307-जेनेरिक
~ / .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

Thu, Mar 29, 2018 को 2:30 पूर्वाह्न, एंड्रयू लेन सूचनाएँ @ithub.com
लिखा था:

स्थानीय रूप से कैशिंग निर्मित मॉड्यूल (# 5314 से)
https://github.com/yarnpkg/yarn/pull/5314 ) मदद कर सकता है ?:
निम्नलिखित के साथ अपने प्रोजेक्ट में .yarnrc जोड़ें:
यार्न-ऑफलाइन-मिरर "।""
प्रायोगिक-पैक-स्क्रिप्ट-पैकेज-इन-मिरर सच
पहली स्थापना के बाद, प्रीबिल्ट मॉड्यूल में रहेंगे
.// पहले से बनाए गए। यार्न .लॉक भी अपडेट किया गया है
w / पूर्वनिर्मित संस्करण
नवीनतम 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 29 मार्च 2018

@snowyu क्या आपने यार्न ,लॉक, नोड_मॉड्यूल और yarn cache clean हटा दिए? करता है ।/yarn-offline-mirror/prebuilt को पॉपुलेटेड पोस्ट इंस्टॉल मिलता है?

theandrewlane 29 मार्च 2018

यह अस्थायी में एक नई परियोजना है। हां, मैं कैश फ़ोल्डर में node-sass-4.8.3.tgz फ़ाइल देख सकता हूं।
अब, मैं yarn cache clean चलाता हूं। लेकिन अभी भी बाइनरी को दोहराएं * ।

`` `बैश

यार्न init -y
यार्न नोड-एसएएस जोड़ें
यार्न जोड़ें v1.6.0-20180327.1507
जानकारी कोई ताला नहीं मिला।
[१/४] संकल्प पैकेज ...
[2/4] पैकेज लाए जा रहे हैं ...
[३/४] निर्भरता को जोड़ना ...
[४/४] बिल्डिंग ताज़ा पैकेज ... https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node से बाइनरी डाउनलोड करना
सफलता ताला लगा हुआ है।
सफलता 152 नई निर्भरताओं को बचाया।
11.98 के दशक में किया गया।

यार्न नोड-एसएएस जोड़ें
यार्न जोड़ें v1.6.0-20180327.1507
[१/४] संकल्प पैकेज ...
[2/4] पैकेज लाए जा रहे हैं ...
[३/४] निर्भरता को जोड़ना ...
[४/४] बिल्डिंग ताज़ा पैकेज ... https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node से बाइनरी डाउनलोड करना
सफलता ताला लगा हुआ है।
सफलता ने 1 नई निर्भरता को बचाया।
जानकारी प्रत्यक्ष निर्भरता
└─ नोड- [email protected]
सभी निर्भरताएं
Ass नोड- [email protected]
13.45 के दशक में किया गया।
``

snowyu 29 मार्च 2018

ठीक है, मैंने इस बग को पुन: पेश करने के लिए सरल गिट रेपो किया।

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

जब मैं शून्य-निर्भरता left-pad जोड़ने का प्रयास करता हूं तो यार्न अनावश्यक ttf2woff2 प्रदर्शन करते हैं

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 छवि के साथ इसे पुन: उत्पन्न कर सकता हूं

एनपीएम इस मामले में सही ढंग से काम करता है:

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 29 मार्च 2018

@vlmonk अभी भी होता है यदि आप @ rally25rs से https://github.com/rally25rs/yarn क्लोन करते हैं और # 5470 (शाखा fix-linking-rebuilding-uws-932 ) में कोड का उपयोग करते हैं?

karlhorky 29 मार्च 2018

@karlhorky हाँ, यार्न अभी भी पुनर्निर्माण ttf2woff2 जोड़ने के बाद left-pad

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

vlmonk 29 मार्च 2018

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 में वास्तव में वे फाइलें हैं।

sth 30 मार्च 2018

👍1

हम इसे ओएस एक्स के साथ भी देखते हैं, yarn add साथ किसी भी पैकेज को जोड़ने से किसी भी आश्रित पैकेज का एक recompile ट्रिगर होता है। हमारे पास मूल कोड के साथ एक नोड-जिप पैकेज है, प्रत्येक बार एक और पैकेज जोड़े जाने में 1 मिनट का समय लग रहा है, और देशी मॉड्यूल में बहुत अधिक कोड नहीं है (यह बहुत खराब हो जाएगा)। यह यार्न 1.5.1 के साथ है।

हम yarn add ../a का उपयोग रिश्तेदार पथों के साथ कर रहे हैं यदि इससे कोई फर्क पड़ता है।

कृपया मुझे बताएं कि क्या कोई वर्कअराउंड हैं, या जब यह तय हो जाएगा।

cisaacson 15 अप्रैल 2018

यह यार्न 1.5.1 के साथ है।

यह मुद्दा 1.6.0 में तय किया गया था जो हाल ही में समाप्त हुआ है।

BYK 16 अप्रैल 2018

👍2

मैं अभी भी 1.6 के साथ इसे देखता हूं। चूँकि npm yarn बहुत पहले से uws हमेशा (या कम से कम yarn uws पर अटक गया है। लगभग 5-10 सेकंड)।

प्रजनन करने कि प्रक्रिया:

$ यार्न पुराना
एक पुराना पैकेज चुनें
$ यार्न उन्नयन [पैकेज]

grantila 16 अप्रैल 2018

👍5

@grantila आप यार्न 1.6.0 साथ इसे पुन: उत्पन्न करने वाले चरणों के साथ एक पूर्ण package.json या रेपो प्रदान कर सकते हैं?

karlhorky 16 अप्रैल 2018

यह अभी भी 1.6.0 पर हो रहा है

आप इसे इस https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784 का उपयोग करके पुनः प्राप्त कर सकते हैं

sibelius 25 अप्रैल 2018

👍1

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

"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 का समय लगा!

संपादित करें: डेबियन स्ट्रेच पर नोड 8.11.1 और यार्न 1.6.0 का उपयोग करना।

brenc 29 अप्रैल 2018

@arcanis @ rally25rs की याचिका इस मुद्दे को फिर से

stereokai 30 अप्रैल 2018

👍2

मुझे लगता है कि यह एक @ rally25rs मुद्दा अधिक है :)

BYK 30 अप्रैल 2018

@grantila एक upgrade _always_ सभी का पुनर्निर्माण करेगा। यह जानबूझकर किया गया है। npm एक ही बात करता है (मैं इस टिप्पणी में इस लंबे धागे में कहीं उल्लेख करता हूं।) हालांकि हम संभवतः ऐसा करने से रोकने की कोशिश कर सकते हैं। मुझे यकीन नहीं है कि इसके क्या परिणाम हो सकते हैं।

के सिवाय प्रत्येक:

# 5680 में मैं इंगित करता हूं कि यह अभी भी होता है अगर कोई पैकेज अपनी फ़ाइलों को हटा देता है _ (क्यों ओह, वे ये काम क्यों करते हैं point) _ और यार्न ट्रैक नहीं करते हैं कि कहीं भी (हम ट्रैक करते हैं कि क्या फाइलें बनाई या संशोधित की जाती हैं), इसलिए यह सिर्फ सोचता है कि पैकेज फाइलों को याद कर रहा है और इसे फिर से बनाता है।

मुझे लगता है कि हम इसे फिर से खोल सकते हैं, लेकिन यह ज्यादातर पैकेजों के लिए तय किया गया है। अगर कोई इसमें "मुझे भी" जोड़ना चाहता है, तो _please_ या तो अपना पैकेज प्रदान करें। या तो, या विशेष रूप से उल्लेख करें कि कौन सा पैकेज लगातार पुनर्निर्माण कर रहा है, क्योंकि आपके पास कुछ निर्भरताएं हो सकती हैं जो पुनर्निर्माण करती हैं और कुछ जो नहीं करती हैं।

किसी को भी इसके लिए पीआर बनाने का स्वागत है! (# 5680 में मेरी डिबगिंग टिप्पणी देखें)

rally25rs 30 अप्रैल 2018

👍1

अधिक शोर जोड़ने के लिए खेद है, लेकिन मैं इस मुद्दे को लॉक करने और शीर्ष पर इस नवीनतम जानकारी के साथ किसी नए की ओर इशारा करने का सुझाव देना चाहूंगा।

मुझे लगता है कि यहां मुद्दा काफी बदल गया है और कम से कम आंशिक रूप से हल हो गया है। यहां सभी पदों के साथ किसी नए के लिए यह तय करना मुश्किल है कि क्या तय किया गया है और क्या अभी भी एक मुद्दा है।

james-rabbit 30 अप्रैल 2018

👍5

मैं @ जेम्स-खरगोश से सहमत हूं

stereokai 1 मई 2018

हाँ, तुम सही हो। मैं इसे लॉक करने जा रहा हूं ताकि @ rally25rs का उत्तर दिखाई दे।

यदि आपके पास मूल पैकेज के साथ कोई समस्या है:

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

arcanis 1 मई 2018

Yarn: देशी पैकेज हर बार फिर से बनाए जाते हैं

सबसे उपयोगी टिप्पणी

सभी 128 टिप्पणियाँ

संबंधित मुद्दों