Webpack - 1

Doodream·2022년 6월 5일

webpack 2.0 웹팩

webpack

목록 보기

1/1

웹팩 이란 무엇인가?

왜 웹팩은 사용되어지기 시작했나요?

ServerSide Templates

서버에서 완전히 완성된 정적인 페이지를 클라이언트에 보내줍니다.
어떤 언어로 만들어졌는지는 중요하지 않습니다.
사용자가 원하는 모든 기능과 데이터가 완전히 들어있는 페이지를 보내줍니다.

Single Page Application

SPA는 방대한 JS 파일을 가지고 있습니다. 사용자에게 보여지기 위한 HTML을 구성할 JS 코드 더미들을 가지고 있습니다.
사용자의 브라우저에서 서비스에 대한 전체 JS 코드를 가져옵니다. 즉, 서버에서 사용자 클라이언트로 엄청난 양의 JS 코드를 보내줍니다.

이러한 차이점으로 인해 SPA는 SST 보다 역동적인 웹페이지 구성과 풍부한 사용자 경험을 가지게 됨으로서 점점 SPA 의 사용이 많아졌습니다.

하지만 SST, SSR의 경우 JS파일 코드량을 보내는 양이 SPA에 비해 훨씬 적었습니다.

여기에서 우리가 Webpack을 사용하는 이유가 있습니다. SPA에서 이렇게 엄청나게 많은 JS코드를 쉽게 처리하게 해줍니다.

Module

엄청난 양의 JS 코드 파일들이 있다고 생각해봅시다. 이러한 파일들을에서 특정 부분을 업데이트 하기란 굉장히 어렵습니다. 이렇게 큰 코드베이스 문제를 해결하기 위해서 Module이라는 개념이 나왔습니다.
Module 이라는 것은 소량의 코드가 포함된 JS 파일 입니다. 이러한 모듈 기반의 코드에서는 큰 파일 몇개 보다 작은 파일들을 많이 갖는 것을 중요하게 생각합니다. 이러한 방식은 코드의 접근 방법에서 우리가 접근할 코드를 훨씬 명확하게 명시해줍니다. (물론 적당히 분할 해야겠지만.)

너무 많은 파일들로 분할 관리 했을 때의 문제

코드가 실행되는 순서를 고민해야합니다.
- 너무 잘게 나뉘어져 있는경우 코드가 어떻게 실행되는지 명확해지지 않습니다.
너무 파일을 잘게 나누면 브라우저에서 각각의 파일을 요청할떄 HTTP 요청으로 받아오는데 이는 통신 한번당 붙는 헤더와 트레일러로 인해 효율이 좋지 않은 통신을 하게 됩니다. 즉, 큰 파일을 한번에 받고 오는 것보다 작은 파일들을 여러번 요청하고 받아오는게 더 느립니다. 즉, 페이지 로딩 시간이 길어집니다.

위 와 같이 너무 많이 잘게 잘려진 파일들을 하나의 큰 파일로 모아서 조립해주는 것이 Webpack 입니다. (올바른 실행 순서 보장)

위와 같은 이유가 가장큰 이유이며 다른 부수적인 효과로서 CSS, ES2015 코드로 변환하여 오래된 환경에서 안정적으로 코드를 돌아가게 해줍니다.
웹팩은 작은 파일들의 순서를 이어줍니다.

모듈팩 방식의 종류

CommonJS : nodeJS에서 자주사용합니다.
AMD ( Async Module Definition ) : 프론트 애플리케이션에 자주사용합니다. 코드의 다른 모듈이 비동기적으로 로드 될 수 있는 곳입니다.
ES2015 모듈 : ES5 문법으로 변형 시켜주면 import export로 모듈을 불러올 수 있는 최신 모듈 시스템 입니다.

Webpack 설치

먼저 디렉토리를 하나 만들고 npm init을 이용해서 프로젝트를 개설합니다.

그안에 npm install --save-dev webpack@2.2.0-rc 명령어를 통해서 npm 패캐지 관리자로부터 webpack 모듈을 설치합니다.

