webpack-dev-server 는 작은 Node.js Express 서버로 , webpakc-dev-middleware를 사용하여 웹팩번들 서버를 제공합니다.. 이것은 또한 Sock.js를 통하여 서버에 접속하는 작은 런타임을 제공합니다.

서버는 이벤트들에 반응하는 편집상태(개발되는 상태)에 관한 정보를 클라이언트에게 제공하며, 필요에 따라서 여러가지 모드를 선택할 수 있습니다.

var path = require("path");
module.exports = {
  entry: {
    app: ["./app/main.js"]
  },
  output: {
    path: path.resolve(__dirname, "build"),
    publicPath: "/assets/",
    filename: "bundle.js"
  }
};

당신은 app폴더를 당신의 초기 엔트리 포인트로 설정할 수 있습니다. 이 엔트리포인트에서 bundle.js를 번들링하여 build폴더에 가져다가 놓을 것입니다.

NOTE : webpack-dev-server 는 분리된 NPM 패키지입니다. 당신은 npm install webpack-dev-server 로 설치할 수 가 있습니다.

Content Base

웹팩개발서버는 특정한 content base를 지정해주지 않는 이상 현재 디렉터리의 파일들을 serving 할 것입니다. 

$ webpack-dev-server --content-base build/

이러한 설정을 통해서 웹팩개발서버는 당신의 build폴더에 있는 정적 자원들을 서빙할 것입니다. 웹팩개발서버가 당신의 소스파일들을 감시하고, 그것들이 변경될때마다 번들을 재컴파일할 것입니다.

수정된 번들은 publicPath에 설정된 상대경로의 메모리로부터 serve될 것입니다. 수정된 번들은 당신이 설정한 output디렉터리에 쓰여지지 않을 것입니다. 번들이 이미 같은 URL 경로에 있다면 메모리의 번들이 우선권을 기본적으로 우선권을 가지게 됩니다.

당신의 번들파일을 불러오기 위해, bundle 폴더에서 정적으로 제공될 index.html을 만들 필요가 있습니다. 여기 예제가 있습니다.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
  <script src="assets/bundle.js"></script>
</body>
</html>

기본적으로 당신의 앱을 실행시키기 위하여 localhost:8080에 접속합니다만 여기 예제에서 publicPath를 사용하여서 localhost:8080/assets/로 가게 됩니다.

자동적 갱신 Refresh

웹팩개발서버는 페이지를 자동으로 갱신하기 위한 여러가지 모드를 제공합니다.

Iframe 모드 : iframe안에 페이지가 내장되어서 바뀔때마다 다시 불러와집니다. Inline 모드 : 작은 웹팩개발서버 클라이언트엔트리가 번들에 추가가 되어서 바뀔때마다 페이지를 갱신합니다.

각각의 모듈은 또한 Hot Module Replacement 를 지원하는데 핫모듈대체에서 번들은 변경이 일어났을 때알아차릴 수 있습니다. 핫모듈대체 런타임은 실행되는 앱에 모듈들을 업데이트하고서 그것들을 주입할 수가 있게 됩니다.

IFrame 모드

아이프레임 모드를 사용하기 위하여 추가적인 설정이 필요하지 않습니다. 단지 http://«host»:«port»/webpack-dev-server/«path» 를 브라우저에다가 치면 됩니다.

Inline 모드

인라인모드를 사용하기 위해서

이것들은 웹팩 설정에 웹팩개발서버 클라이언트 엔프리 포인트를 추가하게 됩니다. URL에 필요한 변경사항은 없습니다. 단지 브라우저에 http://«host»:«port»/«path»를 치면 됩니다.

위의 설정이라면 http://localhost:8080/index.html.

노드.js API와 inline 모드

웹팩개발서버 설정에는 inline:true라는 설정이 없습니다. 왜냐하면 웹팩개발서버 모듈은 웹팩설정에 접근할 수 있지 않기 때문입니다. 대신에 웹팩설정에 웹팩개발서버 클라이언트 엔프리 포인트를 반드시 추가해야합니다.

이러한 것을 하기 위해, 단순히 다음의 엔프리포인트를 추가해보세요. webpack-dev-server/client?http://«path»:«port»/

다음의 설정 : 

var config = require("./webpack.config.js");
config.entry.app.unshift("webpack-dev-server/client?http://localhost:8080/");
var compiler = webpack(config);
var server = new WebpackDevServer(compiler, {...});
server.listen(8080);

HTML에서의 inline 모드 HTML 페이지에 웹팩개발서버 클라이언트 스크립트에 대한 참조를 더하기 위한 옵션도 있습니다. 

<script src="http://localhost:8080/webpack-dev-server.js"></script>

Hot Module Replacement (핫 모듈 대체로 부르기로;;)

