turborepo에서monorepo의 차분 구축

Turborepo
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에 비해).
  • 업데이트 시 구축을 잊어버리고 낡은 구축을 참조하여 잘못된 구축
  • 이런 상황을 방지하기 위해 원래 필요하지 않았던 구축 퀘스트를 자주 재생
  • CI의 모든 구축에서 같은 봉인을 여러 번 구축
  • 인간 오류 구축 순서
  • 원래 포장을 어떻게 구축하는지 조사하기 어려웠다
  • 이런 여러 가지 문제.
    나는 터보레포가 이 문제를 해결하는 구축 도구라는 것을 깨달았다.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.json
    cd 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 기능을 사용하고 싶은 것은 유도하기 위한 모방 요점이다.
    https://turborepo.org/docs/features/remote-caching

    총결산

  • workspace를 가져오면 쉽게 가져올 수 있음
  • 예의 바른 코드는 간단하게 차분 구축이 가능하지만 외부 참조가 있으면 좀 번거로울 수 있다
  • remote caching 단독으로 사용하기에는 좀 비싸다
  • 내 생각엔 모레포 환경이라면 어쨌든 잡동사니로 깊이 들어가야지.

    좋은 웹페이지 즐겨찾기