새로운 세대의 빌드 도구 비교

작년에 많은 새로운 개발자 도구가 착륙했으며 지난 몇 년 동안 Webpack, Babel, Rollup, Parcel, Create-React-App을 포함하여 프론트 엔드 개발을 지배 한 도구의 발 뒤꿈치를 물고 있습니다.

이 새로운 도구는 정확히 동일한 기능을 수행하도록 설계되지 않았으며 각각 달성하려는 다른 것들과 그곳에 도착할 수있는 기능이 있습니다. 차이점에도 불구하고 이러한 도구는 공통 목표를 공유합니다. 개발자 경험을 향상시킵니다.

목차

1. 이 도구가 지금 모두 도착한 이유는 무엇입니까?
2. 기존 도구와 어떻게 다릅니 까?
3. 실험
4. 비슷한 기능
5. Esbuild
6. 스노우 팩
7. vite
8. WMR
9. 기능 비교
10. 마무리

구체적으로, 나는 각각을 평가하고, 그들이하는 일, 왜 필요한지, 그리고 사용 사례를 설명하고 싶습니다. 나는 비교가 항상 공평한 것은 아니라는 것을 알고 있습니다. 다시 말하지만,이 기사에서 우리가보고있는 것은 직접 경쟁자와 다릅니다. 실제로 Snowpack과 Vite는 실제로 특정 작업을 위해 후드 아래에서 Esbuild를 사용합니다 . 우리의 목표는 작업을보다 쉽게 ​​수행하기 위해 작업을 실행하는 개발자 도구의 환경을 더 잘 볼 수 있다는 것입니다. 이런 식으로, 우리는 어떤 옵션이 무엇인지, 어떻게 쌓이는지를 알 수 있으므로 필요할 때 최선의 선택을 할 수 있습니다.

물론,이 모든 것은 React and Preact를 사용한 나의 경험에 의해 채색 될 것입니다. 이 프레임 워크 라이브러리에 더 익숙하지만 다른 프론트 엔드 프레임 워크에 대한 지원을 살펴 보겠습니다.

이 새로운 개발자 도구에 대한 훌륭한 기사, 스트림 및 팟 캐스트가 많이있었습니다. 더 많은 맥락에서 추천 할 ShopTalk 쇼 에피소드가 몇 개 있습니다. 에피소드 454는 Vite와 Episode 448이 WMR과 Snowpack의 제작자를 특징으로합니다. 이 에피소드에서 눈에 띄는 것은 개발자 환경을 현대화하기 위해 이러한 도구를 구축하는 데 엄청난 양의 작업이 시작되었다는 것입니다.

이 도구가 지금 모두 도착한 이유는 무엇입니까?

부분적으로, 이러한 도구는 JavaScript 툴링 피로에 대한 반응으로 도착하고 있다고 생각합니다.이 기사에서 2016 년에 JavaScript 학습에 관한이 기사에서는 잘 포착 된 것입니다. 또한 단일 바닐라 JavaScript 파일을 작성하고 자신의 코드 라인을 작성하기 전에 200 대의 메가 바이트의 툴링 종속성을 다운로드 해야하는 중간 기반을 채 웁니다. 그들은 의존성 목록없이 배터리로 제공되며 JavaScript 생태계에서 붕괴 계층의 경향의 일부입니다.

Snowpack, Vite 및 WMR은 모두 브라우저의 기본 JavaScript 모듈에 의해 활성화되었습니다. 2018 년에 Firefox 60은 기본적으로 ECMAScript 2015 모듈로 출시되었습니다. 그 이후로 모든 주요 브라우저 엔진은 기본 JavaScript 모듈을 지원했습니다. Node.js는 또한 2019 년 11 월에 기본 JavaScript 모듈을 배송했습니다. 우리는 여전히 2021 년에 Native JavaScript 모듈의 가능성을 찾고 있습니다.

기존 도구와 어떻게 다릅니 까?

개발 서버에 WebPack, Rollup 또는 Parcel을 사용하든, 도구는 소스 코드 및 Node_Modules 폴더에서 전체 코드베이스를 번들로 연결하면 Babel, TypeScript 또는 PostCSS와 같은 빌드 프로세스를 통해 이들을 실행 한 다음 번들 코드를 브라우저로 푸시합니다. 이 모든 것이 작업을 수행하고 캐싱 및 최적화에 들어간 모든 작업 후에도 더 큰 코드베이스에서 개발 서버를 크롤링 할 수 있습니다.

