웹팩이란 

웹팩은 모듈 번들러 입니다.

entry point, 즉 진입파일을 명시해주고 이 진입 파일로 부터 필요한 모듈들을 모두 긁어모아 하나의 파일로 만들어 줍니다.

클라이언트에서는 여러 파일을 요청하지 않고 하나의 파일만 요청함으로써 어플리케이션을 활성화 시킬수 있습니다.

웹팩은 js파일만 인식하고 다룰수 있습니다.

다른 형식의 파일을 load해야할때는 loader를 추가해주어야 합니다.

그래서 html, css, img 등을 처리할때는 각각의 loader를 추가해주어야 합니다.

이 loader들은 비js 파일들을 웹팩내에서 다룰수 있게 해줍니다.

minify, ugilify등을 수행하기 위해서는 terserPlugin과 같은 여러 plugin도 추가할 수 있습니다.

플러그인은 웹팩으로 변환한 파일에 추가적인 기능을 수행하고자 할때 사용합니다.

어플리케이션 내에서 사용하는 외부 라이브러리들이 esm 방식을 이용한다면 사용하지 않는 함수는 번들링 하지 않는 트리쉐이킹이 가능합니다.

code splitting을 적용하면 결과물이 여러 js파일들로 나뉘어지게 됩니다.

처음에 사용하지 않는 모듈들은 나중에 불러오는 것과 같이 추후에 사용이 되어지는 모듈들은 별도의 번들링 된 js 파일로 생성할 수 있습니다.

두 방식 다 하나의 결과물이 너무 커져 클라이언트에서 네트워크의 상황으로 인한 버그 및 에러를 예방할 수 있습니다

모듈이란 

모듈이란 하나의 파일 혹은 함수로 존재하며 각각의 기능을 가질 수 있습니다.

이러한 모듈이 모여 하나의 큰 기능을 수행하고 

이전에 쓰였던 모듈들이 다른곳에서 다른 모듈들과 모여 이전과 다른 큰 기능을 수행할 수 있습니다.

이러한 행태가 가구에 적용된 것이 모듈 가구라 생각합니다.

https://www.smlounge.co.kr/living/article/46702

웹팩이 등장한 이유 웹팩 사용 시에 장점

이러한 웹팩을 이용하면 아래의 문제점들을 해결할 수 있습니다.

1. http/1.x에서의 tcp/ip 연결제한(대부분의 브라우저는 6개까지)으로 인한 파일요청 delay

2. 자바스크립트의 변수 유효 범위

3. 사용하지 않는 코드 관리

1. http/1.x 프로토콜에서는 브라우저에서 tcp/ip 연결에 제한이 걸립니다. 요청별로 스레드를 생성해서 날려도 6개 이상부터는 idle 상태 즉 사용되지 않는 상태가 됩니다. 하나의 화면에서 여러개의 http 요청을 해야한다면 모든 파일이 로드되는 대는 그만큼 delay가 생길수 밖에 없습니다. => 웹팩은 아웃풋 파일을 1개 부터 그 이상 커스텀할수 있어 이러한 브라우저의 제한된 연결을 피해갈 수 있습니다.

2. 자바스크립트의 변수는 기본적으로 전역범위를 가집니다. 따라서 즉시 실행 함수나 클로저를 이용하여 변수가 오염되지 않는 영역을 확보해야 했습니다. 다른 언어처럼 private, public을 클로저, 즉시 실행 함수를 통하여 구현한 것입니다.

=> 모듈은 모듈단위의 범위를 가집니다. a 모듈에서의 a 변수와 b 모듈에서의 a 변수는 서로 다른 범위에 존재하게 됩니다.

3. 사용하지 않는 코드를 번들링 하게 되면 불필요하게 번들링된 파일의 사이즈가 커질수 있습니다. => 웹팩에서는 tree shaking을 이용하여 사용되지 않는 코드는 번들링 결과에 포함하지 않을 수 있습니다. 사용되는 외부 라이브러리가 Esm 방식을 사용하여야 하며 명시적으로 side effect이 발생하지 않는다고 코드를 추가해주면 웹팩이 명시된 부분은 번들링 결과에 포함시키지 않을 수 있습니다. 

바벨 이란

javascript의 버전에 맞게 코드를 변경해주는 트랜스 파일러 입니다.

es6혹은 그 이상으로 된 코드는 es5까지만 돌아가는 브라우저에서 동작하지 않습니다.

따라서 바벨과 같은 트랜스 파일러를 통해 es5 버전의 코드로 변경해주어 여러 브라우저에서 동작하는데 이상이 없게끔 해주어야 합니다.

ts코드를 js코드로 변경해주는 tsc, 타입스크립트 컴파일러 또한 트랜스 파일러 입니다.

웹팩의 주요 속성 4가지

1. entry를 통해 진입하는 파일을 지정할 수 있습니다.

2. output를 통해 결과물에 대한 정보를 입력할 수 있습니다. 

3. loader를 통해 비 javascript 파일을 웹팩에서 인식하게 할 수 있습니다.

4. plugin을 통해 웹팩이 번들링한 결과물에 추가 동작을 수행할 수 있습니다.

출처 : https://joshua1988.github.io/webpack-guide/webpack/what-is-webpack.html#웹팩이란

