yarn 🚀 - 매번 재 구축되는 네이티브 패키지

Mac OSX (10.11.6)에서 재현 할 수 없으므로 Ubuntu 특정 문제 일 수 있습니까?

jkimbo 에 2016년 10월 12일

Windows 10에서 재현 할 수 있지만 한 번만 가능합니다. 두 번째로 "yarn"을 실행했을 때 네이티브 라이브러리를 다시 빌드하지 않았습니다. 이상한.

Daniel15 에 2016년 10월 13일

나는 그것을 좀 더 가지고 놀고 몇 가지 세부 사항을 생각해 냈습니다.

yarn add leveldown bcrypt 하면 leveldown 가 목록의 첫 번째 항목으로 컴파일되고 node_modules/.yarn-integrity 의 해시는 완료되면 595306... (잘라 내기 간결함을 위해; 나는 그것이 무언가를 수행 해야하는지 여부를 결정하는 체크섬이라고 가정합니다). 이제 yarn 다시 실행하면 두 패키지 모두 목록의 첫 번째로 컴파일되는 bcrypt 로 다시 빌드됩니다 (순서는 다름). 결과 체크섬은 cbe480... . 이후 yarn 호출은 패키지를 다시 빌드하지 않으며 체크섬은 동일하게 유지됩니다. 이것은 내 원래 보고서와 모순되지만 (어딘가에서 실수를했을 것입니다) @ Daniel15 가 본 것과 일치합니다.
처음부터 패키지 순서를 바꾸면 ( yarn add bcrypt leveldown ), bcrypt 가 목록에서 첫 번째가되고 결과 체크섬은 즉시 cbe480... 됩니다. 이후에 yarn 를 호출하면 패키지가 다시 빌드되지 않습니다.
bcrypt 패키지는 목록의 위치에 관계없이 항상 먼저 완료됩니다 (컴파일 할 것이 많지 않기 때문에 예상대로).

나는 내부에 전혀 익숙하지 않지만 패키지가 컴파일되는 순서가 중요하며 처음 설치할 때 단순히 정렬되지 않고 나중에 yarn 호출 할 때 정렬되지 않는 것 같습니다. 어떤 방식 으로든 체크섬에 영향을줍니다.

jiripospisil 에 2016년 10월 15일

👍4

조사해 주셔서 감사합니다! 좋은 단서처럼 들립니다. 해시는 https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583에 작성되었습니다. .yarn-integrity 의 해시가 잠금 파일을 기반으로하므로 해당 코드를 디버깅하고 잠금 파일에서 무엇이 다른지 확인하는 것이 좋습니다.

Daniel15 에 2016년 10월 15일

.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

jiripospisil 에 2016년 10월 15일

나는 같은 문제가있다 : 나도 bcrypt를 사용한다. 새 모듈을 설치하거나 기존 모듈을 업그레이드 할 때마다 npm rebuild 를 실행하여 앱을 실행해야합니다.

macOS 10.12 && 노드 v7.0.0 && yarn v0.16.1

hustcer 에 2016년 10월 30일

더 이상 원래 문제를 재현 할 수 없습니다. 수정 된 것 같습니다 : +1 :. @ Daniel15 확인할 수 있습니까?

@hustcer 나는 그것이 같은 문제라고 생각하지 않습니다. 최신 버전으로 테스트하고 여전히 작동하지 않는 경우 새 버그를 제출할 수 있습니다.

jiripospisil 에 2016년 11월 17일

@jiripospisil 감사합니다. yarn v0.17.4로 업그레이드 한 후 이제 괜찮습니다.

hustcer 에 2016년 11월 18일

나는 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 동안 만 발생하지만 Yarn 캐시에서 레벨 다운 또는 왼쪽 패드를 사용하거나 사용하지 않고 일관되게 발생합니다.

$ 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 에 2016년 12월 25일

여전히 발생하므로 다시여십시오.
yarn add redux 하고 bcrypt , node-sass 및 기타 여러 프로그램을 다시 빌드했습니다.

노드 v6.9.4
원사 v0.20.3
윈도우 10

ndraiman 에 2017년 02월 22일

👍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 에 2017년 02월 22일

@jiripospisil 제공 할 복제 단계가 없습니다. 단순히 추가 패키지를 설치하면 실이 모든 것을 연결하고 재 구축합니다.

다음은 하나의 패키지를 추가 한 결과입니다 (잠금 파일이 이미 존재 함).

종속성 연결 :
linking dependencies

재건 :
rebuilding

ndraiman 에 2017년 02월 23일

@jiripospisil 나도 여전히 이것을보고 있지만, 재현하는 동안 레벨 다운 (또는 그 종속성)이 OS X 호환 바이너리를 제공하기 시작했을 수 있기 때문에 설치 시간이 의심스럽게 50 초에서 3 초로 떨어졌습니다. 당신에게 특별히을 OS X에있어, 경우 yarn add [email protected] 대신에 단지 yarn add leveldown 이전과, 당신이 볼 수 같은 동작.

seansfkelley 에 2017년 02월 23일

매번 다시 빌드되는 ttf2woff2 에 대한 간접 종속성이 있습니다.

그러나 yarn.lock 변경 사항이있을 때마다 다시 빌드됩니다. 즉, yarn 새와 yarn.lock , yarn upgrade , yarn upgrade-interactive . yarn upgrade-interactive 경우 devdeps와 일반 dep가 모두 업데이트 된 경우 ttf2woff2 가 두 번 다시 빌드됩니다 (!).

Jessidhia 에 2017년 03월 02일

👍3

위의 단계로 재현 할 수는 없지만이 문제도 표시됩니다. 그러나 다음 단계로 재현 할 수 있습니다.

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