Snowpack, Vite 및 WMR 개발 서버는이 모델을 따르지 않습니다. 대신 브라우저가 가져 오기 명령문을 찾아 모듈에 대한 HTTP 요청을 할 때까지 기다립니다. 이 요청이 이루어진 후에 만 ​​도구는 요청 된 모듈과 모듈의 가져 오기 트리의 리프 노드로 변환 한 다음 브라우저에 제공됩니다. Dev 서버로 밀어 붙이는 과정에서 작업이 적기 때문에 많은 속도가 높아집니다.

이 사진에서 Esbuild가 누락 된 것을 알 수 있습니다. 번들러는 가장 먼저 번들 입니다. 다른 도구의 방식을 묶는 것은 측면도가 아닙니다. 대신, Esbuild는 비싼 변환을 피하고 병렬화를 활용하고 GO 언어를 사용하여 매우 빠르게 코드를 프로세스합니다.

실험

React Docs에서 예제 앱 중 하나를 가져 와서이 기사에서 다루는 각 도구와 함께 재구성했습니다. 내가 한 프로젝트는 Yogita Verma의 스냅 샷이었습니다. 다음은 원래 Repo에 대한 링크와 각각 다른 빌드 도구를 사용하는 4 가지 버전의 Snap Shot과 함께 내 리포지션 링크입니다. 나중에 각 빌드 단계의 출력을 비교합니다. 이 응용 프로그램을 재건하면 React 라우터 및 Axios를 포함한 도구로 꽤 표준 반응 의존성을 가져 오는 개발자 경험을 테스트 할 수있었습니다.

비슷한 기능

각 개별 도구의 세부 사항에 들어가기 전에 모두 상자에서 다음 기능을 지원합니다 (다양한 정도).

• 기본 JavaScript 모듈에 대한 일류 지원
• TypeScript 컴파일 (유형 확인은 아님)
• JSX
• 확장 성을위한 플러그인 API
• 내장 개발 서버
• CSS 묶음 및 CSS-in-JS 라이브러리 지원

이러한 모든 도구는 TypeScript를 JavaScript로 컴파일 할 수 있지만 유형 오류가 있더라도 그렇게합니다. 적절한 유형 확인을 위해서는 root javaScript 파일에 TypeScript를 설치하고 TSC -NOEMIT를 실행하거나 편집기 플러그인을 사용하여 유형 오류를 시청해야합니다.

자, 각 도구를 살펴 보겠습니다.

Esbuild

Esbuild는 Evan Wallace (Figma의 CTO)에 의해 만들어졌습니다. 주요 특징은 노드 기반 번들러 (자체 벤치 마크)보다 빌드 단계 10 × -100 × 더 빠른 빌드를 제공한다는 것입니다. Create-React-App과 같은 개발자 편의성을 많이 제공하지 않습니다. 그러나 Create-React-App-esbuild, Estrella 및 Snowpack을 포함하여 이러한 격차를 메우는 점점 더 많은 Esbuild 스타터가 팝업되어 있으며 빌드 단계에 Esbuild를 사용합니다.

Esbuild는 매우 새롭습니다. 아직 1.0 버전에 도달하지 않았으며 생산 사용 준비가되지 않았지만 멀지 않았습니다. 직관적 인 JavaScript 및 명령 줄 API를 스마트 기본값으로 제공합니다.

사용 사례

Esbuild는 Bundler World의 완벽한 게임 체인저입니다. Esbuild와 Node Bundlers의 속도 차이가 곱하는 대형 코드베이스에서 가장 유용 할 것입니다. Esbuild가 1.0을 쳤을 때 대형 생산 사이트에서 매우 유용 할 것이며 빌드가 완료되기를 기다리는 시간을 많은 시간을 절약 할 것입니다. 불행히도, 대형 생산 현장은 Esbuild가 안정 될 때까지 기다려야합니다. 그 동안 측면 프로젝트에서 번들링에 속도를 더하는 것이 좋습니다.

