babel, webpack 그리고 polyfill

Babel

바벨은 초기에 ES6가 등장하고 대부분의 브라우저에서 지원하지 않는 문법을 사용할 수 있도록 ES5로 변환해주기 위해 등장했다. 하지만 현재에는 리액트의 JSX, 타입스크립트와 같은 정적 언어 그리고 최신 문법에 대한 트랜스파일러 자리잡았다.

그럼에도 바벨이 모든 최신 문법을 사용할 수 있진 않다. 화살표 함수, Promise, JSX 문법들을 트랜스파일 하기 위해선 폴리필과 플러그인에 대한 도움을 받아야한다.

프리셋(preset)이라 하여 목적에 맞는 플러그인의 집합들이 생겨났는데 @babel/plugin-transform-arrow-functions @babel/plugin-transform-template-literals @babel/preset-react @babel/preset-env @babel/preset-typescript @babel/preset-jest 등 다양한 프리셋들이 있다.

babel-cli 를 이용할 수 있지만 웹팩에서 babel-loader로 지정하고 여러 설정과 함께 웹팩을 실행하는게 개발할 떄 일반적으로 사용된다.

Polyfill

바벨이 ES6를 ES5로 트랜스파일 하더라도 전부다 지원하지 않는다는 것은 알았을 것이다. 바벨은 컴파일 타임에 코드를 트랜스파일 하는데, 반면 polyfill은 런타임에 등록되지 않은 메서드나 기능을 주입해준다.

프로젝트 내 babel.config.js 를 통해 타깃 환경에 필요한 구문 변화(syntax transform), 브라우저 폴리필(browser polyfill)을 제공하는 @babel/preset-env를 preset에 추가해서 다음과 같이 사용한다.

여기서 targets 옵션을 주어 타깃 브라우저에 필요한 플러그인만 삽입하도록 브라우저 점유율 또는 명시적인 버전으로 설정합니다.

//browserslist-compatible query
{
  "presets": [
    ["@babel/preset-env", {
      "targets": "> 0.25%, not dead"
    }],
  ]
}

//mininum version
{
  "presets": [
    ["@babel/preset-env", {
      "targets": {"chrome": "58", "ie": "11"}
    }],
  ]

useBuiltIns는 옵션 값으로 usage, entry, false(기본값)을 사용할 수 있고 false 이외의 옵션을 주면 core-js 모듈을 가져오는 코드를 브라우저에 맞게 삽입/수정합니다.

entry의 경우 core-js/stable과 regenerator-runtime/runtime 모듈을 전역 스코프에 직접 삽입한 경우에만 가능하고 해당 설정을 통해 core-js의 하위 특정 모듈들의 import문으로 변경시켜서, 타깃 환경에 필요한 폴리필만 전역 스코프에 추가되도록 한다.

//in
import "core-js";

//out
import "core-js/modules/es.string.pad-start";
import "core-js/modules/es.string.pad-end";

usage의 경우 실제 사용한 폴리필만 삽입합니다. import문 변경이 아니라 전역 스코프에 core-js/stable과 regenerator-runtime/runtime을 삽입하지 않아도 된다.

//in
var a = new Promise();
var b = new Map();

//out(실제 사용한 폴리필만 삽입하도록 import 문이 추가된다)
import "core-js/modules/es.promise";
import "core-js/modules/es.map";
var a = new Promise();
var b = new Map();

카카오 테크 에는 entry옵션을 줘서 사용하다가 전역스코프에 변수가 충돌해서 처리하는 일도 소개되어있다.

Webpack

자바스크립트는 초기에 모듈(module) 없이 등장을 했습니다. 하지만 자바스크립트가 웹 생태계에서 대형 어플리케이션을 만들 목적이 생기고 node.js가 등장하며 하나의 파일에서 거대한 코드를 작성할 수 없어 require함수와 module.export를 쓰는 commonJS가 등장하고 이 때부터 npm의 등장으로 module을 공유할 수 있게 되었습니다.

 

출처: https://wormwlrm.github.io/2020/08/12/History-of-JavaScript-Modules-and-Bundlers.html

webpack

모듈들이 많아지며 파일 전송 속도 문제, 중복 이름 문제들로 인해 번들러가 등장하는데 그 중 가장 많이 사용하는 Webpack은 다음과 같은 특징이 있습니다.

1. 같은 타입(HTML, CSS, ...)의 파일을 묶어서 요청 받기 때문에 네트워크 비용을 줄일 수 있습니다. 

2. 여러 모듈의 의존성을 파악해 사용하지 않은 파일을 포함시키지 않는 등 번들의 크기를 줄여 페이지 로딩을 더욱 빠르게 합니다.

3. production 모드 빌드하는 경우 코드 난독화, 압축, 최적화 작업을 지원합니다.

4. 필요한 플러그인 예로 babel-loader, sass-loader plugin등을 추가하여 주입할 수 있습니다.

5. devserver를 제공해서 hot-reload, proxy, source-map로 편한 DX를 제공합니다.