원사 공동 추가
```

다시 레벨 다운을 구축합니다.

내가 어떤 패키지를 추가하는지는 중요하지 않은 것 같습니다. 항상 레벨 다운을 다시 빌드합니다.

Yarn v0.21.3, Windows 10 및 Node v7.7.1을 사용하고 있습니다.

jefftimlin 에 2017년 03월 13일

나는 이것도보고있다. 저는 BuckleScript (bs-platform)를 사용하고 있습니다 ....

jackalcooper 에 2017년 03월 13일

👍6

sharp 에서도이 문제가 발생합니다. yarn add 또는 yarn remove 실행할 때마다 sharp 는 네이티브 패키지가 아닌 경우에도 다시 빌드됩니다.

Windows 10 및 Ubuntu Linux 16.04에서 yarn v0.21.3, Node 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 에 2017년 03월 30일

👍4

bs-platform 에서도 이것을보고 있습니다.

svoynow 에 2017년 04월 19일

👍3

또한 ttf2woff2 로 yarn add 호출 할 때마다이를 경험하면 ttf2woff2 가 1 년 이상 게시되지 않았음에도 불구하고 다시 빌드됩니다.

patrickhulce 에 2017년 04월 20일

👍2

나는 이것도 couchbase와 함께 가지고

편집 : 0.23.2에서 수정 된 것 같습니다.

technicallyfeasible 에 2017년 04월 21일

0.23.2에서 여전히 발생합니다 ( argon2 및 node-sass 종속성이없는 moment 와 같은 관련없는 패키지를 추가 / 제거 할 때마다 다시 빌드됩니다)

운영체제 : Windows 10
노드 : 7.9.0
털실 : 0.23.2

raleksandar 에 2017년 04월 21일

👍2

더 많은 색상을 추가하기 위해 yarn add <some-package> 에서 발생하는 일에 대한 제 인식은 force: true 로 인해 바로 직전에 yarn remove <unrelated-package> 와 (과) 결합하여 실제로 많은 경우가 트리거 되었기 때문에 현실보다 훨씬 컸습니다 force: true 이 줄 에 force: true .

잠금 파일을 생성하기 위해 remove에서 설치 로직을 재사용하는 것이 확실히 편리하지만, 강제 설치의 모든 짐이 함께 제공되지 않았다면 좋을 것입니다. :)

patrickhulce 에 2017년 04월 25일

저에게 이것은 0.23.x로 업그레이드했을 때 다시 시작되었습니다. 0.21.3으로 되 돌렸고 더 이상 매번 빌드되지 않습니다. 또한 이로 인해 몇 개의 패키지를 연속으로 업그레이드 한 후 unicode.org에서 내 IP가 차단되는 문제가 발생했습니다. https://github.com/dodo/node-unicodetable/issues/16

kriscarle 에 2017년 04월 29일

0.21.3은 새 패키지를 추가 할 때 모든 패키지를 다시 빌드하지 않지만 제거 할 때 모든 패키지를 다시 빌드합니다. 그리고 재건이 실패하면 원 사는 실패로 간주하지 않는 것 같습니다.

zhangjyr 에 2017년 05월 03일

👍2

저에게는 0.21.3 다운 그레이드해도 도움이되지 않았습니다. bs-platform 은 (는) 추가 / 제거 할 때마다 다시 작성됩니다.

akxcv 에 2017년 05월 06일

👍2

Yarn 0.23.4를 사용하는 macOS에서 이것을 확인하십시오. yarn add 실행할 때마다 sqlite3 빌드합니다.

$ 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 에 2017년 05월 16일

👍2 👎1

Ubuntu 16.04LTS, 최신 yarn v0.24.6 및 노드 8.1.2에서이 문제 확인

gdal , node-sass 모듈을 추가 할 때마다 재 구축되는 것을보고 있습니다. 이로 인해 yarn add가 필요 이상으로 실행되는 데 더 오래 걸립니다.

billxinli 에 2017년 06월 21일

👍4

나도 이것을보고 있는데, 패키지 (예 : bleno)를 빌드하는 데 몇 분이 걸릴 수있는 Raspberry Pi Zero W에서는 매우 짜증납니다.

richkzad 에 2017년 06월 22일

👍1

Yarn v0.27.5 및 uws 여전히 이것을 볼 수 있습니다. 내 패키지의 내용이 변경 될 때마다 uws가 다시 빌드됩니다.

uws 에 대해 내가 볼 수있는 유일한 흥미로운 점 은 package.json에 종속성 필드가 없다는 것 입니다.

wmertens 에 2017년 07월 03일

👍10

이것은 지난 며칠 동안 저에게 상당히 실망스러워지고 있습니다. 한 단계에서 전역 적으로 windows-build-tools 설치했습니다 (네이티브 패키지 용 Windows 개발 환경을 설정하기 위해 실제로 한 번만 빌드하면 됨). 패키지를 추가 할 때마다 자체적으로 다시 빌드됩니다. 당신이 상상할 수 있듯이 꽤 오랜 시간이 걸렸고 결국 더 이상 설치할 필요가 없다는 것을 깨달았고 제거했습니다.

이제 node-sass 패키지를 추가 할 때 다른 프로젝션에서 계속 재 빌드하기를 원하는 것 같습니다.

이 동작은 나를 위해 yarn add 및 yarn remove 에서 발생합니다. 네이티브 패키지는 노드 버전에 따라 한 번만 빌드되므로 이러한 단계에서 다시 빌드 할 필요가 없습니다.

편집 : Windows 10에서 Node v8.2.1 및 Yarn v0.27.5 사용.

lostpebble 에 2017년 07월 31일

uws 이 (가) 나를 위해 재 빌드 된 횟수를 셀 수 없습니다. :) uws
종속성이 없으며 package.json의 필드도 누락되었습니다.

2017 년 7 월 31 일 월요일 오후 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
.

wmertens 에 2017년 08월 01일

저는 0.27.5를 사용하고 있으며 bs-platform 으로이 동작을 계속 확인합니다.

johannth 에 2017년 08월 08일

이것은 bs-platform 합니다.

constfun 에 2017년 08월 13일

👍1

거기에 좋은 자격 감각… PR 팀은 어때?

2017 년 8 월 22 일 화요일 오전 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
.

wmertens 에 2017년 08월 22일

👍4

지금까지 언급되지 않은 것 같지만 yarn global list 하여이 버그를 재현 할 수도 있습니다.

재현 단계 :

새로운 글로벌 환경 사용 : : warning : 수행중인 작업을 알고있는 경우에만 실행하십시오.
```
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 는 항상 해당 기본 패키지를 다시 컴파일합니다.
😭

이게 도움이 되길 바란다.

ℹ️ Homebrew를 통해 Yarn 0.27.5가 설치된 MacOS 10.12.6.

michaelbaudino 에 2017년 08월 22일

👍2

자격은 필요하지 않지만 좌절감을 이해할 수 있습니다. 이것은 많은 사람들에게 많은 시간을 낭비하고 있습니다 (긴 재설치는 시간이 지남에 따라 합쳐지고 흐름이 중단됨). 물론, "make a pull request"라고 말할 수 있습니다. 하지만 잠재적으로 코드 몇 줄만 변경하는 것 외에 학습 과정이 될 것입니다. 우리가 바라는 것은이 프로젝트의 내용을 잘 아는 사람들이 다음 릴리스에서이 문제의 우선 순위를 정할 수 있다는 것입니다. 다소 중요해 보입니다 (그리고 잠재적으로 쉬운 해결 방법입니까? 노드 버전이 변경되지 않은 경우 바이너리를 다시 설치하지 마십시오).

처음보고 된 지 거의 1 년이 지났습니다.

나는이 말을 할 자격이 없다고 들리 길 바란다. 나는이 프로젝트와 그것이 이미 내게 가져온 유용성에 대해 매우 감사하다고 덧붙이고 싶다. 이 문제는 제가 겪었던 몇 안되는 문제점 중 하나였습니다.

편집 : 방금 무작위 패키지에 대해 yarn remove 을 (를) 시도했지만 (이번에는) 내 바이너리를 다시 빌드하지 못했습니다. 부작용은 내 바이너리가 지금 완전히 누락되어 있으며이를 고치는 유일한 방법은 npm rebuild 입니다. 따라서이 문제로 인해 불필요한 재 구축이 발생하는 것처럼 보일뿐만 아니라 해당 프로세스가 실패하면 npm 에 다시 의존하여 문제를 다시 해결해야합니다.

lostpebble 에 2017년 08월 23일

👍13

@zhangjyr 및 @lostpebble과 동일한 동작이 yarn add 은 잘 작동하지만 yarn remove 하면 네이티브 패키지가 다시 빌드됩니다.

Mac Sierra 10.12.6
원사 0.27.5

farism 에 2017년 08월 29일

이것도 나에게 영향을 미치기 때문에 나는 이것에 대해 내가 무엇을 할 수 있는지 보려고 노력할 것입니다. Yarn은 그다지 공헌하기 어렵지 않으니 누군가 PR을 보내고 싶으 시다면 한번 해주시면 최대한 지원해 드리겠습니다.