Esbuild의 번개 빠른 속도는 당신이하고있는 모든 일에 대한 보너스가 될 것입니다. 빌드가 실행되기를 기다리는 데 소요되는 시간이 줄어들면서 항상 개발자 경험에 좋을 것입니다! 이로 인해 빠른 응용 프로그램을 프로토 타이핑하는 경우 Esbuild보다 높은 수준으로 시작하고 싶을 수도 있습니다. 그렇지 않으면 JavaScript 생태계에서 기대하는 편의를 얻기 전에 종속성을 끌어 내고 환경을 구성하는 데 시간을 소비해야합니다. 또한 번들의 크기를 최대한 최소화하려면 롤업 및 테러를 사용하여 약간 더 작은 번들 크기를 생성 할 수 있습니다.

설정

나는 Esbuild에서 Esbuild, React 및 Reactdom을 설치하는 NPM의 순진한 방식으로 Esbuild에서 React 프로젝트를 시작하기로 결정했습니다. src/app.jsx 파일과 dist/index.html 파일을 만들었습니다. 그런 다음 다음 명령을 사용하여 앱을 dist/bldle.js 파일로 컴파일했습니다.

 ./node_modules/.bin/esbuild src/app.jsx-bundle-platform = 브라우저 -outfile = dist/bundle.js

브라우저에서 index.html을 호스팅하고 열었을 때, 나는 "흰색 사망 스크린"과 "uppher 참조 오류 : 프로세스가 정의되지 않은"콘솔 오류를 만났습니다. 문서와 CLI는 모두이를 방지하기 위해해야 ​​할 일을 정확하게 설명하지만 초보자에게는 약간의 "gotcha"일 수 있습니다. 왜냐하면 번들링이 반응 할 때 추가 논쟁이 필요하기 때문입니다.

 -define : process.env.node_env = \ "Production \"

또는 인용문을 피하기 위해 이와 같이 작성된 NPM 스크립트에 Esbuild를 포함하는 경우 :

 -define : process.env.node_env = \\\ "Production \\\"

이 정의 인수는 노드 환경 변수를 기대하는 브라우저에 대해 번들로 제공되는 라이브러리에 필요합니다. Vue 2.0도 이것을 기대합니다. 기본적으로 브라우저에 대한 환경 변수와 선박을 기대하지 않기 때문에 Preact와 동일한 문제가 없습니다.

정의 인수로 명령을 실행 한 후, 나의“Hello World”React App은 완벽하게 작동했습니다. JSX는 .jsx 파일을 사용하여 상자 밖으로 작동합니다. 즉, RECT를 수동으로 가져와야하고 JSX는 React.createElement로 변환됩니다. 그러나 JSX에서 자동 가져 오기 및/또는 prect에 대한 JSX를 구성하는 방법이 있습니다.

용법

Esbuild는 개발 서버를위한 -서비스 옵션을 제공합니다. 이것은 파일 시스템을 우회하고 메모리에서 직접 모듈을 제공하여 브라우저가 이전 버전의 모듈을 가져 오지 않도록합니다. 그러나 Live/Hot Reloading은 포함되지 않으므로 저장 후 브라우저를 새로 고칠 수 있으며 이상적인 경험이 아닙니다.

새로 출시 된 시계 기능을 사용하기로 결정했으며 소스 파일이 저장 될 때마다 Esbuild에게 코드를 재 컴파일하라고 지시합니다. 그러나 저장된 변경 사항을 확인하려면 서버가 여전히 필요합니다. Luke Jackson의 서버와 같은 개발 서버 패키지를 가져올 수 있습니다.

 NPM 설치 서버-사브 디브

그런 다음 Esbuild JavaScript API를 사용하여 서버로 시작하고 동시에 Esbuild의 시계 모드를 실행할 수 있습니다. 프로젝트의 루트에서 watch.js라는 파일을 만들어 봅시다.

 // watch.js
const esbuild = require ( "esbuild");
const servor = 요구 사항 ( "서보");

esbuild.build ({
  // 옵션을 전달하여 여기에서 esbuild ...
  EntryPoints : [ "src/app.jsx"],
  Outdir : "Dist",
  정의 : { "process.env.node_env": ' "Production"'},
  시청 : 사실,
});