루트 디렉토리에 webpack.config.js 파일을 만듭니다.
이파일의 이름은 특별합니다.

webpack을 실행하면 node.js 환경에서 실행됩니다. webpack이 실행되면서 루트디렉토리에서 webpack.config.js 파일을 찾게 됩니다. 그리고 파일의 내용을 읽게 되면서 [코드베이스에서 일부 작업을 수정합니다.] ...?

우리 프로젝트의 구성은 다음과 같습니다.

index.js <- sum.js

index.js 파일은 다른 파일에 export 하지 않습니다. 다른 모듈들을 받기만 하는 의존적이지 않는 파일입니다. 이러한 진업점의 특징을 가진 것을 엔트리 파일이라고 합니다.

즉, 응용프로그램이 브라우저에서 시작될때 시작되어야 하는 첫번째 파일이라는 뜻입니다.
다시말하면 엔트리파일이 모듈 프로세스 구축의 시작을 담당합니다.

webpack은 이렇게 시작되는 첫번째 파일인 엔트리파일을 시작으로 엔트리파일이 어떤 파일을 필요로 하는지 트리구조를 그리며 모듈 구축 프로세스의 트리를 형성합니다. 연결된 require문으로 크롤링을 시작하는 것입니다.

// webpack.config.js 에서도 require 문이 실행될 수 있습니다.
// 이부분은 webpack이 실행시켜주는 것이 아니라 node.js 런타임에서 실행됩니다.
// path를 사용하는 이유는 node.js에서 path 자체가 옳게 설정되었는지 확인 시켜줍니다. 여러 OS들을 지원합니다.

const path = require('path');

const config = {
    // 상대경로
    entry: './src/index.js',
    output: {
        // 절대경로
        path: path.resolve(__dirname, 'build'),
        filename: 'bundle.js'
    }

};

module.exports = config;

entry 속성과 output 속성을 지정하지 않으면 웹팩은 동작하지 않습니다.

entry : 위에서 말한 진입점 파일의 상대경로를 명시합니다.
output : webpack에서 index.js 파일을 통해서 만든 번들 파일을 저장할 파일 이름과 절대 경로를 명시합니다.
path라는 것은 현재 디렉토리의 절대경로를 가져오는 Nodejs의 기본 모듈입니다.

위와 같이 entry와 output을 지정한 네이밍과 경로는 아주 일반적인 관습들입니다.

./package.json

{
  "name": "udemy_webpack",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build": "webpack"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "webpack": "^2.2.0-rc.0"
  }
}

위 부분에서 scripts 에 해당하는 부분의 명령어를 위와 같이 바꿔주었습니다. scripts 안의 명령어들은 npm run 이라는 명령어로 수행가능합니다. 즉, build 라는 명령어로 webpack이라는 명령어를 실행가능 하게 해줍니다. npm run build 명령어를 실행하게 되면 webpack이 실행되면서 build.js 파일이 생성될 것 입니다.

왜 이렇게 명령어 스크립트 따로 만들어서 할까요?

웹팩에서 제공해주는 명령어를 사용하려면 먼저 webpack을 전역적으로 설치를 해야합니다. 이렇게 webpack을 설치하면 실행할 때 저장소에서 하나의 웹팩만을 선택하여 실행하게 됩니다. 전역적인 webpack 설치는 여러 버전의 웹팩을 사용하기에 굉장히 번거로워 집니다. 따라서 로컬의 특정부분 예를 들면 지금 있는 프로젝트에만 특정 버전의 웹팩을 설치하는데 node.js 프로젝트에서 웹팩을 설치 할때 -save--dev 라는 옵션으로 이 프로젝트 한정으로 특정 웹팩 버전이 설치되도록 하였습니다. 여기서 webpack은 node_modules라는 폴더 안에 모듈이 설치되는데 npm run 이라는 명령어는 해당 모듈에 있는 webpack에 명령을 수행시킬수 있습니다.