몇 주 동안이 작업을 수행 할 수 없습니다.

BYK 에 2017년 08월 29일

👍8

나도보고있다.
개츠비를 기반으로 현장에서 작업합니다. 모든 실 작업은 재건을 유발합니다.
개츠비와 실링으로 사이트를 만들어보세요. 도움이 되었기를 바랍니다

Rulikkk 에 2017년 09월 11일

👍1

gatsby를 사용하는 프로젝트에서 이것을 본다 :
원사 1.0.2
노드 7.10.1
우분투 16.04

AndyMoreland 에 2017년 09월 16일

이 문제는 현재 상당히 심각 해지고 있습니다. 내 바이너리는 항상 다시 빌드 될뿐만 아니라. 그러나 yarn add 또는 yarn install (모듈을 업데이트 / 롤백하기 위해 package.json 에서 패키지의 버전 번호를 변경 한 후) 후에 내 바이너리가 완전히 제거되는 경우가 종종 있습니다. 그리고 나중에 yarn install 또는 yarn install --check-files 아무리 실행해도 해당 바이너리는 손실되고 사라지고 다시 돌아 오지 않습니다. 이를 검색하는 유일한 방법은 npm rebuild 입니다.

실이 네이티브 패키지의 상태에 대한 지식이 전혀없는 것처럼 느껴지기 시작했습니다. 이미 설치 / 빌드되었는지 또는 제대로 설치 / 빌드되지 않았는지 여부.

이것에 대해 진전이 있었습니까?

lostpebble 에 2017년 09월 27일

👍1

@arcanis의 실 무결성 파일에 최근 artifacts 필드를 추가하면이 문제를 해결하는 데 도움이 될 것이라고 생각합니다. 아직 진행되지 않았지만 PR에 열려 있습니다. :)

BYK 에 2017년 09월 27일

👍1

내 reasonml 프로젝트에 패키지를 설치할 때 bs-platform과 비슷한 문제가 있습니다.

cullophid 에 2017년 10월 03일

👍1

동일 ... 말 그대로 모든 yarn add 는 gyp 프로젝트를 다시 빌드합니다.

MeirionHughes 에 2017년 10월 13일

👎1

여기에서도 발생합니다.
(얀 1.2.1)

Okoyl 에 2017년 10월 22일

👎1

node-sass 이것을 봅니다.

jbrooksuk 에 2017년 10월 25일

👎1

예를 들어 Cypress와 만나게됩니다.

노드 -v
v8.8.1
원사 -v
1.2.1

piehei 에 2017년 10월 26일

👎1

✋ 추가 정보없이 "Me too"를 작성하는 대신 Github의 상단 게시물 에 +1 기능을 사용하세요. "me too"댓글을 쓸 때마다 35 명의 가입자에게 불필요하게 알림이 전송됩니다.

sandstrom 에 2017년 10월 26일

👍6

+1

HafizAhmedMoon 에 2017년 10월 26일

👎9 😄3 😕2

업데이트를 받으려면 Subscribe 클릭하십시오. 모든 사람이 문제가 해결되면 알림을 받기를 원하지만 새로운 누군가가이 문제에 직면했을 때 알림을받지 않기를 바랍니다.

@BYK 는 스레드를 잠그고 소유자 만 사용할 수 있도록 할 수 있습니다.

printercu 에 2017년 10월 26일

👍7

현재이 문제를 조사 중이며 재현 가능한 최소 테스트 케이스로 요약하려고합니다. 이 문제를 보여주는 "훌륭한"패키지는 htmlstrip-native 입니다. 컴파일하는 데 몇 분이 걸리므로 놓칠 수 없습니다.

다른 사람이 빈 폴더에서 package.json 을 (를) 시도해보고 싶습니다.

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

다음 명령을 실행 해보십시오.

yarn upgrade [email protected]

내 컴퓨터에서 최신 yarn 1.2.1을 사용하면 upgrade 명령을 사용하면 htmlstrip-native 가 다시 작성되며 영원히 걸립니다. left-pad 업그레이드는 htmlstrip-native 또는 그 종속성에 영향을 미치지 않으므로 Yarn은 이것을 재 구축해서는 안됩니다.

이제 npm 시도 :

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

내 컴퓨터에서 두 번째 명령이 (올바르게) htmlstrip-native 새로 다시 빌드하지 않습니다.

편집 : 위의 모든 게시물을 다시 읽음 으로써이 사건은 누구에게도 놀라운 일이 아닌 것처럼 들립니다. 나를 포함한 대부분의 사람들은 단순히 원사에게 _anything_을 요청하면 재건 결과가 발생한다는 것을 발견하고 있습니다. 대부분의 사람들이 빌드하는 데 오랜 시간이 걸리는 네이티브 패키지를 사용하지 않기 때문에 이것이 커뮤니티에서 더 큰 문제가 아니라고 생각합니다. 그래서 그들은 재 빌드 단계가 없거나 너무 빨리 완료되어 누가 신경을 쓰게됩니다.

nfarina 에 2017년 10월 26일

👍4

좋습니다. 많은 디버깅 후에는이 동작이 의도적 인 것 같습니다. 코드를 추적하면 예를 들어 yarn upgrade [email protected] 결과는 다음과 같습니다.

1) upgrade 모듈이 호출되어 left-pad 대해 new Add() 작업을 실행합니다.
2) Add.init() 는 수퍼 클래스 인 Install.init() 호출합니다.
3) Install.init() 대기열에 rebuildingPackages 단계
4) PackageInstallScripts.init() 에서는 단순히 _all_ 패키지를 수집하여 workQueue 에 추가하여 다시 빌드합니다.
5) PackageInstallScripts 는 htmlstrip-native 대한 설치 명령이 있음을 발견하고 실행합니다. 이것은 우리 모두가보고있는 매우 느린 네이티브 재 빌드입니다.

지금까지 내가 본 모든 것에서 다시 빌드 할 필요가없는 패키지를 걸러 내려는 논리가없는 것 같습니다. 콘솔 출력에 명시된 것처럼 단순히 모든 것을 다시 빌드하는 것입니다.

Yarn 팀의 누군가가 여기에 차임하는 것을 좋아합니다.이 동작이 진정 의도적이라면이 문제를 종결하는 것이 좋습니다!

내 상황에 대해 개인적으로 htmlstrip-native 종속성을 교체 할 것입니다. 빌드하는 데 몇 분이 걸릴 이유가 없기 때문입니다 (작은 .c 파일 몇

nfarina 에 2017년 10월 26일

👍6

의도하지 않은 디자인의 부작용처럼 들리지만 @ yarnpkg / core의 누군가가 그것에 대해 언급 할 수 있습니다. 다시 빌드 할 필요가없는 패키지를 다시 빌드하기위한 것이 아니라고 생각합니다.

Daniel15 에 2017년 10월 26일

이것은 의도적 인 것이 아니며 아마도 그렇게 구현하는 것이 더 쉬울 것입니다.
위의 BYK에서이 문제가 PR을 찾고 있다는 의견이 있습니다.
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

james-rabbit 에 2017년 10월 26일

확실히 네이티브 무거운 패키지는 Yarn의 최우선 순위로 나타날만큼 일반적이지 않지만 Yarn은 모든 설치에서 패키지를 다시 빌드하지 않는 기능을 가지고 있습니다.
이것은 수정하기 쉽고 PR을 보내야하는 버그처럼 보입니다.
Yarn은 빌드 된 패키지가 손상되었을 수 있는지 확실하게 알 수 없기 때문에 경고가있을 수 있습니다. 이것이 바로 지금 설치 스크립트를 열심히 재실행하는 이유입니다.

Reason / Ocaml 종속성에는 많은 컴파일이 필요하기 때문에 많은 기본 컴파일 문제를 해결하는 Reason https://github.com/esy-ocaml/esy-install 뒤에 팀에서 사용하는 Yarn 포크가 있습니다.
그 접근 방식이 성숙 해짐에 따라 변경 사항을 업스트림으로 병합 할 수 있기를 바랍니다.

bestander 에 2017년 10월 30일

👍4

따라서 기본적으로 네이티브 패키지는 다음과 같은 이유로 다시 빌드됩니다.

1) force=true 플래그가 설정되었거나
2) 패키지가 fresh=true 로 표시되었습니다.