비동기 기능 serv () {
  Console.log ( "서버 실행 : http : // localhost : 8080/");
  서버를 기다리고 있습니다 ({
    // 여기에서 옵션을 서보에게 전달합니다 ...
    브라우저 : 사실,
    루트 : "dist",
    포트 : 8080,
  });
}

제공하다();

이제 명령 줄에서 Node Watch.js를 실행하십시오. 이것은 우리에게 멋진 Dev 서버를 제공하지만 다시는 핫 모듈 교체 또는 빠른 새로 고침을 제공하지 않습니다 (예 : 클라이언트 측 상태는 보존되지 않음). 그러나 이것은 내 테스트 요구에 충분했습니다.

파일을 저장할 때마다 전체 응용 프로그램을 재조정하더라도 Esbuild가 느려지기 전에 꽤 큰 응용 프로그램이 필요합니다. 이 툴링을 설정 한 후 변경 사항으로부터 즉각적인 피드백을 받고있었습니다. 내 컴퓨터는 2012 년부터 인텔 i7을 사용하므로 확실히 최고의 기계가 아닙니다.

Live Reload와 일부 React 기본값을 갖춘 미리 구성된 Esbuild 버전이 필요한 경우이 리베르를 복제 할 수 있습니다.

지원되는 파일

Esbuild는 스타일 인 경우 JavaScript로 CSS를 가져올 수 있습니다. 기본 출력 JavaScript 파일과 동일한 이름의 출력 파일로 CSS를 컴파일합니다. 또한 기본적으로 CSS @import 문을 번들로 만들 수도 있습니다. CSS 모듈에 대한 지원은 없지만 계획이 있습니다.

Esbuild 용 플러그인 커뮤니티가 점점 커지고 있습니다. 예를 들어 VUE 단일 파일 구성 요소 및 Svelte 구성 요소에 사용할 수있는 플러그인이 있습니다.

Esbuild는 JSON 파일과 함께 작동하여 구성없이 JavaScript 모듈에 묶을 수 있습니다.

또한 데이터 URL로 변환하거나 출력 폴더로 복사하는 옵션으로 JavaScript의 이미지를 가져올 수도 있습니다. 이 동작은 기본적으로 활성화되지 않지만 Esbuild 구성 객체에 다음을 추가하여 두 옵션 중 하나를 활성화 할 수 있습니다.

 로더 : { '.png': 'dataurl'} // JS 번들의 데이터 URL로 변환
로더 : { '.png': 'file'} // 폴더 출력을 복사합니다.

코드 분할은 진행중인 작업 인 것으로 보이지만 대부분 ESM 출력 형식으로 구성되어 있으며 프로젝트의 우선 순위 인 것처럼 보입니다. 또한 나무 흔들림은 기본적으로 Esbuild에 내장되어 있으며 끄질 수 없습니다.

생산 빌드

Esbuild 명령에서 "Minify"및 "Bundle"옵션을 사용하면 롤업/Terser 파이프 라인만큼 작은 번들이 생성되지 않습니다. Esbuild는 가능한 몇 가지 패스로 코드를 통과하기 위해 일부 번들 크기 최적화를 희생하기 때문입니다. 그러나 차이는 상당히 무시할 수 있으며 프로젝트에 따라 번들링 속도의 증가에 대한 가치가 있습니다. Snap Shot Application의 클론에서 Esbuild는 롤업과 Terser를 사용하는 Vite가 생산 한 165KB보다 크지 않은 177kb의 번들을 만들었습니다.

전반적인

Esbuild는 매우 강력한 도구입니다. 그러나 설정 설정에 익숙해지면 어려울 수 있습니다. 더 필요한 경우 Esbuild를 사용하는 다음 도구 인 Snowpack을 살펴보십시오.

스노우 팩

Snowpack은 Skypack과 Pika의 제작자가 빌드 도구입니다. 그것은 멋진 개발 서버를 제공하며“undundled development”철학으로 만들어졌습니다. 문서를 인용하려면 다음과 같이 말합니다.

