webpack 내용 정리. (2)

전의 포스트에 이어서 작성하는 내용입니다.

 

전 포스트에서 웹팩의 주요 속성으로 mode, entry, output, module(loader)이 무엇인지 짧게 작성했습니다.

var path = require('path');
var HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'none',
  entry: './index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  devServer: {
    port: 9000,
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: 'index.html',
    }),
  ],
};

그 외의 웹펙 주요 속성은 빌드 결과물의 재처리를 수행하는 plugins과 devServer 입니다.

 

저번 포스트에서 기술했듯이 mode, entry, output, module(loader) 등의 속성은 webpack, webpack-cli 다운만으로 설정이 가능했지만 plugins, devServer는 별도의 설치가 필요합니다. 

 

이 속성들을 사용하기 위해서는 추가적인 라이브러리를 설치할 필요가 있습니다.

npm i webpack webpack-cli webpack-dev-server html-webpack-plugin -D

 

 

 

5) 플러그인은 loader로 해석되어 최종 빌드된 js 또는 html 파일을 설정에 맞게 수정합니다.

즉, loader가 번들링 전 개발 파일들을 해석해서 변환하는 역할을 한다면 plugins는 해당 결과물을 가공, 수정하는 역할을 합니다.

참고로 위의 설정 코드처럼 plugins는 플러그인을 설정할 객체를 new 키워드로 생성자를 호출해 주입이 가능합니다.

 

plugins: [
  new HtmlWebpackPlugin({
    template: 'index.html'
  })
]

또한, 특정 플러그인을 주입할 때 그 플러그인 내부에서 추가적인 설정이 필요할 수 있습니다.

그럴 때는 위의 코드 처럼 생성자의 인자로 객체를 넣음으로써 설정이 가능합니다.

예시의 객체는 빌드가 완료되어 생성되는 index.html 파일에 로더로 변환 작업이 완료된 css, js 파일 등을 호출하는 태그들이 포함될 수 있도록 지정하는 객체입니다.

즉, 객체에 template 속성이 없다면 빌드로 생성되는 index.html 파일은 변환된 css, js 파일들을 호출하는 태그가 전혀 없는 의미없는 index.html 파일을 생성할 뿐입니다.

이 그림은 webpack 공식 문서에서 제공하는 이미지입니다.

이제 설명된 webpack.config.js의 속성들과 webpack 빌드 프로세스의 관계는 위와 같이 도식화할 수 있습니다.

 

6) 마지막으로 작성할 webpack 속성은 devServer입니다.

지금까지의 속성들 만으로 프론트 작업들을 수행한다면 매번 파일에 수정이 있을 때마다 빌드 작업이 필요할 것입니다.

만약, html 문서의 폰트나 글꼴 등의 작은 수정에도 이를 화면에 반영하려면 빌드 명령어를 입력해 webpack이 새로운 빌드 결과물을 생성하고 브라우저가 이를 다시 읽도록 해야 합니다.

하지만, 지금까지 제가 해온 React, Vue 같은 SPA 프레임워크들은 단순히 Ctrl + S를 입력하거나 새로고침을 하는 것 만으로도 수정된 내용들이 즉시 화면에 반영될 수 있도록 해줍니다.

 

바로 이러한 편리성을 돕는 것이 devServer 속성입니다.

devServer: {
  port: 9000,
},

이 속성의 값으로 객체를 지정하고 객체 내부에 프로세스가 실행될 포트 번호를 지정할 수 있습니다.

우리가 CRA나 vite, Vue-cli 등으로 프로젝트를 생성할 때 자동으로 3000번 서버를 지정해주는 원인이 여기에 있었습니다!

 

그렇다면 포트 번호를 지정해주는건 알겠는데, 어떻게 번들링 전 내용물들을 devServer가 관리할 수 있게 할까요.

Ctrl + S를 입력하거나 새로고침을 하면 수정된 내용들은 모두 화면에 반영되지만, 수정이 반영된 결과 파일들은 빌드를 수행했을 때와 달리 어디에도 생성되지 않습니다.

 

그 해답은 바로 개발모드로 프로젝트 파일들을 컴파일 하고 나면 그 결과물과 매번 수정되어 달라지는 결과물들은 컴퓨터의 내부 메모리에 적재되기 때문이라고 말할 수 있습니다.

즉, 빌드를 했을 때와 달리 개발 모드로 프로젝트를 구동, 수정하면 그 결과물들은 따로 출력되어 별도의 파일이 만들어지지 않고 컴퓨터의 메모리에만 생성되어 컴퓨터 내부적으로만 접근 가능하게 생성되기 때문입니다.

따라서, 이 결과물들은 우리가 직접 보고 수정할 수 없지만 수정되는 부분은 언제나 컴퓨터가 자동으로 업데이트하여 달라진 부분을 우리가 눈으로 확인할 수 있게 해줍니다.

뿐만 아니라, 컴파일 결과물들을 직접적인 빌드 결과물로 저장하는 것은 해당 결과물들을 출력하고 별도의 파일에 저장하는데에 많은 시간과 자원이 소모된다는 큰 단점이 존재하기 때문에 프로젝트를 완성해서 당장 빌드를 해야할 상황이 아니라면 언제나 컴파일 결과물들을 메모리에 임시 저장하는 것이 여러모로 효과적이라고 할 수 있습니다.

 

이렇게 되면 왜 굳이 webpack 에서 mode라는 속성이 존재하고 속성 값에 따라 다른 스크립트를 수행하는 로직들로 나뉘어지는지 더욱 이해할 수 있겠습니다.