초기 컴퓨터 시절, 배경
그 때 당시 컴퓨터는 코드를 직접 작성, 실행해 원하는 결과물을 얻거나
코드 작성 후 프로그램으로 저장하느 디스크를 삽입하고 마운트하고 나서야 원하는 작업 시작
The Kaypro 10은 다양한 번들을 하드웨어와 같이 제공하는 마케팅 전략 !
텍스트 편집기나 스프레드시트 소프트웨어 등 여러 편리한 소프트웨어를 한번에 제공
번들링
- 여러 제품이나, 코드, 프로그램을 묶어서 패키지로 제공하는 행위
- 사용자에게 웹 애플리케이션을 제공하기 위한 파일 묶음
사용자가 브라우저를 열고 주소를 입력하면, 해당 주소에서 프론트엔드 개발자가 번들링한 여러 파일을 받는다. 이 파일을 브라우저가 실행하여 멋진 웹 애플리케이션을 사용자에게 제공하게 된다.
번들리의 필요성
- 두개의 .js파일에서 같은 변수를 사용해 충돌 일어남
- 딱 한 번 불러오는 프레임워크 코드가 8MB라, 인터넷 속도가 느린 국가의 모바일 환경에서 사용자 불편
- 번들 파일 사이즈를 줄이기 위해 파일의 공백을 모두 지웠다 => 가독성이 너무 떨어져 코딩하기가 어려워 결국 공백 되돌려 코딩
- 배포 코드가 너무 읽기 쉬워 개발을 할 줄 아는 사용자가 프론트엔드 애플리케이션을 임의로 조작하여 피해가 발생한다.
결론
번들링 작업에서는 필연적으로 용량을 줄이고, 파일을 통일하는 툴링 작업이 필요하다. 즉, 소프트웨어를 잘 만들어도 사용자에게 배포하기 위해 번들링이 꼭 필요하다.
Webpack
webpack은 2022-07 현재, 프론트엔드 애플리케이션 배포를 위해 가장 많이 사용하는 번들러다. 대규모 유저에게 웹 애플리케이션을 제공하기 위해서 사용됨
Webpack이란
- 여러 개의 파일을 하나의 파일로 합쳐주는 모듈 번들러를 의미
- 모듈 번들러란, html,css,js 등의 자원을 전부 각각의 모듈로 보고 이를 조합해 하나의 묶음으로 번들링하는 도구
모듈 번들러의 등장
- 모던 웹으로 발전 js 코드 양 많이 증가
- 대규모 의존성 트리를 가지고 있는 웹이 등장하면서 세분화된 모듈 파일 폭발적 증가
- js특성에 따라 발생하는 변수들의 스코프 문제 해결해야함
- 각 자원 호출할 때 생기는 네트워크 쪽 코스트도 신경써야함
=> 이 복잡성에 대응하기 위해 하나의 시작점으로부터 의존성을 가지는 모듈을 모두 추적해 하나의 결과물 내는 모듈 번들러 등장 !
webpack에서의 모듈
- webpack에서 모듈은 html css js .jpg .png 같은 이미지 파일들도 전부 포함한 포괄적 개념
=> 주요 구성 요소인 loader를 통해 다양한 파일도 번들링이 가능
빌드와 번들링
빌드
개발이 완료된 앱을 배포하기 위해 하나의 폴도로 구성하여 준비하는 작업
- react 앱 기준, npm run build 실행하면, React build 작업 진행, index.html 파일에 압축되어 배포에 최적화 상태 제공
번들링
파일을 묶는 작업. 이 파일들은 의존적 관계에 있는 파일들이며(import, export) 그 자체, 혹은 내부적으로 포함되어 있는 모듈을 의미한다. 즉, 모듈 간의 의존성 관계를 파악해 그룹화 하는 작업이다.
Webpack의 필요성
- 웹 애플리케이션의 빠른 로딩 속도와 높은 성능을 위함
- 웹 페이지를 구성하는 코드의 양이 많을수록 웹 페이지 로딩 속도, 성능 저하
속도를 개선하기 위해, 브라우저에서 서버로 요청하는 파일의 숫자를 줄여야 했다. Webpack을 이용해 같은 타입의 파일들은 묶어서 요청 및 응답을 받아 네트워크 코스트가 획기적으로 줄어든다.
또, webpack loader를 사용하면 일부 브라우저에서 지원하지 않는 jSES6의 문법들을, ES5로 변환해주는 babel-loader를 사용할 수 있게 된다. 그 외 vue-loader, scss-loader등의 loader도 사용할 수 있기 때문에 최선의 개발 방식을 선택할 수 있다.
Webpack4 버전 이상부터 Develoment, Production 두 가지 모드 지원!
여기서 Production 모드로 번들링을 진행할 경우, 코드 난독화, 압축, 최적화(Tree Shaking) 작업을 지원하기도 한다.
=> 상용화 된 프로그램을 사용자가 느끼기에 더욱 쾌적한 환경 및 보안까지 신경쓰면서 노출시킬 수 있다
웹팩의 핵심 컨셉
Target
기본값은 web, 이외에도 다양한 환경 컴파일 가능.
esX를 넣으면 지정된 ECMAScript 버전으로 컴파일 할 수 있다.
module.exports = {
target: ["web", "es5"],
};해당 config 파일에서 es5를 배열안에 넣었기 때문에, 이 config 파일은 브라우저와 동일한 환경에서 사용하기 위해 컴파일 할 것이고, 작성된 코드를 es5 버전으로 컴파일 하겠다고 지정한 것이다. Browser Compatibility와 연관된 속성이다.
Entry(엔트리)
개발자가 작성한 코드의 "시작점"
React도 index.js에서 HTML 엘리먼트 하나에 React코드를 적용하는 것부터 시작!
Entry 속성은, webpack이 내부 디펜던시 그래프 생성을 위해 사용해야 하는 모듈이다. webpack은 이 Entry를 기반으로 직간접적으로 의존하는 다른 모듈과 라이브러리를 찾아낼 수 있다.
// 기본값
module.exports = {
...
entry : "./src/index.js",
};
// 지정값
module.exports = {
...
entry : "./src/script.js",
}webpack 설정해서 entry속성을 이용해 다른 entry point를 지정할 수 있다.
Output(출력)
기본 출력 파일의 경우에는 ./dist/main.js로 , 생성된 기타 파일의 경우에는 ./dist 폴더로 설정
const path = require('path');
module.exports = {
...
output: {
path: path.resolve(__dirname, "docs"), // 절대 경로로 설정을 해야 합니다.
filename: "app.bundle.js",
clean: true
},
};
위의 예제에서는 output.filename과 output.path 속성을 사용하여 webpack에 번들의 이름과 내보낼 위치를 알리고 있음. path 속성을 사용할 때는 path 모듈을 사용해야만 합니다.
Loader(로더)
Webpack은 기본적으로 JavaScript와 JSON 파일만 이해한다.
그러나 loader를 사용하면 Webpack이 다른 유형의 파일을 처리 or 유효한 모듈로 변환해 애플리케이션에 사용, 디펜던시 그래프에 추가할 수 있다.
module.exports = {
...
module: {
rules: [
{
test: /\.css$/,
use: [MiniCssExtractPlugin.loader, "css-loader"],
exclude: /node_modules/,
},
],
},
};상위 수준에서 loader는 webpack 설정에 몇 가지 속성을 가집니다.
- test: 변환이 필요한 파일들을 식별하기 위한 속성
- use: 변환을 수행하는데 사용되는 로더를 가리키는 속성
- exclude: 바벨로 컴파일하지 않을 파일이나 폴더를 지정. (반대로 include 속성을 이용해 반드시 컴파일해야 할 파일이나 폴더 지정 가능)
여기서 test와 use 속성은 필수 속성.
이런 속성을 넣어 규칙을 정하기 위해서는 module.rules 아래에 정의해야 한다.
Plugins(플러그인)
Plugins를 사용하면 번들을 최적화하거나 에셋을 관리하고, 또는 환경변수 주입 등의 광범위한 작업을 수행
const webpack = require('webpack');
const HtmlWebpackPlugin = require("html-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = {
...
plugins: [
new HtmlWebpackPlugin({
template: path.resolve(__dirname, "src", "index.html"),
}),
new MiniCssExtractPlugin(),
],
};플러그인을 사용하기 위해서는 require()를 통해 플러그인을 먼저 요청
=> plugins 배열에 사용하고자 하는 플러그인을 추가
대부분의 플러그인은 사용자가 옵션을 통해 지정가능. 다른 목적으로 플러그인을 여러 번 사용하도록 설정할 수 있기 때문에 new 연산자를 사용해 호출하여 플러그인의 인스턴스를 만들어준다.
위의 예제에서 html-webpack-plugin 은 생성된 모든 번들을 자동으로 삽입하여 애플리케이션용 HTML 파일을 생성했다. mini-css-extract-plugin은 CSS를 별도의 파일로 추출해 CSS를 포함하는 JS 파일 당 CSS 파일을 작성해주게끔 지원한다.
Optimization(최적화)
Webpack은 버전 4부터는 선택한 항목에 따라 최적화를 실행
module.exports = {
...
optimization: {
minimizer: [
new CssMinimizerPlugin(),
]
}
};최적화하기 위해 다양한 옵션이 지원이 되는데, minimize와 minimizer 이 대표적이다.
- minimize : TerserPlugin 또는 optimization.minimize에 명시된 plugins로 bundle 파일을 최소화(=압축)시키는 작업 여부를 결정
- minimizer : defualt minimizer을 커스텀된 TerserPlugin 인스턴스를 제공해서 재정의할 수 있습니다.
위의 예제에서는 mini-css-extract-plugin 에 관련된 번들을 최소화하도록 지시하고 있습니다.
웹팩과 리액트
리액트가 번들링이 필요한 이유
프레임워크로써 앵귤러가 주류였으나, 필요한 코드의 양이 많고, 배우는데도 오래걸리고, 번들 사이즈가 커지고, 성능 문제도 점점 커져갔다.
=> 리액트는 라이브러리라, 코드가 가볍다.
리액트
리액트 개발진은 개발자가 어떤 기술 스택을 사용할지 미리 가정하지 않는다. 그래서 개발자가 새로운 코드를 다시 작성할 필요 없이 기능을 추가할 수 있다.
=> 이로 생기는 문제는, 리액트만 알아서는 개발하기가 어려움
=> 우리는 지금까지 react, react-dom, react-scripts, create-react-app, react-router-dom, storybook, styled-components등 많은 부가 라이브러리를 설치하고 활용법을 교육했다.
=> 리액트 개발진이 create-react-app 이라는 툴 체인을 개발해 초급 리액트 개발자가 쉽게 리액트에 접근할 수 있도록 했다. 근데 그러다보니, 사용되는 라이브러리 목록이 엄청나게 되어버림
{
// ...
"dependencies": {
"@babel/core": "^7.16.0",
"@pmmmwh/react-refresh-webpack-plugin": "^0.5.3",
"@svgr/webpack": "^5.5.0",
"babel-jest": "^27.4.2",
"babel-loader": "^8.2.3",
"babel-plugin-named-asset-import": "^0.3.8",
"babel-preset-react-app": "^10.0.1",
"bfj": "^7.0.2",
"browserslist": "^4.18.1",
"camelcase": "^6.2.1",
"case-sensitive-paths-webpack-plugin": "^2.4.0",
"css-loader": "^6.5.1",
"css-minimizer-webpack-plugin": "^3.2.0",
"dotenv": "^10.0.0",
"dotenv-expand": "^5.1.0",
"eslint": "^8.3.0",
"eslint-config-react-app": "^7.0.1",
"eslint-webpack-plugin": "^3.1.1",
"file-loader": "^6.2.0",
"fs-extra": "^10.0.0",
"html-webpack-plugin": "^5.5.0",
"identity-obj-proxy": "^3.0.0",
"jest": "^27.4.3",
"jest-resolve": "^27.4.2",
"jest-watch-typeahead": "^1.0.0",
"mini-css-extract-plugin": "^2.4.5",
"postcss": "^8.4.4",
"postcss-flexbugs-fixes": "^5.0.2",
"postcss-loader": "^6.2.1",
"postcss-normalize": "^10.0.1",
"postcss-preset-env": "^7.0.1",
"prompts": "^2.4.2",
"react-app-polyfill": "^3.0.0",
"react-dev-utils": "^12.0.1",
"react-refresh": "^0.11.0",
"resolve": "^1.20.0",
"resolve-url-loader": "^4.0.0",
"sass-loader": "^12.3.0",
"semver": "^7.3.5",
"source-map-loader": "^3.0.0",
"style-loader": "^3.3.1",
"tailwindcss": "^3.0.2",
"terser-webpack-plugin": "^5.2.5",
"webpack": "^5.64.4",
"webpack-dev-server": "^4.6.0",
"webpack-manifest-plugin": "^4.0.2",
"workbox-webpack-plugin": "^6.4.1"
},
"devDependencies": {
"react": "^18.0.0",
"react-dom": "^18.0.0"
},
"optionalDependencies": {
"fsevents": "^2.3.2"
},
"peerDependencies": {
"react": ">= 16",
"typescript": "^3.2.1 || ^4"
},
"peerDependenciesMeta": {
"typescript": {
"optional": true
}
}
}나같은 삐약이 말고,, 전문 개발자들은 직접 웹팩을 설치해 하나씩 리액트와 그에 필요한 라이브러리 설정을 하기 시작했다.
그래서 결론은?
리액트는 프론트엔드 라이브러리로서 최소한의 기능을 제공하고자 가볍게 만들어졌지만, 시간이 지나면서 아이러니하게도 개발자의 다양한 니즈를 충족시키기 위해 더 많은 라이브러리를 필수적으로 사용해야만 했고, 개발자가 필요한 이런저런 라이브러리를 골라서 번들링 할 수 있는 웹팩이 필요하게 됐다.
리액트 개발에 꼭 필요한 라이브러리
react, react-dom
react : 리액트 컴포넌트와 Hooks, 라이프 사이클에 대한 정보가 모두 들어있다.
react-dom : 이 리액트 코드를 브라우저에 보여줄 수 있다.
babel
브라우저는 js는 읽지만 JSX는 읽을 수 없다. babel이 jsx를 js로 변경해주어 번들링 했기 때문이다. 참고로 babel은 JSX를 js로 변경해 entry에서 불러올 수 있게 만들어줬기 때문에 로더의 일종으로 볼 수 있다.
css-loader
import 'aaa.css'같이 입력해도 css가 적용된다.
리액트 개발에 도움이 되는 라이브러리
react-hot-reloader
react-hot-reloader는 webpack-dev-server처럼 저장할 때 마다 변경사항을 개발 환경에 적용해주는 라이브러리입니다. 추가적인 특징이 있다면 react-hot-reloader는 리액트 상태를 유지시킨다.
eslint
eslint는 JavaScript로 개발 시 자주 접하는 에러를 방지하기 위한 린터입니다. eslint 역시 많은 config와 plugin이 있는데, 이를 잘 조합하면 리액트에서 자주 접하는 에러를 미리 발견하는데 도움이 됩니다.
prettier
prettier는 JavaScript로 개발 시 통일성 있게 코드 형식을 맞출 수 있게 도와주는 툴입니다. eslint와 조합해서 통일된 코드 형식까지 강요할 수도 있습니다.