기본적으로 Snowpack의 빌드 단계는 파일을 단일 패키지로 번들로하지 않지만 브라우저에서 실행되는 Unbundled esmodules를 제공합니다. Esbuild는 실제로 거기에 종속성으로 포함되어 있지만 아이디어는 JavaScript 모듈을 사용하고 필요할 때 Esbuild와 함께 번들 만 사용하는 것입니다.

Snowpack에는 JavaScript 프레임 워크와 함께 사용하기위한 가이드 목록과 많은 템플릿을 포함하여 매우 매끄러운 문서가 있습니다. 가이드 중 일부는 여전히 진행중인 작업이지만 React를위한 것과 같은 다른 가이드는 훌륭하고 명확합니다. 또한 Snowpack이 Svelte를 일류 시민으로 취급하는 것처럼 보입니다. 나는 실제로 Svelte Summit 2020에서 Rich Harris의“Futuristic Web Development”대화의 Snowpack에 대해 처음 들었습니다. 즉, 다가오는 Svelte Meta-Framework Sveltekit은 Snowpack에 의해 구동되어야했지만 이후 Vite로 전환되었습니다 (다음에 검토 할 것입니다).

사용 사례

Unbundled Deployment를 두 배로 늘리려면 Snowpack이 좋은 선택입니다. 소수의 모듈로 소스 코드를 작성하고있을 수 있습니다. 이것은 당신이 undundled 빌드로 큰 요청 폭포를 만들지 않는다는 것을 의미합니다. 번들링의 추가 복잡성과 기술 부채가 필요하지 않으면 Snowpack은 훌륭한 선택입니다. 프론트 엔드 프레임 워크를 서버 렌더링 또는 정적 애플리케이션에 점진적으로 채택하는 것이 좋습니다. 노드 생태계에서 가능한 한 적은 툴링을 가져 오지만 여전히 선언적 프론트 엔드 프레임 워크의 이점을 얻을 수 있습니다.

둘째, Snowpack은 Esbuild 주변의 훌륭한 포장지라고 주장합니다. Esbuild를 사용해 보려고하지만 프론트 엔드 프레임 워크를위한 개발 서버 및 사전 작성된 템플릿을 원한다면 Snowpack으로 잘못 갈 수 없습니다. 스노우 팩 구성의 빌드 단계에서 esbuild를 활성화하면 좋습니다.

현재 서있는 것처럼 Snowpack은 Create-React-App과 같은 제로 구성 도구를 가장 잘 대체하지 않을 것이라고 주장합니다. 플러그인을 가져 와서 큰 응용 프로그램이 있고 슈퍼 팬시 최적화 된 생산 준비 단계가 필요한 경우 직접 구성해야하기 때문입니다.

설정

명령 줄로 뛰어 들어 Snowpack으로 프로젝트를 시작합시다.

 mkdir snowpackproject
CD SnowPackProject
기본값이 포함 된 NPM Init #Fill 
NPM 스노우 팩을 설치하십시오

이제 package.json에 다음을 추가합시다.

 // package.json
"스크립트": {
  "시작": "Snowpack Dev",
  "빌드": "스노우 팩 빌드"
},

다음으로 구성 파일을 작성하겠습니다.

 // Mac 또는 Linux
SnowPack.config.js를 터치합니다
// Windows
new-item snowpack.config.js

Snowpack의 가장 마술적인 부분은 구성 파일에 무고한 키 값 쌍을 설정할 때 발생한다고 생각합니다. 예를 들어 구성 파일에 붙여 넣습니다.

 // snowpack.config.js
module.exports = {
  PackageOptions : {
    "소스": "원격",
  }
};

출처 : 원격은 스트리밍 imports 라는 것을 활성화합니다. 스트리밍 가져 오기를 사용하면 스노우 팩이 베어 가져 오기 (예 : 'react'에서 React에서 가져 오기)를 Skypack에서 CDN 가져 오기로 변환하여 NPM 설치를 우회 할 수 있습니다.

앞으로도 index.html 파일을 만들어 봅시다.

 



  <meta charset="utf-8">>
  <title> 스노우 팩 스트리밍 수입 </title>


  <div> </div>
  
  <script type="module" src="app.js"> </script>

위 내용은 새로운 세대의 빌드 도구 비교의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!