일부 명령 (예 upgrade 및 remove )에서 force 플래그가 "경우에 따라"true로 설정되어있는 것처럼 보입니다. 이 플래그는 "변경 여부에 관계없이 모든 패키지를 다시 빌드"할 것을 약속하므로이 약속을 위반할 수 있으므로 일부 변경 감지 코드를 추가하는 것은 의미가 없습니다.

따라서이 문제를 해결하려면 force=true 를 설정하는 코드의 다양한 위치에 대한 가정에 도전해야 할 것 같습니다.

내가 추적 한 첫 번째 것은 yarn upgrade whatever 실행할 때 발생합니다. @juanca에 의해 # 2780의 일부로이 커밋 에서 소개되었습니다. 커밋 노트는 다음과 같이 말합니다.

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

@juanca 또는 원사의 역사에 더 익숙한 사람이 이것이 해결하려는 문제에 차임 할 수 있습니까?

nfarina 에 2017년 11월 07일

👍9

@nfarina 감사합니다. 업그레이드를 위해 네이티브 패키지를 강제 빌드하고 싶을 수도 있습니다 (업그레이드중인 경우). 그러나 설치 (yarn add)의 경우, 이미 설치된 네이티브 패키지를 다른 것이 설치 될 때 다시 빌드하는 가정에 대해 합법적으로 도전해야한다고 말하고 싶습니다.

yawaramin 에 2017년 11월 07일

👍2

이전 버전이 yarn.lock에 있기 때문에 Yarn 해석기가 기존 종속성을 건너 뛰지 않도록 force 플래그가 설정되어 있다고 가정합니다.

업그레이드 작업을위한 빠른 솔루션이라고 생각합니다.
적절한 방법은 지정된 패키지의 해상도에만 영향을 미치고 force 만큼 핵이되지 않는 다른 플래그를 전달하는 것입니다.
PR 보내기 :)

bestander 에 2017년 11월 13일

@juanca 또는 원사의 역사에 더 익숙한 사람이 이것이 해결하려는 문제에 차임 할 수 있습니까?

맞습니다. 저는 Add API로만 작업했습니다. 기존 패키지를 추가 할 때 아무것도하지 않습니다.

또한 절차 흐름을 제어 할 때 더 나은 기술을 사용하는 것이 좋습니다.

juanca 에 2017년 11월 13일

node-opencv에 대한 종속성이있는 프로젝트에서 내 라즈베리 파이 0에 원사를 사용하고 있습니다. 관련없는 패키지를 추가 / 제거 / 업데이트 할 때마다 재 구축을 위해 35 분을 기다려야합니다.

Torsten85 에 2018년 01월 04일

👍7 😄2 ❤1

@ Torsten85 , 저는 파이에서도 사용합니다. 예, 불필요한 재 구축은 우리가 해결해야 할 것입니다.
재 구축을위한 재현 스크립트를 제공 할 수 있습니까?

bestander 에 2018년 01월 04일

👍1

lubuntu 17.10에서 얀을 사용할 때 https://github.com/mui-org/material-ui로 개발합니다.

yarn add/remove (-D) <pkg> 마다 새로 설치하는 것처럼 모든 것을 재 구축하는 데 1 분 이상 걸립니다.

caub 에 2018년 01월 12일

이것이 npm이 처리하는 방식입니까? 그렇지 않다면 일시적으로 전환하는 것이 가능한 해결 방법일까요?

rightaway 에 2018년 01월 21일

👎2

여기에서도 일어나고 있습니다

노드 9.2.0
원사 1.4.0

종속성을 추가 할 때마다 bcrypt 또는 couchbase와 같은 모듈이 매번 다시 빌드됩니다.

rkmax 에 2018년 01월 29일

👍1

안녕하세요 여러분, 저는 https://github.com/yarnpkg/yarn/pull/5314 작은 해킹 작업을하고
아이디어는 내장 된 패키지를 오프라인 미러에 캐시하여 항상 설치 스크립트를 실행하지 않도록하는 것입니다.

따라서 오프라인 미러를 사용하고 yarn add node-sass :

yarn은 평소와 같이 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 에 2018년 02월 04일

❤2 👍1

나는 typescript를 글로벌 패키지로 설치하려고하는데, yarn은 지금 정말로 필요한 것을 설치하는 대신 모든 시간을 재 구축하는 데 소비합니다.

나는 그것이 더 빠르고 더 좋다고 생각하면서 실로 옮겼습니다. npm의 흔적을 제거했습니다 (노드 설치와 함께 제공되는 항목 제외). 모든 글로벌 패키지를 yarn에 다시 설치했습니다.

Yarn은 이제 간단한 패키지 설치를 위해 1 ~ 15 분 정도 기다려야합니다. Yarn은 request-package가 재 빌드가 필요한 기본 패키지에 명시 적으로 의존하지 않는 한 다른 항목을 다시 빌드하기 전에 먼저 요청한 것을 설치하기에 충분히 똑똑해야합니다.

환경:

노드 : 9.4.0
원사 (글로벌) : 1.3.2
macOS Sierra : 10.12.6
Macbook Pro 15 인치
- 메모리 : 16GB
- CPU : 2GHz-Intel Core i7
- 저장 : 자홍색 (많은 여유 공간)
- 설치시 실행되는 앱 : Firefox (6 개 탭), Mail.app 및 iTerm (2 개 탭 포함)

로그

패키지를 가져 오는 데 많은 시간이 걸립니다.