웹팩개발서버와 핫 모듈 대체를 활성화하기 위해 커맨드 라인에 --hot옵션을 지정할 수가 있습니다. 이것은 웹팩 설정에 핫모듈대체플러그인을 추가합니다.

웹팩개발서버와 핫모듈대체를 사용하는 가장 쉬운 방법은 인라인모드를 사용하는 것입니다.

CLI에서 인라인모드를 통한 핫모듈대체

특별히 필요한 것 없이 --inline --hot 이 연관된 일을 자동으로 처리해줍니다. 웹팩개발서버의 CLI가 자동으로 당신의 설정에 특정 webpack/hot/dev-server 를 추가해줄 것입니다.

단지 http://«host»:«port»/«path» 에 들어가보고 마법이 일어나는 것을 보세요.

당신은 브라우저 로그에서 다음과 같은 로그를 볼 수 있을 겁니다.

[HMR] Waiting for update signal from WDS...
[WDS] Hot Module Replacement enabled.

[HMR]로 시작하는 메시지들은 webpack/hot/dev-server 모듈로부터 왔습니다. [WDS]로 시작하는 메시지들은 웹팩 개발서버 클라이언트로부터 왔습니다.

정확한 output.publicPath를 지정해주는 것이 중요합니다. 그렇지 않으면 핫모듈 업데이트 청크들이 업데이트되지 않습니다.

node.js API와 핫모듈 대체

인라인모드와 비슷하게, 유저는 반드시 웹팩 설정을 좀 고쳐야 합니다. 세 가지의 수정이 필요합니다

설정은 다음과 같습니다. 

var config = require("./webpack.config.js");
config.entry.app.unshift("webpack-dev-server/client?http://localhost:8080/", "webpack/hot/dev-server");
var compiler = webpack(config);
var server = new webpackDevServer(compiler, {
  hot: true
  ...
});
server.listen(8080);

“safe write” 를 지원하는 IDE/에디터로 작업하기

많은 에디터가 “safe write” 속성을 지원하고 이것이 기본설정이라는 것을 생각해보면, 이것은 개발서버가 파일들을 올바르게 감시하는 것을 못하게 합니다. "Safe write"는 변경된 내용이 실제 파일에 직접적으로 바로 저장되지 않고 일시적인 파일에 일시적으로 저장되어서 저장작업이 성공적으로 완료되었을 때 실제 파일을 바꾸는 것을 의미합니다. 이러한 행동은 실제 파일이 지워지기 때문에 파일 감시기가 추적을 하지 못하게 합니다. 이러한 문제를 방지하기 위하여 당신은 에디터에서 “safe write”를 비활성화해야 합니다.

Proxy

웹팩개발서버는 http-proxy-middleware 를 사용하여서 선택적으로 분리된거나 외부의 백엔드서버에 요청을 프록시 처리할 수 있습니다. 예제 설정은 다음과 같습니다. 

proxy: {
  '/api': {
    target: 'https://other-server.example.com',
    secure: false
  }
}

// In webpack.config.js
{
  devServer: {
    proxy: {
      '/api': {
        target: 'https://other-server.example.com',
        secure: false
      }
    }
  }
}

가능한 설정을 보고 싶다면 다음의 링크를 클릭하세요. http-proxy-middleware Options documentation

몇가지 URL을 프록시하는 것은 다양한 설정에 유용할 수 있습니다. 하나의 예제는 로컬 개발서버에서 자바스크립트 파일과 다른 정적 자원들을 제공하지만 외부 개발서버에 요청을 날릴 때입니다. 다른 예제는 인증백엔드서버와 어플리케이션 백엔드 서버같은 두개의 나눠진 서버에 요청을 나눌 때입니다.

Bypass the Proxy (프록시 우회하기)

(Added in v1.13.0) 프록시는 선택적으로 함수로 부터 반환되는 값에 기반하여 우회될 수 있습니다. 그 함수는 HTTP 요청과 응답, 주어진 프록시 옵션을 조사합니다. 이것은 반드시 false나 URL경로를 리턴하여서 요청을 프록시처리하는 것을 계속할 것인지 아닌지를 결정합니다.

예를 들어서 다음의 설정은 브라우저로부터 비롯된 요청을 프록시하지 않습니다. 이것은 historyApiFallback 옵션과 비슷합니다. 브라우저 요청은 평소대로 HTML 파일들을 받고, API에 대한 요청은 백엔드서버로 프록시 요청될 것입니다.

