Esbuild, 놀라운 속도💨 유망한 묶음자📈!

나는 이미 JS 묶음기를 몇 년 동안 탔다.여전히 이 공구들을 사용하는 필요성을 확신한다(생산에서 JS 모듈을 포장하지 않았다고 믿지 마라)😅), 나는 자주 그와 함께 논다.특히 성능, 최적화, 사용자 정의 플러그인 사용 문제.
나는 여전히 2021년에 웹 패키지는 나의 웹 응용 프로그램을 묶는 가장 공업화되고 성공적인 해결 방안이라고 생각한다.파라셀과 롤러블 같은 도구가 여전히 좋은 선택이라고 들었습니다.그러나 웹 패키지는 가장 큰 지역 사회를 가지고 많은 프로젝트에 사용될 수 있다.
비록 성능이 매우 나쁘지만, 오늘날 우리는 이 묶음 도구들에 대해 만족을 느낀다.나는 매일 웹 패키지로 해결되는 수천 개의'모듈'프로젝트를 하고 있는데, 이것은 때때로 일종의 고통이다.🥱.

Despite an intensive use of cache and workers, webpack shows some limitations to package large applications.

왜 esbuild가 재미있어 보여요?

나는 간단하게 너에게 설명하는 것보다 더 쉬운 표현 방식을 생각해 내지 못하겠다.

The first time I ran esbuild on my test web app, I thought it crashed when in fact it ran at an absolutely insane speed.

설치가 복잡하지 않습니다.

yarn add -D esbuild

npm install -D esbuild

심지어 NPX

npx esbuild --version

Go에서 작성된 WASM 버전과 주요 아키텍처의 바이너리 파일은 모두 사용할 수 있습니다.esbuild 가장 많은 병렬 솔루션과 더 나은 메모리 관리를 위해 네이티브 Go에 베팅합니다.

향상된 API 설계

전 세계esbuild의 API는 매우 간단합니다. 30분 동안 설정할 수 있는 모든 문서를 읽었습니다.예를 들어, 이것은 웹 페이지의 모든 문서를 읽는 데 필요한 3-4시간이 훨씬 걸리지 않는다.비록 설정이 제한된 것 같지만, 나는 여전히 놀라움을 느낀다.나의 인상은 우리가 묶기에 필요한'정확한 문법'에 정말 가깝다는 것이다.esbuild는 3가지 소비자 모델을 제공합니다.

CLI

esbuild app.jsx --bundle --minify --sourcemap --target=chrome58,firefox57,safari11,edge16

가다

package main

import "github.com/evanw/esbuild/pkg/api"
import "os"

func main() {
  result := api.Build(api.BuildOptions{
    EntryPoints: []string{"app.jsx"},
    Bundle: true,
    MinifyWhitespace: true,
    MinifyIdentifiers: true,
    MinifySyntax: true,
    Engines: []api.Engine{
      {api.EngineChrome, "58"},
      {api.EngineFirefox, "57"},
      {api.EngineSafari, "11"},
      {api.EngineEdge, "16"},
    },
    Write: true,
  })

  if len(result.Errors) > 0 {
    os.Exit(1)
  }
}

JS

require('esbuild').buildSync({
  entryPoints: ['app.jsx'],
  bundle: true,
  minify: true,
  sourcemap: true,
  target: ['chrome58', 'firefox57', 'safari11', 'edge16'],
  outfile: 'out.js',
})

내가 보기에 CLI는 테스트 방면에서 여전히 매우 실용적이지만, 더욱 '공업' 의 응용에서 우리는 여전히 JS나 GO 형식을 더욱 좋아한다.

플러그인 메커니즘