원사 글로벌 업그레이드 typescript
원사 글로벌 v1.3.2
[1/4] 🔍 패키지 해결 중 ...
[2/4] 🚚 패키지 가져 오는 중 ...
[############################################### ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

연결 종속성이 몇 분 동안 진행되지 않고 멈 춥니 다.

원사 글로벌 업그레이드 typescript
원사 글로벌 v1.3.2
[1/4] 🔍 패키지 해결 중 ...
[2/4] 🚚 패키지 가져 오는 중 ...
[3/4] 🔗 의존성 연결 ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

모든 패키지 재 구축-많은 시간이 걸립니다

원사 글로벌 업그레이드 typescript
원사 글로벌 v1.3.2
[1/4] 🔍 패키지 해결 중 ...
[2/4] 🚚 패키지 가져 오는 중 ...
[3/4] 🔗 의존성 연결 ...
[4/4] 📃 모든 패키지 재 구축 ...
[12/17] ⠐ 웹 소켓
[2/17] ⠐ expresso : ISO C99를 허용하는 gcc 옵션 확인 중 ...
[8/17] ⠐ 직렬 포트 : [email protected] 사용 | 다윈 | x64
[6/17] ⠐ now :> 소스 코드 확인 : https://github.com/zeit/now-cli

원사 글로벌 업그레이드 typescript
원사 글로벌 v1.3.2
[1/4] 🔍 패키지 해결 중 ...
[2/4] 🚚 패키지 가져 오는 중 ...
[3/4] 🔗 의존성 연결 ...
[13/17] ⠈ 서버리스
[13/17] ⠂ 서버리스
[14/17] ⠠ 솔 그래프
[14/17] ⠁ 솔 그래프
[14/17] ⡀ 솔 그래프
[-/ 17] ⠈ 기다리는 중 ...
[-/ 17] ⠄ 기다리는 중 ...
[-/ 17] ⠠ 기다리는 중 ...
[-/ 17] ⠈ 기다리는 중 ...
[-/ 17] ⠄ 기다리는 중 ...
[-/ 17] ⢀ 기다리는 중 ...
[-/ 17] ⠈ 기다리는 중 ...

나는 계속 기다린다 :-)

abdul 에 2018년 02월 05일

👍3

또 다른 부작용은 사전 컴파일을 다운로드하고 캐시하는 라이브러리도 지워지고 다시 다운로드되어야한다는 것입니다. 즉, 빌드 대상 SDK의 nwjs-builder-phoenix 캐시

MeirionHughes 에 2018년 02월 08일

네이티브 패키지가 아닌 패키지 버전을 업데이트 할 때 네이티브 패키지는 항상 다시 빌드됩니다.

Yarn은 npm과 같이 바이너리를 전역에 캐시합니까?

snowyu 에 2018년 02월 13일

모든 간단한 설치에서 nwjs를 다시 빌드해야하는 불편 함을 느끼기 시작합니다. 말이 안돼

LuisHCK 에 2018년 02월 14일

이것도보고 있어요. uws는 추가 / 제거 작업을 수행 할 때마다 다시 작성됩니다. 원사 v1.3.2

Spongman 에 2018년 02월 16일

안녕하세요 @bestander. 우리 회사의 monorepo에서 # 5314를 시도했지만 일부 종속성의 재 구축을 중지하는 데 아무런 영향을 미치지 않았습니다. 추가 된 테스트에 표시된대로 .yarnrc에서 yarn-offline-mirror 및 pack-built-packages 를 활성화했습니다.

중요한 점은 yarn 를 실행하는 데는 우리가 직접 실행 한 명령이 yarn 이더라도 항상 약 40-50 초가 걸린다는 것입니다.

bbrzoska 에 2018년 02월 19일

👍2

@ bazyli-brzoska, 플래그를 더 명확하게 변경하고 설명을 업데이트하는 것을 잊었습니다.
experimental-pack-script-packages-in-mirror 플래그를 "true"로 설정하여 시도 할 수 있습니까?

bestander 에 2018년 02월 21일

이것에 진전이 있습니까? pull 요청이 이미 병합되었으며 최신 릴리스 1.5.1에 있음을 확인했습니다. 나는 1.5.1을 사용하고 있으며 아무것도 변경되지 않았습니다. 그럼에도 불구하고 npm으로 돌아가는 것을 고려하고 있습니다. 322.70s 또는 282.69s 또는 683.41s (실제로 내 마지막 3 개의 yarn add s)를 기다리기 때문에 작은 롤업 플러그인이나 lodash 또는 거의 모든 것을 설치하는 것은 미친 짓입니다.

이와 같은 주요 경고가 README.md에 있으면 멋질 것입니다. 사용자는 "더 빠르다"고 주장하기 때문에 yarn을 설치하고 npm에서 yarn으로 전환하는 것은 작은 단계가 아니므로 개발자에게 사전 경고가 있으면 좋을 것이므로 전환하기 전에 한 번 더 생각할 수 있습니다. 그들의 스크립트, 그들의 글로벌을 오염시키고 원사 CLI를 학습합니다.

나는 이것이 내 오래된 32 비트 머신의 문제라고 생각했지만 237 번째 발생을 본 후에 나는 그것을 봤고 오, 실이 빠르지 않습니다. 큰.

비열한 것 같아 미안하지만 좌절감을 느끼는 것 같아요.

nnmrts 에 2018년 02월 28일

👍1

우리는 기부금을받습니다.

즉, "필요"하지 않은 경우 다시 빌드되는 패키지와 관련하여 염두에 두어야 할 사항 : 빌드 단계는 종속성이 설치된 후 실행됩니다. 빌드 스크립트가 이러한 종속성을 사용할 수 있음을 의미합니다. 즉, 이러한 종속성이 어떤 이유로 든 변경되면 (예 : 패키지의 호환 가능한 두 버전을 하나로 최적화 한 경우 '무작위로'발생할 수 있음), 해당 종속성이 실제로는 아니더라도 실제로 빌드 단계를 다시 실행해야합니다.

그래서 그것은 정확히 쉬운 문제가 아닙니다. 문제의 적어도 일부는 package.json 디자인 자체에서 비롯됩니다. 좌절감에 대해 알려주세요 🙂

arcanis 에 2018년 02월 28일

@arcanis 나는이 부분을 얻지 못합니다.

이러한 종속성이 빌드 중에 실제로 사용되지 않더라도 (어떻게 알 수 있었습니까?).

YARN 디자인은 정적 종속성 + 버전 (yarn-lock)을 유지하는 것이기 때문에 임의의 "업데이트"가 없을 것이라고 생각했습니다.
하지만 package json은 전체 트리를 제공하는데 왜 "우리가 알 수있는 방법"이라고 말합니까? 트리가 해결되면 X 빌드에 대한 종속성 (심층 수준의 종속성 포함)이 변경되었는지 여부를 쉽게 말할 수 있습니다.

Rulikkk 에 2018년 02월 28일

babel-core 및 left-pad@^1.0.0 종속 된 종속성 foo 이 있고이 foo 종속성에 인덱스 파일에서 babel을 실행하는 빌드 스크립트가 있다고 가정 해 보겠습니다. .

실행 한 후 yarn add foo 내 프로젝트에서 내가 가진 결국 폴더 [email protected] 오른쪽 node_modules에? 이제 새로운 왼쪽 패드 버전 ( 1.1.0 )이 출시되어 프로젝트에서 사용하고 싶습니다. yarn add left-pad 실행하면 latest , 즉 1.1.0 됩니다.

이제 일어날 수있는 일은 Yarn이 트리에 두 개의 왼쪽 패드 복사본이 있음을 "보고"최적화 할 수 있다는 것입니다. 결국 foo 는 left-pad@^1.0.0 에 따라 달라집니다 1.1.0 도 호환됩니다. 따라서 이전 버전을 제거하고 1.1.0 만 사용합니다. 종속성이 변경 되었기 때문에 Yarn이 left-pad 가 빌드 시간 종속성이 아니라 런타임 종속성임을 알 수있는 방법이 없기 때문에 빌드 스크립트를 다시 실행해야합니다.

이제 "하지만 전 이적 종속성이 변경되었을 때 재 구축을 건너 뛰지 않는 이유는 무엇입니까?"라고 물을 수 있습니다. 대답은 일부 패키지 (특히 네이티브 패키지)에는 빌드 방식에 근본적으로 영향을 미치는 종속성이 있다는 것입니다. 이런 일이 발생하면 우리는 정말로 그 패키지를 다시 빌드하고 싶거나 호환되지 않는 아티팩트가 생깁니다.