proxy: {
  '/some/path': {
    target: 'https://other-server.example.com',
    secure: false,
    bypass: function(req, res, proxyOptions) {
      if (req.headers.accept.indexOf('html') !== -1) {
        console.log('Skipping proxy for browser request.');
        return '/index.html';
    }
  }
}

Rewriting URLs of proxy request 프록시 요청에 대하여 URL들을 Rewriting하기

(Added in v1.15.0) 프록시에 대한 요청은 선택적으로 제공된 함수에 의하여 다시 쓰여질 수 있습니다. 함수는 HTTP 요청을 조사하고 변경할 수 있습니다. 예를 들어서 다음과 같은 설정은 URL의 시작부분에 /api부분을 삭제하면서 HTTP요청을 다시 쓸 수 있습니다. 

proxy: {
  '/api': {
    target: 'https://other-server.example.com',
    pathRewrite: {'^/api' : ''}
  }
}

pathRewrite는 http-proxy-middleware의 특징입니다. 더 많은 설정을 원하신다면, 해당 부분 문서를 확인하세요.

Proxying local virtual hosts 로컬 가상호스트 프록시하기

http-proxy-middleware 가 미리 로컬 호스트 네임을 로컬호스트에 해석하는 것처럼 보이므로 당신은 프록시 요청을 수정하기 위하여 다음의 설정이 필요할 것입니다.

var server = new webpackDevServer(compiler, {
  quiet: false,
  stats: { colors: true },
  proxy: {
    "/api": {
      "target": {
        "host": "action-js.dev",
        "protocol": 'http:',
        "port": 80
      },
      ignorePath: true,
      changeOrigin: true,
      secure: false
    }
  }
});
server.listen(8080);

웹팩 개발서버 CLI

$ webpack-dev-server <entry>

모든 웹팩 CLI 옵션들은 웹팩 개발서버 CLI에도 유효합니다. 그러나 웹팩개발서버에는 <output> 기본 아규먼트가 존재하지 않습니다. 웹팩개발서버 CLI를 위한 webpack.config.js (혹은 파일로 전달되는 --config 옵션 ) 또한 적용될 수 있습니다.

여기 몇가지 옵션들이 있습니다 :

참고 : 핫모듈대체플러그인을 두번 추가할 수가 없습니다.

추가적인 설정 옵션

CLI 를 사용할 때, 핵심 개발서버 아래의 설정 파일에서 웹팩개발서버 옵션들을 가지는 것이 가능합니다. CLI인자로 전해지는 옵션들은 설정파일의 옵션들을 오버라이드합니다. 개발서버를 위한 옵션들은 다음 섹션에서 보겠습니다.

예제

module.exports = {
  // ...
  devServer: {
    hot: true
  }
}

API

var WebpackDevServer = require("webpack-dev-server");
var webpack = require("webpack");

var compiler = webpack({
  // configuration 설정
});
var server = new WebpackDevServer(compiler, {
  // webpack-dev-server options 웹팩 개발 서버 옵션

  contentBase: "/path/to/directory",
  // Can also be an array, or: contentBase: "http://localhost/",
  // 배열이나 contentBase를 사용할 수 있다.

  hot: true,
  // Enable special support for Hot Module Replacement
  // Page is no longer updated, but a "webpackHotUpdate" message is send to the content
  // Use "webpack/hot/dev-server" as additional module in your entry point
  // Note: this does _not_ add the `HotModuleReplacementPlugin` like the CLI option does. 
  // 핫모듈대체를 위한 특별 지원 활성화

  // Set this as true if you want to access dev server from arbitrary url.
  // This is handy if you are using a html5 router.
  // 만약 임의의 URL부터 개발서버로 접근하기를 원한다면 true로 설정
  // 만약 html5 라우터를 사용한다면 편리합니다. 
  historyApiFallback: false,

  // Set this if you want to enable gzip compression for assets
  // 자원들에 관해서 gzip압축을 원한다면 true
  compress: true,

  // Set this if you want webpack-dev-server to delegate a single path to an arbitrary server.
  // Use "**" to proxy all paths to the specified server.
  // This is useful if you want to get rid of 'http://localhost:8080/' in script[src],
  // and has many other use cases (see https://github.com/webpack/webpack-dev-server/pull/127 ).
  // 만약 웹팩개발서버가 임의의 서버로 단일 경로를 위임하고자 한다면 여기를 설정
  // 지정된 서버에 모든 경로를 프록시 처리하려면 ** 를 사용
  // script에서 http://localhost:8080을 제거 하고 싶을 때 유용합니다. 
  // 이밖에도 많은 사용 경우가 있습니다. 
  proxy: {
    "**": "http://localhost:9090"
  },

  setup: function(app) {
    // Here you can access the Express app object and add your own custom middleware to it.
    // For example, to define custom handlers for some paths:
    // app.get('/some/path', function(req, res) {
    //   res.json({ custom: 'response' });
    // });
    // 여기서 당신은 익스프레스 앱 객체를 접근할 수 있고 당신의 커스텀 미들웨어를 해당 앱객체에 추가할 수 있습니다.
    // 예를 들어서 어떤 경로들에 대해서 커스텀 핸들러를 정의할 수가 있습니다. 
  },

  // pass [static options](http://expressjs.com/en/4x/api.html#express.static) to inner express server
  // 정적 옵션들
  staticOptions: {
  },

  // webpack-dev-middleware options
  // 웹팩개발미들웨어 옵션들
  quiet: false,
  noInfo: false,
  lazy: true,
  filename: "bundle.js",
  watchOptions: {
    aggregateTimeout: 300,
    poll: 1000
  },
  // It's a required option.
  // 필요한 옵션
  publicPath: "/assets/",
  headers: { "X-Custom-Header": "yes" },
  stats: { colors: true }
});
server.listen(8080, "localhost", function() {});
// server.close();

미들웨어 옵션들에 대해서 알고 싶다면 여기를 보자 webpack-dev-middleware

웹팩설정이 웹팩개발서버 API에 전달되지 않기 때문에, 웹팩 설정에서 devServer옵션 은 이러한 경우 사용되지 않습니다. 또한 WebpackDevServer API 에 대하여 인라인 모드는 없습니다.

<script src="http://localhost:8080/webpack-dev-server.js"></script> 가 HTML페이지에 직접 입력되어야 합니다.

The historyApiFallback option

만약 당신이 HTML5 히스토리 API를 사용한다면 당신은 아마 404 응답을 대신하여 index.html을 제공하기를 원할 지도 모르는데 이것은 historyApiFallback: true를 설정함으로써 이뤄질 수가 있습니다. 그러나 만약 당신이 웹팩 설정에서 output.publicPath를 수정한다면 당신은 리다이렉트될 URL을 설정할 필요가 있을 겁니다. 이것은 historyApiFallback.index 옵션을 통하여 이뤄집니다.

// output.publicPath: '/foo-app/'
historyApiFallback: {
  index: '/foo-app/'
}

rewrites를 사용하여서, 정적 페이지들을 제공하기 위한 이러한 기능들이 사용될 수 있습니다. 

historyApiFallback: {
    rewrites: [
        // shows views/landing.html as the landing page
        { from: /^\/$/, to: '/views/landing.html' },
        // shows views/subpage.html for all routes starting with /subpage
        { from: /^\/subpage/, to: '/views/subpage.html' },
        // shows views/404.html on all other pages
        { from: /./, to: '/views/404.html' },
    ],
},

존재하는 서버끼리 결합하기

당신은 아마 개발단계에서 백엔드서버나 백엔드목서버를 사용하기를 원할지도 모릅니다. 당신은 webpack-dev-server 를 백엔드로 사용하여서는 안됩니다. 웹팩개발서버는 오직 웹팩된 정적자원들을 제공하기 위한 목적입니다.

당신은 웹팩개발서버와 백엔드 서버 두 가지를 운영할 수가 있습니다.

이러한 경우 당신은 (HTML페이지가 동작하고있더라도)웹팩으로 생성된 자원에게 요청들이 백엔드서버로 가야한다고 가르쳐줄 필요가 있습니다. 다른 쪽면에서는 백엔드서버쪽의 생성된 HTML들이 웹팩개발서버에 있는 자원들을 가리키게 해야 합니다. (맞나?) 추가적으로 웹팩개발서버와 개발서버 런타임간에 연결하여서 다시 컴파일 할 시에 다시 불러오기 트리거를 발생시켜야 합니다.

웹팩에게 웹팩개발서버에 대한 요청을 만들게 하기 위해 (chunk loading 이나 HMR), 당신은 output.publicPath옵션에서 full URL을 제공할 필요가 있습니다.

웹팩개발서버와 그것의 런타임간의 커넥션을 만들기 위해 --inline과 함께 인라인모드를 사용하세요. 웹팩개발서버 CLI는 자동적으로 웹소켓 커넥션을 만들 수 있는 엔트리 포인트를 포함하게 될 것입니다. (당신은 또한 iframe모드를 사용할 수 있습니다. 만약 당신이 웹팩개발서버의 --content-base에서 백엔드 서버를 지정한다면 ) 만약 당신이 백엔드 서버와의 커넥션을 원한다면 당신은 아이프레임 모드를 사용하면 됩니다.

당신이 인라인 모드를 사용하기를 원한다면, 단지 백엔드 서버URL을 웹브라우저에다가 치면 됩니다. ( 만약 당신이 아이프레임모드를 사용한다면 웹팩개발서버의 접두된 URL /webpack-dev-server/ 을 치면 됩니다 )

요약과 예제입니다. (여기는 이만.. )

webpack-dev-server on port 8080. backend server on port 9090. generate HTML pages with