> 최신 자바스크립트 개발에서 **모듈**은 절대 빠져서는 안 될 용어 중 하나입니다. > 자바스크립트 파일을 기능 단위로 모듈화하고 이것을 하나로 묶어 관리할 방법이 필요하게 되면서 **번들러**의 역할도 중요해졌습니다. > 번들러를 사용하면 소스 코드를 모듈별로 작성할 수 있도 모듈간 또는 외부 라이브러리의 의존성도 쉽게 관리할 수 있습니다. > > _- [번들러_toast ui](https://ui.toast.com/fe-guide/ko_BUNDLER)_ Perl을 개발한 Larry Wall은 [프로그래머에 필요한 3대 덕목](https://www.mimul.com/blog/three-great-virtues-of-a-programmer/)을 재밌게 설명한 적이 있습니다. 그 중 하나가 `게으름` 입니다. 여기서 말하는 게으름은 일반적인 게으름과는 다른 의미로 사용됩니다. 게을러지기 위해서 불필요한 반복 작업을 구조화하고 줄이며 재사용 성을 생각하고 자동화 할 수 있는 곳이 있는지 찾아서 그 방법을 생각해야 된다고 말합니다. ~~의자에 앉아 티비 채널을 돌리기 위해 리모컨을 개발한 것처럼 말이죠~~ 자바스크립트 개발을 번들러 없이도 할 수 있습니다. 하지만 매 프로젝트 개발 시 문제들을 제거하기 위한 동일한 보일러 플레이트를 작성한다던지 시간을 들여 중복성을 방어한다던지... 하는 행위가 반복되고 그로 인해 개발 생산성이 떨어집니다. 한 마디로 게을러 질 수 없습니다. 그럼 번들러 의 어떤점이 `게으름`을 갖게 해주는 걸까요? # 번들러 > 번들러는 의존성이 있는 모듈 코드를 하나(또는 여러 개)의 파일로 만들어주는 도구이다. 번들러는 크게 3가지 이유로 사용됩니다. 1. 모든 브라우저 환경에서 완전한 모듈 시스템을 지원하기 위해서 2. 모듈 간 종속성 관리, 외부 라이브러리 의존성 관리를 쉽게하기 위해서 3. 종속성 순서와 이미지 asset, css asset 등을 포함한 assets를 효율적으로 load하기 위해서 그 외에도 다양한 기능들을 포함하여 개발 생산성을 획기적으로 높이도록 여러 번들러들이 개발되고 발전해왔습니다. # 처음엔 처음 번들러는 자바스크립트 모듈을 브라우저에서 실행할 수 있는 단일 자바스크립트 파일로 번들링하기 위함 이었습니다. ```html {2-6} ``` 위와 같은 경우에 어플리케이션 동작을 위해서 **5**번의 http 요청을 보냅니다. (script준비 시간 * 5 + http요청응답 시간 * 5) (이해를 위해 각 script parsing 시간을 동일하게 적용합니다.) ```html {2} ``` 만약 하나의 파일로 합친다면 더 나은 결과를 보일 것입니다. (script준비 시간 * 5 + http요청응답 시간 * 1) http connection overhead문제를 해결하기 위해 HTTP/2를 사용하더라도 동일 테스트결과에서 하나의 파일로 합친 것이 더 나은 결과를 보입니다. (HTTP/2는 하나의 연결로 지속해서 진행되도록 되어있습니다. 더 많은 정보는 [여기서](https://www.seonest.net/posts/HTTP...-%EA%B7%B8%EA%B2%83%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC) 작성되어있습니다.) # 발전 그러면 어떻게 `dist/bundle.js`를 생성해낼까요? 몇가지 해결해야 될 중요한 점이 있습니다. - 어떻게 포함될 `file`의 순서를 관리할 것인가? - 어떻게 `file`간 naming conflict를 막을 것인가? - 어떻게 사용되지 않는 `file`을 찾아낼 것인가? 이 문제를 해결하기 위한 정보는 다음과 같습니다. - 어떤파일이 다른파일에 의존적인가? - 파일로 부터 내보내진 인터페이스가 무엇인가? 그리고 - 다른 파일에 의해 사용된 인터페이스가 어떤것인가? 이 정보만 안다면 우리는 위 문제들을 해결할 수 있습니다. 우리가 필요한 것은 파일 간의 관계를 설명하는 `선언적 방법` 입니다. 그리고 이것은 자바스크립트 모듈 시스텝으로 이끌었습니다. 처음엔 번들링만을 위한 번들러 였습니다. 그러나 단순히 번들하는 것을 넘어서 사용하지 않는 코드를 제거하는 기능(Tree shaking), 적당한 코드 분리(Code splitting), 필요한 시점에서 로딩하기(lazy loading) 등의 최적화 작업에 대한 필요성도 높아졌습니다. 또한 배포 시에 css를 구형 브라우저에서도 동작할 수 있게끔 전처리하는 등 이러한 작업을 자동화 해주는 태스크 러너(grunt, gulp 등) 기능도 있었습니다. 최근 번들러는 이러한 다양한 기능들을 자체에서 제공하거나 플러그인 형태로 사용할 수 있기 때문에 올인원 패키지 처럼 이용할 수 있습니다. 번들러 내부에서 최적화를 동시에 처리할 수 있기 때문에 효율적으로 가능하고, 다양한 기능도 한번에 제공가능하니 당연한 흐름이었던 것 같습니다. 현재는 웹 어플리케이션을 개발할 때 별도의 추가적인 툴 없이 Webpack과 같은 모듈 번들러 툴 하나로 처리하는 이유이기도 합니다. # 대장들 ![bundler-npm-trend.png](https://files.seonest.net/images/qnfqnfqnf/post/25/bundler-npm-trend.png) 모듈 번들러는 **웹팩(Webpack)**, **롤업(Rollup)**, **파셀(Parcel)**, **스노우팩(Snowpack)**, **esbuild** 등이 있습니다. 아마 대부분 많이 들어봤던 번들러 일 것 같아요. 각 모듈 번들러들은 큰 틀의 목표는 같지만 각자 특징과 장단점을 가지고 있습니다. 가지고 있는 특징들을 잘 살펴보고 필요한 번들러를 사용하는 것도 하나의 좋은 방법이 될 것 같아요. [bundler.tooling.report](https://bundlers.tooling.report/#overview) ![bulder-tooloing-report.png](https://files.seonest.net/images/qnfqnfqnf/post/26/bulder-tooloing-report.png) 먼저 가장 많이 사용되고 있는 Webpack에 대해서 먼저 살펴보고자 합니다. # Webpack ![webpack logo](https://raw.githubusercontent.com/webpack/media/3e52c178e6ad2428585a2cbf5d22d6dbe0697f0f/logo/logo-on-white-bg.svg) > Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset. > > Webpack은 모듈 번들러입니다. > 주요 목적은 브라우저에서 사용할 수 있게 자바스크립트 파일을 번들링하는 것입니다. > 추가로 리소스나 asset에 대해 transforming, bundling, packaging 또한 가능합니다. > > _- [webpack_github](https://github.com/webpack/webpack#webpack)_ 웹팩은 대부분 듣거나 경험해보셨을 것 같아요. 그만큼 현재 가장 널리 쓰이는 번들러이며, 안정적인 모듈 번들러 입니다. (현재 버전은 웹팩 5 까지 나왔습니다.) CommonJS, AMD, ES Module 모듈을 모두 지원하며, 자바스크립트 뿐만 아니라 CSS, Image 파일 등 리소스의 의존성도 관리합니다. (웹 애플리케이션을 구성하는 모든 자원을 모듈로 인식합니다.) 예를 들어, CSS/Sass/Less 내부에서 사용하는 @import , url(...) 구문이나 HTML 내부의 `

` 태그를 모두 관리합니다. 또한 트랜스파일 외 Minify/Uglify, Banner, CSS Preprocess 작업을 자동화해 주는 Task Runner 기능을 포함하고 있습니다. 이 외에도 Code Spliting과 Dynamic imports(Lazy Loading), Tree Shaking, Dev Server(Node.js Express 웹서버) 등 효율적인 자바스크립트 개발을 위한 기능을 제공하고 있다. ~~(많은 것을 포함하고 있는 것만큼 설정할 것도 많습니다.)~~ ## webpack.config.js 웹팩에는 중요한 설정 4가지가 있습니다. 1. entry: 번들링해야될 파일의 진입점 2. output: 번들링하고나서 결과의 경로 3. loader: 모듈 로더(자바스크립트를 포함한 리소스(css, image, file 등)를 변환할 때 쓸 것들) 4. plugin: 추가적으로 결과물 형태를 바꾸고자할 때 쓸 것들 ### 1. entry ```js {3} // webpack.config.js module.exports = { entry: './src/index.js' } // ./src/index.js import LoginView from './LoginView.js'; import HomeView from './HomeView.js'; import PostView from './PostView.js'; function initApp() { LoginView.init(); HomeView.init(); PostView.init(); } initApp(); ``` webpack.config.js가 있는 경로에서 하위 src/index.js 파일을 번들링 하겠다 라는 뜻입니다. 위 처럼 싱글 페이지 어플리케이션(SPA)같은 경우는 파일이 1개로 존재할 수 있겠지만 그렇지 않다면 여러 개 진입점도 가능합니다. ```js entry: { login: './src/LoginView.js', main: './src/MainView.js' } ``` ### 2. output ```js {3-5} // webpack.config.js module.exports = { output: { filename: 'bundle.js' } } ``` webpack.config.js가 있는 경로에서 bundle.js 파일을 번들링 결과 파일로 생성하겠다 라는 뜻입니다. entry와는 다르게 object 형태로 filename 등을 지정해주어야 합니다. ```js {5-8} // webpack.config.js var path = require('path'); module.exports = { output: { filename: 'bundle.js', path: path.resolve(__dirname, './dist') } } ``` __dirname은 현재 경로(webpack.config.js가 있는 경로이겠죠)에 대한 경로를 알려주는 Nodejs에서 제공하는 변수입니다. `webpack-sample` 이라는 프로젝트 안에서 설정하였다고 생각해보게씁니다. 위 output 경로를 풀어보자면 `/Users/jhseo/webpack-sample/dist/bundle.js` 가 될 것입니다. 추가로 배포 시에 브라우저 캐싱을 막기 위하거나 디버깅을 위해 해쉬값을 파일명으로 추가한다던가 id를 부여한다던지 등을 웹팩에서 기본적으로 제공하는 옵션으로 만들 수 있습니다. ```js {4,11,18,25} // [name] 결과 파일 이름에 entry 속성을 포함하는 옵션 module.exports = { output: { filename: '[name].bundle.js' } }; // [id] 모듈 id를 포함하는 옵션 module.exports = { output: { filename: '[id].bundle.js' } }; // [hash] 빌드 시 마다 고유 hash 값을 붙이는 옵션 module.exports = { output: { filename: '[name].[hash].bundle.js' } }; // [chunkhash] 각 청크된 파일 내용을 기준으로 생성된 hash 값을 붙이는 옵션 module.exports = { output: { filename: '[chunkhash].bundle.js' } }; ``` ### 3. loader 엔트리, 아웃풋에 기반한 모든 자원들(css, image, file 등)에 대해서 변환할 때 쓰이는 모듈 로더 입니다. 가령 css 파일을 자바스크립트에서 import 하여 사용한다고 가정해보겠습니다. ```js // app.js import './common.css'; console.log('css loaded'); /* common.css */ p { color: blue; } // webpack.config.js module.exports = { entry: './app.js', output: { filename: 'bundle.js' } } ``` 위 대로 동작하면 빌드 시 에러가 나게 됩니다. common.css 를 해석할 수 없기 때문에 적절한 loader를 설정해주어야 합니다. ```js // webpack.config.js module.exports = { entry: './app.js', output: { filename: 'bundle.js' }, module: { rules: [ { test: /\.css$/, use: ['css-loader'] } ] } } ``` module 이라는 객체에 rules라는 배열에 test와 use를 가진 object를 추가했습니다. - test: 로더를 적용할 파일 유형(regular expression으로 보통 작성합니다.) - use: 해당 파일에 적용할 로더 이름 다시 말해 파일명이 .css로 끝나는 파일들에 대해서 css-loader를 적용하겠다라는 의미입니다. 엔트리에 해당하는 모든 파일에 대해서 적용할 수 있기 때문에 전체 파일을 대상한다고 생각하시면 됩니다. (그래서 상당히 많은 로더들이 있습니다.) 자주 사용되는 로더는 - [babel-loader](https://webpack.js.org/loaders/babel-loader/#root) - [sass-loader](https://webpack.js.org/loaders/sass-loader/) - [style-loader](https://webpack.js.org/loaders/style-loader/) - [postcss-loader](https://webpack.js.org/loaders/postcss-loader/) - [ts-loader](https://github.com/TypeStrong/ts-loader) > raw-loader, url-loader, file-loader는 webpack 5에서 deprecated 되고 [asset module](https://webpack.js.org/guides/asset-modules/) 로 추가적인 로더 설치 없이 사용가능합니다. 등이 있습니다. 특정 파일에 대해서 여러 개의 로더를 한 번에 적용할 때에는 순서를 주의해야 합니다. 로더는 기본적으로 오른쪽에서 왼쪽으로 적용됩니다. ```js {5} module: { rules: [ { test: /\.scss$/, use: ['css-loader', 'sass-loader'] } ] } ``` .scss 파일에 대해 sass-loader를 먼저 적용을 하고 css-loader를 적용한다는 뜻입니다.(이렇게 해야만 정상 동작가능하기 때문에 순서를 주의해서 작성해야 합니다.) 위와 같이 배열 형태 뿐 만아니라 object 형태로도 작성가능합니다. (오른쪽에서 왼쪽으로, 아래에서 위로) ```js {5-12} module: { rules: [ { test: /\.scss$/, use: [ { loader: 'style-loader' }, { loader: 'css-loader', options: { modules: true } }, { loader: 'sass-loader' } ] } ] } ``` .scss 파일에 대해 sass 컴파일 하고 css-loader를 통해 파일에 불러옵니다. style-loader는 인라인 `

Bundler

Bundle(3) - Module Bundler