arcanis 에 2018년 02월 28일

@arcanis , 나는 당신이 문제를 오해하고 있습니다. 여기서 문제는 yarn 가 빠르게 연속해서 두 번 (또는 그 이상) 실행되는 경우에도 이러한 기본 패키지가 _ 매번 다시 빌드된다는 것입니다. 종속성 업데이트와 관련이 _ 아무것도 없습니다 _-항상 _ 다시 빌드합니다.

Spongman 에 2018년 02월 28일

👍4

@Spongman 귀하의 최근 의견에 동의합니다. 그러나 @Spongman이 올바르게 언급했듯이 다시 빌드는 매번 발생합니다 . yarn && yarn 만 수행하더라도 종속성 구조가 변경되지 않았음에도 불구하고 두 번의 전체 재 빌드를 얻을 수 있습니다.

Rulikkk 에 2018년 02월 28일

👍3

OP에서와 같이 yarn add leveldown bcrypt && yarn && yarn 실행을 시도했지만 하나의 빌드 만 얻었습니다. : /이 동작을 재현하는 데 사용할 수있는 명령이 있습니까?

arcanis 에 2018년 02월 28일

예를 들어 시도해 볼 수 있습니다.

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 에 2018년 02월 28일

👍1

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

yarn & yarn

두 번의 재 빌드가 발생하지 않지만 socket.io가있는 예제는 반응을 추가하고 반응을 제거하면 두 번의 재 빌드가 발생합니다.

billxinli 에 2018년 02월 28일

yarn v1.5.1로 socket.io 예제를 시도했지만 새 기능을 사용하여 네이티브 빌드를 캐시 할 때 다시 빌드되지 않았습니다. 이를 위해서는 오프라인 캐시를 사용해야합니다. 내 ~/.yarnrc 이 있습니다.

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

해당 구성없이 다른 사용자로 시도하면 매번 다시 빌드됩니다.

skomorokh 에 2018년 02월 28일

예, 이러한 옵션을 추가하면 지금 다시 빌드하지 않습니다.
그러나 experimental-pack-script-packages-in-mirror true 이면 여전히 다시 빌드됩니다.
yarn-offline-mirror 를 "~ / .yarn / cache"와 같은 기본 경로로 설정하지 마십시오.

snowyu 에 2018년 03월 01일

아직 실험적이지만 흥미로운 제안입니다 (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 에 2018년 03월 01일

👍1

@arcanis 친절한 답변에 감사드립니다. 좌절감은 실이 제시되는 방식에서 비롯됩니다. 현재로서는 "빠르지"않습니다. 확실히 npm보다 빠르지 않으며 실제 프로젝트에서는 사용할 수 없습니다. Imho,이 문제가 해결 될 때까지 README.md 파일에 @skomorokh 의 해결 방법에 대한 정보가 있어야합니다. 또는 설명에서 "빠름"을 제거하십시오.

angularjs 리포지토리의 readme에 경량 프레임 워크라고 명시되어 있다면 동일한 좌절감을 느낄 것입니다. 그것은 아닙니다.

nnmrts 에 2018년 03월 01일

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

snowyu 에 2018년 03월 02일

오늘 조금 디버깅을 시도 할 것입니다. 새로 설치된 패키지 만 다시 빌드하기 위해 pkg.fresh 를 확인하지 않는 것이 실제로 PackageInstallScripts 만큼 간단 할 것이라고 생각합니다. 대신 모든 것을 반복하는 것처럼 보입니다.

rally25rs 에 2018년 03월 02일

🎉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 에 2018년 03월 02일

내 최신 반응 앱에 종속성이없는 패키지 인 yarn add ed moment ) 사용했습니다. 377.97s .

그 직후에 다시 한 번, 389.63s 했고 바이너리를 다시 빌드했습니다.

비교를 위해 node_modules를 삭제하고 npm install .
added 1751 packages and updated 124 packages in 360.595s

지금 npm으로 다시 전환했습니다.

nnmrts 에 2018년 03월 03일

좋아,이 문제에 대한 모든 시각을위한 더 많은 정보 ... 나는 하루 반 동안이 일을 엉망으로 만들고 마침내 몇 가지를 깨달았다.

첫째, 이러한 재 구축 문제의 대부분이 수정되었습니다. PackageInstallScripts 에는 패키지에 대한 설치 스크립트 만 다시 실행하는 코드가 이미 있습니다. "fresh"로 표시됩니다 .

    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 은 다시 빌드하지 않습니다.

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은 캐시와 비교하여 "변경된"파일을 확인하므로 패키지를 다시 설치할 수 있도록 "새로"표시합니다.

그런 다음 "새로 워진"설치 스크립트를 다시 실행하는 위의 논리를 트리거합니다. Yarn은 도움이되고 잘못된 파일을 "수정"하려고하지만 물론 설치 스크립트로 인해 파일이 변경되었음을 알지 못합니다. 이 문제를 해결하는 방법을 조사해야 할 수도 있지만, 이러한 파일을 비교하는 방식을 변경하는 것에 대한 이야기도 있으므로 (모든 파일에서 stat 실행 중지) 해당 재 작업으로 해결 될 수 있습니다.

여기에 일부 사람들은 작동한다고 말하고 다른 사람들은 작동하지 않는다고 말하는 일부 사례를 설명합니다.

rally25rs 에 2018년 03월 04일

👍9 ❤3

더 깊이 다이빙 해 주셔서 감사합니다, @ rally25rs.

Re : 삭제 명령에서 force 사용.
그것은 분명히 핵 접근 IIRC https://github.com/yarnpkg/yarn/pull/323으로 정확성을 달성 한 빠른 컷 코너 버그 수정
force 를 제거하고 문제를 해결하는 것이 어렵지 않아야합니다.
node_modules/uws/uws_darwin_57.node :이 파일에 있어야합니다 artifacts 분야 .yarn-integrity 다음 UWS는 연결시하지 신선한 상태로 표시 할 수 없습니다.
여기에 뭔가 잘못되었을 수 있습니다.

bestander 에 2018년 03월 04일

@bestander 아 2에 좋은 지적입니다. 나는 수표에 그것을 작동하는

rally25rs 에 2018년 03월 04일

stereokai 에 2018년 03월 19일

@stereokai 위의 의견에서 npm은 제거 / 제거시 패키지를 다시 빌드하므로 npm의 동작을 표준으로 간주하면이 경우가 "올바른"것입니다.

rally25rs 에 2018년 03월 19일

@ rally25rs 지적 해 주셔서 감사합니다 :)

그러나 패키지 관리자에 관계없이이 동작이 버그라고 생각합니다. 올바른 작동을 위해 이런 종류의 행동이 왜 필요한지 이해하기 어렵습니다. 앱이 이미 있기 때문에 다른 프로그램을 추가 / 제거 할 때 OS가 로컬 프로그램을 다시 설치하지 않습니다. 나는 정적 의존성 관리자로부터 다른 것을 기대하지 않을 것입니다, nahmean?

stereokai 에 2018년 03월 20일

👍1

@stereokai 나는 다소 동의한다. 그래서 나는 "arguably correct"라는 문구를 사용했다 .😆
관련없는 응용 프로그램을 제거 할 때 다른 응용 프로그램이 설치된 위치도 OS가 변경되지 않습니다.

