Webpack 탄생 배경

웹팩의 배경을 살펴보려면 import/export 가 없던 모듈 이전 상황부터 살펴야 한다.

// sum.js
function sum (a ,b ){return a + b}; // 전역 공간에 sum 함수가 노출된다.

// app.js
sum(1,2); //3

sum.js가 로딩되면 app.js는 sum이라는 함수를 찾은 뒤에 함수를 실행한다.
문제는 다른 파일인데도 불구하고 sum이라는 함수가 전역 공간에 노출되는 것이다.
이럴 경우 app.js 파일 안에서 sum이라는 함수를 선언한 경우 전연 공간에 있는 다른 sum 함수와 충돌이 생기게 된다.

이를 막기 위해 탄생한 게 IIFE이다

IIFE 모듈

즉시 실행 함수 (IIFE) 함수 스코프를 만들어 외부에서 안으로 접근하지 못하도록 한다.

쉽게 말해 스코프가 생기면서 스코프 외부와 이름 충돌을 막을 수 있다.

// sum.js
var math = math || {}; // math 네임스페이스 math가 있으면 할당 없으면 빈 객체

(function () {
    function sum(a, b) {
        return a + b;
    }
    math.sum = sum; // 네임스페이스에 추가
})();

// app.js
math.sum(1,2) //3

같은 코드를 즉시 실행 함수로 감쌌기 때문에 다른 파일에서 안으로 접근할 수가 없다.
'sum'이란 이름은 즉시실행함수 안에 감추어졌기 때문에 외부에서는 같은 이름을 사용해도 괜찮다.

Module

프로그램을 구성하는 구성 요소로, 관련된 데이터와 함수를 하나로 묶은 단위를 의미

Module Bundler

웹 애플리케이션을 구성하는 자원 HTML CSS JAVASCRIPT IMAGES 등을
모두 각각의 모듈로 보고 조합된 하나의 결과물을 만드는 도구를 의미

Webpack

자바스크립트의 모듈화 도구

웹 개발을 하면서 자바스크립트로 작성하는 코드의 양이 늘어나게 되면서,
유지와 보수가 쉽도록 코드를 모듈로 나누어 관리하는 모듈 시스템이 필요해지게 된다.
그러나, 자바스크립트 언어 자체가 지원하는 모듈 시스템이 없기 때문에 이러한 한계를 극복하는 것 중에 하나가 웹팩이다.

Webpack은 common js와 amd의 명세를 모두 지원하는 자바스크립트의 모듈화 도구이다.
웹 개발을 하면서 자바스크립트로 작성하는 코드의 양이 늘어나게 되면서,
유지와 보수가 쉽도록 코드를 모듈로 나누어 관리하는 모듈 시스템이 필요해지게 된다.

Webpack 사용 이유?

1. 자바스크립트 변수 유효 범위 문제

자바스크립트의 기본적으로 전역 범위를 갖는다.
최대한 넓은 변수 범위를 갖기 때문에 어디에서도 접근하기 편리하다.
프로젝트가 규모 ⬆ 복잡도 ⬆ => 변수를 중복 선언하거나 의도치 않은 값을 할당할 가능성 ⬆
웹팩을 사용하면서 바벨의 es6모듈과 웹팩의 모듈 번들링으로 해결 가능하다.

2. 브라우저별 HTTP 요청 숫자의 제약

브라우저에서 한 번에 서버로 보낼 수 있는 HTTP 요청 숫자는 제약되어 있다.
많은 요청을 할 수록 응답 받는 시간이 길어지고 로딩 속도가 그만큼 길어지게 된다.
HTTP 요청 숫자를 줄이는 것이 웹 애플리케이션의 성능 ⬆
사용자가 사이트를 조작하는 시간 ⬆

3. Dynamic Loading & Lazy Loading 미지원

같은 라이브러리를 쓰지 않으면 동적으로 원하는 순간에 모듈을 로딩하는 것이 불가능했다.
웹팩의 Code Splitting 기능을 이용하여 원하는 모듈을 원하는 타이밍에 로딩 가능.

Webpack 동작원리

웹팩의 작동 원리를 우리가 이전에 이용했던 예제로 이용해보자.
우리가 파일을 작성하게 되면 모듈에 대한 의존성들이 생기게 된다.
의존성이 생기게 되는 이유는 app.js 가 sum.js를 Import 해서 계속 계속 불러오는데,
그래서 app.js 이 sum.js 파일을 의존하고 있다고 이해하면 된다.
여기서 웹팩의 역할은 모듈로 연결된 여러 개의 자바스크립트 파일을 하나로 합쳐주는 역할을 한다.

그리고 웹팩이 합쳐준 파일을 bundle이라고 부른다.

Entry

웹팩이 프로젝트 빌드 할 때의 첫 진입점.

Output

빌드가 완료 된 후 결과물 파일의 경로와 파일명을 지정 해준다.

$ node_modules/.bin/webpack --mode development --entry ./src/app.js --output-path dist/main

웹팩은 개발 모드로 실행시켜주며, 첫 진입점은 app.js 파일이고, 결과물을 저장해주는 파일은 dist/main 폴더 안에 저장시킨다.
라는 명령어로 실행시키면 아래의 이미지처럼 실행되면서, 폴더구조에 dist 파일이 생성된 것을 확인할 수 있다.

Loader

자바스크립트 파일이 아닌 웹 자원들을 변환하기 위해 사용.

로더는 타입 스크립트 같은 다른 언어를 자바스크립트 문법으로 변환해 주거나 이미지를 data URL 형식의 문자열로 변환한다.

웹팩은 모든 파일을 모듈로 바라본다.
자바스크립트로 만든 모듈, 스타일시트, 이미지, 폰트까지도 전부 모듈로 보기 때문에
import 구문을 사용하면 자바스크립트 코드 안으로 가져올 수 있다.

Plugin

웹팩의 기본적인 동작에 추가적인 기능을 제공하는 속성

로더가 각 파일 단위로 처리했던거에 비해, 플러그인은 번들 된 결과물을 처리한다.
자바스크립트를 난독화 한다거나, 특정 텍스트를 추출하는 용도로 사용된다.

웹팩을 빌드하고 난 후 번들링 한 파일을 브라우저에서 읽게 되었을때,
큰 파일보다 작게 여러개로 읽는 것이 브라우저 렌더링 할때 더 좋다.
그래서 번들 사이즈를 줄이는 경우에, 대부분 plugin에 대한 설정을 많이 바꾸는 편이다.

Babel

구형 브라우저에서 지원되지 않는 기능들이 지원될 수 잇도록 도와주는 도구

브라우저마다 지원하지 않는 자바스크립트 문법을 transplie 시켜줌.

EX) es6 => es5 , sass => css , ts => js

transpile

한 언어로 작성된 소스 코드를 비슷한 수준의 추상화를 가진 다른 언어로 변환

웹팩을 쓰는 이유 (정리)

ECMAScript2015 이전에는 모듈을 만들기 위해 즉시실행함수와 네임스페이스 패턴을 사용했다. 이후 각 커뮤니티에서 모듈 시스템 스펙이 나왔고 웹팩은 ECMAScript2015 모듈시스템을 쉽게 사용하도록 돕는 역할을 한다.

엔트리포인트를 시작으로 연결되어 었는 모든 모듈을 하나로 합쳐서 결과물을 만드는 것이 웹팩의 역할이다. 자바스크립트 모듈 뿐만 아니라 스타일시트, 이미지 파일까지도 모듈로 제공해 주기 때문에 일관적으로 개발할 수 있다.

참고자료