esbuild의 창립자와 핵심 관리자는 자신의 도구가 인터넷 세계의 수요를 100% 만족시키고 싶지 않다는 것을 숨기지 않았다.그러나 이것은 우리가 특정 상황에서 이 도구를 사용할 수 없다는 것을 의미하지 않는다.
다른 패키지에서 보듯이 esbuild 플러그인 메커니즘을 제공하여 많은 일을 할 수 있습니다.모든 특정한 수요를 유지하기 위해서, 창설자는 지역 사회에 의존하여 당신이 필요로 하는 모든 플러그인을 만들 수 있습니다.분명히 지역사회가 거기에 있어요. 제가 보여 드릴게요Evan Wallace.

이 페이지에는 몇 가지 플러그인이 열거되어 있다 가장 재미있는 기능

나는 코드 분할, 주입, 축소 등 내가 보기에 웹 패키지의 핵심 기능들을 여기에 열거하지 않을 것이다.그러나 나는 다른 곳에 없는 기능들에 놀랐다.

이해하기 쉬운 아키텍처

경쟁사에 비해esbuild의 장점은 그 구조에 있다. 간단하게 요약할 수 있다.구축 절차의 병행화와 아스트 읽기 감소를 결합함으로써 이 점을 이해하기 쉽다.읽으세요.
more explanations in the doc

브라우저 대상

기본값esbuild에서 구축할 목표를 정의할 수 있습니다.어떤 등급의 자바스크립트를 원하십니까?
일반적으로 우리는 @babel/preset-env 와 browserlist 같은 도구를 사용하여 생성된 JS가 우리의 목표와 호환되는 것을 확보한다.Babel은 대단합니다. 저는 매일 그것을 사용하지만, 제가 보기에, 다른 묶음 도구를 쌓는 것은 분명히 좋은 해결 방안이 아닙니다.이는 복잡성을 증가시킵니다.

간단한 번들 도구를 배우는 것 외에 맞춤형 투명 도구를 배워야 한다

두 가지 종속성 유지 관리

제3자 도서관을 통해 성능을 낮출 수 있다esbuild의 노름돈)

서버 모드

esbuild의 속도는 매우 빨라서 요청한 컴파일 결과를 포함하는 폴더에 HTTP 서버를 공개할 수 있다.다른 도구는 일반적으로 감시 모드에 의존하여 구축을 시작할 때 변경된 파일을 감시합니다.esbuild에도watch모드가 존재하지만, 내가 보기에는 serve모드가 더 좋다. 브라우저를 새로 고치기만 하면 로컬에서 최신 버전의 응용 프로그램을 얻을 수 있기 때문이다.

require('esbuild')
  .serve(
    {
      servedir: 'www',
    },
    {
      entryPoints: ['src/app.js'],
      outdir: 'www/js',
      bundle: true,
    }
  )
  .then(server => {
    // Call "stop" on the web server when you're done
    server.stop()
  })

그리고 우리는 모든 것을 멈추고 계속할까?

Let’s save time, the answer for me is clearly no.

창조자가 에서 솔직하게 말했듯이 이 프로젝트는 알파 프로젝트로 간주되어서는 안 된다.그러나 이 도구 자체는 이전 세대 패키지의 모든 기능을 잘 대체할 수 없다.내가 특별히 생각한 것은 네이티브 HMR이나 완벽한 분열 코드가 부족하다는 것이다.
그러나 사람들은 이 문제에 대해 침묵을 지켜서는 안 된다.분명히 esbuild는 현재 생태계에서 부족한 매우 강한 점을 가지고 있다.이 지역사회는 여전히 시작 단계에 있고 상당히 활발하며 환매 협의 발행과 홍보 분야의 교류가 매우 재미있다.
이 프로젝트에서 내가 진정으로 좋아하는 것은 성능을 중시하고 간단한 API를 유지하는 조치이다.마지막으로 한 번은 버블러에 1000개의 의존항이 없고, 내 node_modules 폴더에 100Mb가 추가되었으니 주의할 필요가 있다.
마지막으로 내가 말하고자 하는 것은 esbuild 차세대 묶음기가 우리에게 제공하는 유일한 선택이 아니다.나는 FAQ of the doc나 Vite 등의 도구에 대해 이런 분석을 진행할 계획이다.