다음과 같은 종속성 트리가 있다고 가정합니다.

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

이것을 설치하면 node_modules 아래에 동일한 디렉토리 구조가 형성됩니다. depB 를 루트로 올릴 수 없기 때문입니다.

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

하지만 yarn remove depB 경우 새로운 dep 구조는 다음과 같습니다.

  |- depA v1
       |-depB v2

  |- 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 에 2018년 03월 20일

👍2

적어도 _some_ 케이스에서 재 구축을 피하는 방법이 있다면 멋질 것입니다.

lydell 에 2018년 03월 20일

👍1

누구나 PR 작업을 환영합니다. 😸 위에서 지적했듯이 yarn install 및 yarn add (대부분의 경우)에서는 이미 재 구축이 수행되지 않습니다. 종속성 (또는 설치 중에 자체 파일을 변경하는 다른 패키지)에 uws 이있을 때 yarn add 대한 불필요한 재 빌드를 제거해야하는 # 5470이 열려 있습니다. 내가 아는 유일한 남은 경우는 yarn remove 입니다.

rally25rs 에 2018년 03월 20일

👍3

이 스레드의 대부분을 읽은 후 여기서 무슨 일이 일어나고 있는지 이해하지 못합니다.

다른 (관련되지 않은) 모듈에 yarn add 를 사용할 때마다 여러 기본 패키지가 다시 작성됩니다. 랩톱의 CPU에 매우 높은 부하가 걸리는 데 약 20 분이 걸립니다. 나는 그렇게 할 수 없습니다.

분명히이 스레드에서 19 개월 동안 문제가되었습니다.

버그입니까? 작업 중입니까? 해결 방법이 있습니까? npm으로 다시 전환해야합니까?

vibl 에 2018년 03월 26일

👍1

npm으로 다시 전환해야합니까?

예, # 5470이 출시 될 때까지.

Spongman 에 2018년 03월 26일

@vibl

분명히이 스레드에서 19 개월 동안 문제가되었습니다.

실제로 (대부분) 오래 전에 수정되었습니다. 이 스레드는 몇 주 전에 패키지가 파일을 변경하면 yarn이 패키지를 다시 빌드하는 하나의 가장자리 케이스를 위해 열려 있습니다. 그것). 그리고 remove 및 upgrade 가 재 빌드를 수행해야하는지에 대한 공개 토론을 위해 (npm에서 수행하지만 그렇지 않을 수도 있음)

버그입니까?

아마도. 어떤 패키지가 재 구축됩니까? 내가 아는 유일한 문제는 uws 이므로 더 많은 것을 아는 것이 도움이 될 것입니다.

작업 중입니까?

위에서 언급 한 특정 사례는 # 5470에서 수정되었습니다.

해결 방법이 있습니까?

추가하려는 패키지에 설치 스크립트가없는 경우 --ignore-scripts 사용할 수 있습니다.

또는 위의 PR에서 지점을 확인하여 사용할 수 있습니다.

약 20 분 소요

와. 어떤 패키지인지 궁금합니다.

rally25rs 에 2018년 03월 26일

대답 해줘서 고마워.

noise-search , level-rocksdb 및 jq 패키지는 yarn add 관련없는 패키지를 추가 할 때마다 다시 컴파일됩니다. 내 노트북은 조금 오래되어 동시에 컴파일하는 데 시간이 오래 걸립니다.

Yarn 1.5.1과 노드 9.8.0을 사용했습니다.

vibl 에 2018년 03월 26일

@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.

MacbookPro에서 7 분 이상 😢

어쨌든, 나는 noise-search 를 설치 한 다음 # 5470의 코드로 yarn add left-pad 를 실행했고 리빌드를 _not_했기 때문에 일단 병합되면 가야한다고 생각합니다 👍

rally25rs 에 2018년 03월 26일

감사 :-)

며칠, 몇 주 또는 몇 달 후에 Yarn을 다시 확인해야합니까?

vibl 에 2018년 03월 26일

방금 동일한 랩톱 (듀얼 부팅)에서 동일한 프로젝트를 사용하는이 버그가 Windows 10에서 발생하지 않는다는 것을 발견했습니다.하지만 최신 세 가지 Debian 버전 인 Ubuntu, Arch Linux 및 Fedora에서 발생합니다. 기묘한. 아직 MacOS를 사용해 보지 않았지만 일부 사람들도 문제가있는 것 같습니다.

nnmrts 에 2018년 03월 27일

@vibl 다음 릴리스가 언제인지 잘 모르겠습니다 (저는 그 계획에 관여하지 않습니다).

@nnmrts 그래 나는 그것이 OS에 특화된 것임을 발견했다. # 5470의 내 의견에서 :

노드 8이있는 Linux에서 파일이 캐시에서 node_modules로 복사되면 타임 스탬프가 업데이트됩니다. yarn은 파일이 다르다고 판단하고 참조를 신선하게 표시합니다.
이것은 리눅스 노드 8에서만 발생하는 것 같습니다.
이는 Node v8.5가 fs.copyFile을 도입하여 훨씬 빠르게 복사하기 때문입니다. 기본 파일 시스템 복사본으로 연결되는 IIRC는 OS간에 그리고 노드 8에서만 다르게 작동하는 이유를 설명합니다.

rally25rs 에 2018년 03월 27일

👍1

그것은 가장 확실히 맥 OS의 특정 일이 아니다 @ rally25rs의 @nnmrts. 내 Win10 PC에서도 발생합니다.

stereokai 에 2018년 03월 28일

@stereokai 글쎄,이 모든 문제는 구체적이지 않습니다. 때때로 패키지를 다시 빌드해야하고 사람들은 여전히 버그라고 생각하고 여기에 게시합니다. 모든 OS에 대한 확실한 재현 가능한 저장소가 없으면 우리는 아무것도 알 수 없습니다.

nnmrts 에 2018년 03월 28일