https://velog.io/@eastshine94/webpack-webpack-설치부터-실행까지

이 포스팅은 아래의 사이트를 번역한 글입니다.(오역과 개인의 생각 또한 포함되어 있습니다.)

https://webpack.js.org/concepts/why-webpack/

왜 웹팩일까요?

웹팩의 사용이유에 대해 이해하기 위해서 번들러가 유행하기 전에 자바스크립트를 웹에서 어떻게 사용하였는지 알아봅시다

브라우저에서 자바스크립트를 실행하기 위한 두가지 방법이 있습니다. 첫번째는 각 기능별로 script를 포함시키는 것입니다. 이 해결책은 확장성이 떨어지는데 너무 많은 script들을 불러오는 것은 네트워크 병목 현상을 가져올 수 있습니다. 

두번째 옵션은 모든 프로젝트 코드를 포함한 거대한 .js 파일을 사용하는 것입니다. 그러나 이것은 범위(변수의 범위를 뜻하는 듯), 크기, 가독성, 유지보수에 문제를 일으킬 수 있습니다.

IIFEs - 즉시 실행 함수들

IIFEs는 거대한 프로젝트에서 범위 문제를 해결하였습니다. script 파일이 IIFE로 감싸여저 있으면 범위가 충돌할 걱정 없이 파일들을 안전하게 합치거나 연결시킬수 있습니다. 

IIFE의 사용은 Make, Gulp, Grunt, Broccoli 혹은 Brunch와 같은 도구들을 등장시켰습니다. 이러한 도구들은 task runner들로 알려져 있으며 모든 프로젝트 파일들을 연결시킵니다.

그러나 파일하나의 변경은 전체를 다시 빌드해야하는 것을 의미합니다. 연결성은 파일간에 script들의 재사용을 쉽게 하였지만 빌드 최적화는 어렵게 만들었습니다. 코드가 실제가 사용되는지 아닌지를 어떻게 알수 있을까요?

lodash로 부터 단지 하나의 함수만 사용할지라도 전체 라이브러리를 추가하고 함께 압축해야 합니다. 코드에서의 의존성을 어떻게 treeshake 할 수 있을까요? 코드 덩어리를 lazy loading 하는 것은 확장성을 떨어뜨리고 개발자의 적지않은 수작업을 요구합니다

Node.js 덕분에 등장한 Javascript Modules의 탄생

Webpack은 브라우저 환경이 아닌 서버와 컴퓨터에서 사용될수 있는 javascript runtime인 Node.js에서 동작합니다. 

Node.js가 등장하고 새로운 시대가 시작되었고 새로운 도전 또한 다가왔습니다. Javascript가 브라우저에서 동작하지 않는데 어떻게 Node application 들은 새로운 코드들을 불러올까요? 추가할수 있는 html 파일들과 script 태그들은 없습니다.

CommonJs가 등장하였고 현재 파일에서 다른 모듈을 불러오고 사용할 수 있는 require을 소개하였습니다. 이것은 필요할때마다 각각의 모듈을 불러옴으로써 범위 이슈를 해결하였습니다.

npm + Node.js + modules – mass distribution 

Javascirpt는 언어, 플랫폼으로서 그리고 빠르게 application들을 만들고 발전시키는 방법으로 세계를 장악하고 있습니다.

그러나 CommonJs를 지원하는 브라우저는 없습니다. live binding은 없습니다. 순환 참조에서 문제들이 있고 동기적인 모듈의 사용과 로딩은 느립니다. 반면 CommonJs는 Nodejs 프로젝트들에서 훌륭한 해결책이 되었습니다. 브라우저들은 module을 지원하지 않았고 그래서 브라우저에서 CommonJs module을 사용할수 있게 해주는 Browserify, RequireJs, SystemJs와 같은 번들러와 도구들이 생겨났습니다.

ESM - ECMAScript Modules

웹 프로젝트들에게 좋은 소식은 모듈이 ECMAScript의 표준으로 체택이 되었다는 것입니다.

그러나 브라우저에서의 지원은 아직 불완전 하고 bundling는 초기 모듈 구현보다 여전히 빠르고 현재 추천되고 있습니다. 

Automatic Dependency Collection 

오래된 Task Runner들과 구글의 Closure Compiler는 모든 의존성을 미리 수동으로 선언해주어야 합니다. 반면 웹팩과 같은 bundler들은 자동으로 build해주고 import되고 export되는 것을 기반으로 의존성 그래프를 추론해줍니다.

Wouldn't it be nice…

모듈을 작성할 수 있을 뿐만 아니라 어떠한 모듈 형식과 resource들과 asset들을 동시에 다뤄야 할까요??

이것이 웹팩의 존재 이유 입니다. 이것은 Javascript 어플리케이션들(ESM과 CommonJs를 지원하는)을 묶을수 있게해주는 도구 이며, 이미지, font, stylesheet들을 지원하도록 확장할 수 있습니다.

웹팩은 성능과 load 시간을 고려합니다. 비동기 chunk 로딩과 미리 가져오는것과 같이 사용자와 프로젝트를 위한 최고의 긍정적 경험을 제공하기 위해 항상 새로운 기능을 추가하거나 개선합니다.