turborepo에서monorepo의 차분 구축
vercel에서 개발한monorepo 환경의 구축 도구입니다.vercel이지만,next에 의존하지 않습니다.
turborepo는 뭘 해결해요?
node.js에만 국한된 것이 아니라monorepo 환경에서 각 내부 모듈의 구축은 대부분 단독으로 진행된다.여기서 말하는 내부 모듈은 패키지입니다.json을 가진 디렉터리 단위로 이해할 수 있습니다.
apps/
web/
package.json # => foo, bar を参照
packages/
foo/
package.json
dist/
index.js
bar/
package.json # => foo を参照
dist/
index.js
package.json
이 빌딩은 문제를 일으킬 수 있다(구축되지 않은 요소 js에 비해).나는 터보레포가 이 문제를 해결하는 구축 도구라는 것을 깨달았다.node monorepo 내의 의존 도표를 만들고 매크로 패키지의 수정을 감시하여 현재 수정에 필요한 구축 작업을 재생합니다.(문서에 따라 병렬 프로세스 최적화도 진행 중)
제가 직접 내부 포장을 구축하지 않고 Type Script에 따라 처리하여 이 문제를 피할 수 있었지만 도구 검사의 이유로 어떻게든 구축해야 할 상황이 발생했습니다.
기타 도구와의 이점
make는 중복된 작업을 생략할 수 있지만, 구축을 건너뛰려면 논리를 써야 합니다.
그레이드와 바젤은 같은 문제를 해결할 수 있지만 노드에서 사용하면 지루하고 기술량이 늘어난다.노드용이 아니어서 API의 부조화감도 있어요.
turborepo와 마찬가지로 node용 물건은 nx가 있지만 nx가 요구하는 규칙을 준수해야 하기 때문에 창고를 새로 지을 때 가져오기가 어려울 것 같습니다.(단, 공중에서 날아다니는 사람이라 식견이 있는 사람의 평론을 원한다)
Nx: Smart, Fast and Extensible Build System
turborepo와 기본적으로 같은 개념으로 졸작bincr이 있지만 의존 도표가 없다. 대신 해시 계산에서 자신의 원본 코드 이외의 의존적인 구축 성과물을 참조했다.turborepo 참조 변경 감시
.gitignore
.turborepo가 좋은 점은 turborepo의 도입이 npm/yarn/lerna의workspace를 효과적으로 할 수만 있다면 다른 요구는 매우 적다는 것이다.이후 기본적으로 지령의 두드리기 방식으로 제어할 수 있고 캐시가 있는 관리 wsrun과 yarn workspaces run 같은 느낌으로 처리할 수 있다.
시용하다
스크래치면
npx create-turbo@latest
디렉터리만 생성되지만 이러면 터보로에서 뭘 컨트롤했는지 몰라서 스크래치로 창고 가져오는 거예요.방금 예시한 단일 보고 구조를 만들다.
apps/*
생략했습니다.프로젝트 경로 패키지다음은 json을 기술한 것이다.이 설정은
packages/*
을 모듈로 인식합니다.package.json
packages/
foo/
package.json
dist/
index.js
bar/
package.json # => foo を参照
dist/
index.js
.gitignore
package.json
이 상태에서 한 번npm/yarn install
룸 참조가 적용됩니다.이 자체는 npm/yarn의 기능이지turborepo의 기능이 아니다.turbo는 패키지입니다.json에서 파이프라인 구축을 기술합니다.이것은 최소한의 예
turbo run build
에서 사용할 수 있는 설정이다.origin/master
이외의 버전으로 설정할 때 베이스 브랜치를 추가하십시오.^build
는 각 모듈에서 npm run build (yarn build) 를 재생하는 작업을 의미합니다.(실제로 이 전후로 집행이 필요한지 아닌지 판정)터보의 변경을 측정하기 위해
.gitignore
에 추가.turbo
.감시 대상을 저장한 해시.mkdir try-turbo && cd try-turbo
yarn init -y
mkdir -p packages/foo packages/bar apps/web
cd packages/foo && yarn init -y
cd packages/bar && yarn init -y
cd apps/web && yarn init -y
출력 디렉터리를 산열 계산 대상에서 제거하기 위해 dist
,build
,.next
등을 추가한다.이때build 퀘스트 모듈이 없기 때문에 이번에는 잡지에서esbuild 묶음 기능을 사용합니다.
{
"name": "monorepo-root",
"version": "0.0.0",
"private": true,
"workspaces": [
"packages/*"
],
"scripts": {
"build": "turbo run build"
},
"devDependencies": {
"turbo": "latest"
},
"turbo": {
"baseBranch": "origin/main",
"pipeline": {
"build": {
"dependsOn": [
"^build"
]
}
}
}
}
packages/foo/index.ts# .gitignore
dist
node_modules
.turbo
packages/foo/package.jsoncd packages/foo
yarn add esbuild -D
이 상태에서 프로젝트 경로yarn build
에서 터보는 foo의 변경을 감지하고 구축합니다.export const foo: number = 1;
두 번째 변경 없음, 구축 건너뛰기{
"name": "foo",
"version": "1.0.0",
"main": "dist/index.js",
"scripts": {
"build": "esbuild index.ts --bundle --outfile=dist/index.js --format=esm"
},
"devDependencies": {
"esbuild": "^0.14.10"
},
"license": "MIT"
}
1 cached.마지막 구축 명령 결과를 다시 표시하고 있지만 구축을 건너뛰었습니다.적당히foo를 수정하고 다시 구축합니다.
packages/foo/index.ts
$ yarn build
yarn run v1.22.17
$ turbo run build
• Packages in scope: foo
• Running build in 1 packages
foo:build: cache miss, executing a078fd7ae8dc2ff6
foo:build: $ esbuild index.ts --bundle --outfile=dist/index.js --format=esm
foo:build:
foo:build: dist/index.js 43b
foo:build:
Tasks: 1 successful, 1 total
Cached: 0 cached, 1 total
Time: 430ms
$ yarn build
yarn run v1.22.17
$ turbo run build
• Packages in scope: foo
• Running build in 1 packages
foo:build: cache hit, replaying output a078fd7ae8dc2ff6
foo:build: $ esbuild index.ts --bundle --outfile=dist/index.js --format=esm
foo:build:
foo:build: dist/index.js 43b
foo:build:
Tasks: 1 successful, 1 total
Cached: 1 cached, 1 total
Time: 24ms >>> FULL TURBO
변경 사항이 감지되어 재구성되었습니다.여기까지는 쉬운데.
foo를 사용하는bar의 구축 작업을 추가합니다.
packages/bar/pacakge.json
export const foo: number = 1.1; // 1 => 1.1
packages/bar/index.ts$ yarn build
yarn run v1.22.17
$ turbo run build
• Packages in scope: foo
• Running build in 1 packages
foo:build: cache miss, executing e6e3717869758b18
foo:build: $ esbuild index.ts --bundle --outfile=dist/index.js --format=esm
foo:build:
foo:build: dist/index.js 45b
foo:build:
Tasks: 1 successful, 1 total
Cached: 0 cached, 1 total
Time: 231ms
foo를 참조하여foo+1의 코드를 되돌려줍니다.이것
turbo run build
을 하겠습니다.{
"name": "bar",
"version": "1.0.0",
"main": "dist/index.js",
"scripts": {
"build": "esbuild index.ts --bundle --outfile=dist/index.js --format=esm"
},
"devDependencies": {
"foo": "*",
"esbuild": "^0.14.10"
},
"license": "MIT",
}
bar:build이cache miss로 변하여 구축되었습니다.foo가 재이용되다.다시 한 번 건설하면 바도 캐시를 할 거예요.
import { foo } from "foo";
export const bar = foo + 1;
footurbo run build
를 변경하면 의존도표에 따라foo,bar의 순서로 재구성됩니다.$ yarn build
yarn run v1.22.17
$ turbo run build
• Packages in scope: bar, foo
• Running build in 2 packages
bar:build: cache miss, executing 31c08f60022b24e8
foo:build: cache hit, replaying output e6e3717869758b18
foo:build: $ esbuild index.ts --bundle --outfile=dist/index.js --format=esm
foo:build:
foo:build: dist/index.js 45b
foo:build:
bar:build: $ esbuild index.ts --bundle --outfile=dist/index.js --format=esm
bar:build:
bar:build: dist/index.js 89b
bar:build:
Tasks: 2 successful, 2 total
Cached: 1 cached, 2 total
Time: 382ms
...이런 느낌으로 최소한의 번거로움을 느끼고 선언에 따라 구축한다.이번에는 아주 간단한 예로 설명하지만, 실제로는 거대한 의존으로 표현되고, 이상적인 상황은 제로 config로 하면 되지만, 실제 幂 등성의 관리가 어려워질 것 같은 예감이 든다.원본 코드 이외의 幂 등 자원에 대한 인용이 없는 산열은 매번 자체적으로 생성되고 산열 계산에 휘말릴 수 있습니다.
Remote Caching (Beta)
Nx에도 이런 기능이 있지만 터보레포는 클라우드를 통해 구축된 캐치를 sync로 진행하는 기능이 있다.
이 상태에서 한 번 지어본 사람이 있다면 손 옆에 지어본 적이 없어도 그 구축 캐시를 다시 이용할 수 있다는 것이다.예를 들어git pull 이후,cache는 기본적으로 모두 효과가 있다.(단, 환경이 나쁘면 같은 상태가 되지 않는다)
그럼turborepo가vercel에 제공하는 이유는vercel이remotecache를 무료로 제공하는 것입니다.잡다한 사용 느낌, 개인 계정 or
캐치를 팀 단위로 공유할 수 있습니다.
remote cache 자체는 무료이지만 이 팀은 1인당 20/mo per member입니다.https://vercel.com/pricing
클라우드로서의vercel을 사용하는 사람이 사실상 무료라면remote caching을 위해서만 사용할 수 있지만 그 과잉으로 인해 vercel 기능을 사용하고 싶은 것은 유도하기 위한 모방 요점이다.
총결산
Reference
이 문제에 관하여(turborepo에서monorepo의 차분 구축), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/mizchi/articles/introduce-turborepo텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)