빌드 된 모듈 (# 5314에서)을 로컬로 캐싱하면 도움이 될 수 있습니까? :

다음을 사용하여 .yarnrc 을 프로젝트에 추가합니다.

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

처음 설치 한 후 미리 빌드 된 모듈은 ./<your-offline-mirror-path>/prebuilt 있습니다. yarn.lock 도 미리 빌드 된 변형으로 업데이트됩니다.

최신 66a0143a753cd4ade1a0fffee2174890d564c129를 가져 왔고 제대로 작동하는 것 같습니다 😎

theandrewlane 에 2018년 03월 28일

여전히 바이너리를 반복적으로 다운로드합니다.

노드 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

2018 년 3 월 29 일 목요일 오전 2시 30 분에 Andrew Lane [email protected]
썼다 :

빌드 된 모듈을 로컬로 캐싱 (# 5314에서
https://github.com/yarnpkg/yarn/pull/5314 ) 도움이 될 수 있습니까? :
다음을 사용하여 프로젝트에 .yarnrc를 추가합니다.
yarn-offline-mirror "./"
미러에서 실험 팩 스크립트 패키지 true
처음 설치 한 후 미리 빌드 된 모듈은
.// 사전 빌드. 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 에 2018년 03월 29일

@snowyu yarn.lock, node_modules 및 yarn cache clean 삭제 했습니까? ./yarn-offline-mirror/prebuilt는 설치 후 채워 집니까?

theandrewlane 에 2018년 03월 29일

임시로 새로운 프로젝트입니다. 예, 캐시 폴더에서 node-sass-4.8.3.tgz 파일을 볼 수 있습니다.
이제 yarn cache clean 합니다. 그러나 여전히 바이너리를 반복적으로 다운로드합니다 * .

```bash

원사 초기화 -y
원사 노드 엉덩이 추가
원사 추가 v1.6.0-20180327.1507
info 잠금 파일이 없습니다.
[1/4] 패키지 해결 중 ...
[2/4] 패키지 가져 오는 중 ...
[3/4] 종속성 연결 ...
[4/4] 새로운 패키지 빌드 ... https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node 에서 바이너리 다운로드
성공 저장된 잠금 파일.
success 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 에서 바이너리 다운로드
성공 저장된 잠금 파일.
성공 1 개의 새 종속성을 저장했습니다.
info 직접적인 의존성
└─ [email protected]
info 모든 종속성
└─ [email protected]
13.45 초에 완료되었습니다.
``

snowyu 에 2018년 03월 29일

좋아, 나는이 버그를 재현하기 위해 간단한 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 ... ]

최신 node 이미지를 사용하여 호스트 OSX 시스템과 도커 컨테이너 모두에서이를 재현 할 수 있습니다.

이 경우 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 에 2018년 03월 29일

@vlmonk이 여전히 만약 당신이 복제 일어나지 않습니다 https://github.com/rally25rs/yarn을 rally25rs @로부터 # 5470 (지점의 코드를 사용 fix-linking-rebuilding-uws-932 )?

karlhorky 에 2018년 03월 29일

예 @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 에 2018년 03월 29일

ttf2woff2 패키지는 빌드 단계에서 변경된 파일과 함께 제공됩니다. 다음 실행에서 yarn은 해당 파일이 변경된 것을 확인하고 패키지를 다시 설치합니다.

Yarn은이 상황을 더 잘 처리해야합니다. 빌드 단계에서 해당 파일이 변경되었음을 확인하고 변경된 파일을 다시 설치 이유로 취급하지 않고 "올바른"파일로 받아 들여야합니다.

추가 로깅 (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 에 2018년 03월 30일

👍1

OS X에서도 이것을 볼 수 있습니다. yarn add 패키지를 추가하면 종속 패키지의 재 컴파일이 트리거됩니다. 네이티브 코드가 포함 된 node-gyp 패키지가 있으며 다른 패키지가 추가 될 때마다 1 분 이상 걸리며 네이티브 모듈에는 아직 코드가 많지 않습니다 (훨씬 나빠질 것입니다). 이것은 원사 1.5.1입니다.

차이가 나는 경우 상대 경로와 함께 yarn add ../a 를 사용하고 있습니다.

해결 방법이 있는지 또는 언제 수정 될지 알려주십시오.

cisaacson 에 2018년 04월 15일

이것은 원사 1.5.1입니다.

이 문제는 아주 최근에 나온 1.6.0에서 수정되었습니다.

BYK 에 2018년 04월 16일

👍2

나는 여전히 1.6에서 이것을 본다. 오래 전에 npm 에서 yarn 로 이동 한 이후 uws 항상 재 구축되었습니다 (또는 최소한 yarn 가 uws 에 약 5-10 초).

재현 단계 :

$ 원사 구식
오래된 패키지를 고르다
$ 원사 업그레이드 [패키지]

grantila 에 2018년 04월 16일

👍5

@grantila 당신은 완전한 package.json 또는 Yarn 1.6.0 이것을 재현하는 단계가있는 저장소를 제공 할 수 있습니까?

karlhorky 에 2018년 04월 16일

이것은 1.6.0에서 여전히 발생합니다.

이 https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784를 사용하여 재현 할 수 있습니다.

sibelius 에 2018년 04월 25일

👍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 A는 재 작성 트리거 패키지 sodium . 그런 다음 컴파일이 필요한 모든 패키지처럼 보이는 것을 다시 빌드하도록 트리거를 제거했습니다. 이 간단한 패키지를 추가하는 데 36 초가 걸렸고 제거하는 데 100 초가 걸렸습니다!

편집 : Debian Stretch에서 Node 8.11.1 및 yarn 1.6.0 사용.

brenc 에 2018년 04월 29일

@arcanis @ rally25rs 는 문제를 다시 여는 것을

stereokai 에 2018년 04월 30일

👍2

나는 이것이 @ rally25rs 문제에 더

BYK 에 2018년 04월 30일

@grantila 는 upgrade _ 항상 _ 모두를 다시 빌드합니다. 이것은 의도적 인 것입니다. npm은 똑같은 일을합니다 (이 긴 스레드의 어딘가에 주석에 언급했습니다.). 잠재적으로 그 일을 중단 할 수 있습니다. 나는 그것이 어떤 영향을 미칠 수 있는지 잘 모르겠습니다.

그 외 모든 사람 :

# 5680에서 나는 패키지가 자신의 파일을 삭제하고 _ (왜 이런 일을하는 이유 😿) _ 그리고 yarn이 그것을 어디에서나 추적하지 않는 경우 (우리는 어떤 파일이 생성되거나 수정되었는지 추적) 이런 일이 여전히 발생한다고 지적합니다. 패키지에 파일이 없다고 생각하고 다시 빌드합니다.

나는 이것을 다시 열 수 있다고 생각하지만 이것은 대부분의 패키지에서 수정되었습니다. 누구든지 이것에 "나도"를 추가하고 싶다면, _please_ package.json을 제공하거나 어떤 패키지가 지속적으로 재 구축되고 있는지 구체적으로 언급하십시오. 재 빌드하는 종속성과 그렇지 않은 종속성이있을 수 있기 때문입니다.

누구나 PR을 할 수 있습니다! (# 5680의 내 디버깅 주석 참조)

rally25rs 에 2018년 04월 30일

👍1

더 많은 소음을 추가해서 죄송합니다.이 문제를 잠그고 맨 위에 최신 정보가있는 새 문제를 가리키는 것이 좋습니다.

나는 여기서 문제가 상당히 바뀌었고 적어도 부분적으로 해결되었다고 생각합니다. 여기에있는 모든 게시물로 인해 새로운 사람이 수정 된 사항과 여전히 문제가되는 사항에 대해 최신 정보를 얻는 것은 어렵습니다.

james-rabbit 에 2018년 04월 30일

👍5

@ james-rabbit에 동의합니다

stereokai 에 2018년 05월 01일

네, 맞아요. @ rally25rs 의 답변이 계속 표시되도록이 항목을 잠글 것입니다.

네이티브 패키지에 문제가있는 경우 :

모든 기본 종속성에서 발생하는 경우 일반 문제를여십시오. 이 문제는 해결 되었어야하므로 곧 문제가 발생하지 않을 것입니다. 그래도 재현 단계를 제공 할 수 있다면 언제든지 새 문제를 열 수 있습니다 (원하는 경우이 문제에 연결할 수 있음).
하나의 특정 네이티브 종속성에서 발생하는 경우 문제도여십시오. 그러나 제목에 종속성 이름을 지정하는 것을 잊지 마십시오 (설명 된 바와 같이 서로 다른 이유로 다른 패키지가 재 구축 될 수 있습니다. 모든 사람이 정보를 쉽게 공유 할 수 있도록합니다).

arcanis 에 2018년 05월 01일

Yarn: 매번 재 구축되는 네이티브 패키지

가장 유용한 댓글

모든 128 댓글

관련 문제