Detailed explanation of webpack-dev-server core concepts and cases

webpack-dev-server core concepts

Webpack's ContentBase vs publicPath vs output.path

webpack-dev-server will use the current path as the requested resource path (the so-called

Current Path

It is the path to run the webpack-dev-server command. If webpack-dev-server is packaged, such as wcf, then the current path refers to the path to run the wcf command, which is generally the root path of the project), but readers can modify this default behavior by specifying content-base:

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

In this way, webpack-dev-server will use the resources in the build directory to handle requests for static resources, such as css/pictures. content-base should generally not be confused with publicPath or output.path. The content-base indicates the path of the static resource, such as the following example:

<!DOCTYPE html>
<html>
<head>
  <title></title>
  <link rel="stylesheet" type="text/css" href="index.css" rel="external nofollow" >
</head>
<body>
  <div id="react-content">Insert js content here</div>
</body>
</html>

After being used as a template for html-webpack-plugin, what is the path of index.css above? Relative to whom? It has been emphasized above: if content-base is not specified, it is relative to the current path. The so-called current path is the directory where webpack-dev-server is running. So if this command is run in the project root path, then you must ensure that the index.css resource exists in the project root path, otherwise there will be a 404 error in html-webpack-plugin. Of course, to solve this problem, you can change the content-base to the same directory as the html template of html-webpack-plugin.

As mentioned above, content-base is only related to requests for static resources, so let's make a distinction between its publicPath and output.path.
First: if output.path is set to build (build here has nothing to do with content-base build, please don't confuse it), you should know that webpack-dev-server does not actually write these packaged bundles to this directory, but exists in memory, but we can assume (note that this is an assumption) that it is written to this directory.
Then: When these packaged bundles are requested, their paths are relative to the configured publicPath, which is equivalent to a virtual path that maps to the specified output.path. If the specified publicPath is "/assets/" and output.path is "build", then the virtual path "/assets/" corresponds to "build" (the former and the latter point to the same location), and if there is an "index.css" under build, then the virtual path access is /assets/index.css.
Finally: if a specific bundle already exists at a certain memory path (file written in memory), and there are new resources in memory after compilation, then we will also use the new in-memory resources to handle the request instead of using the old bundle! For example, there is a configuration like this:

module.exports = {
  entry: {
    app: ["./app/main.js"]
  },
  output: {
    path: path.resolve(__dirname, "build"),
    publicPath: "/assets/",
    //At this point, the /assets/ path corresponds to the build directory, which is a mapping relationship filename: "bundle.js"
  }
}

Then we can access the compiled resources through localhost:8080/assets/bundle.js. If there is an html file in the build directory, you can use the following method to access the js resource:

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

At this point you will see the following output on the console:

enter image description here

Focus on the following two outputs:

Webpack result is served from /assets/
Content is served from /users/…./build

The reason for this output is that contentBase is set to build, because the command run is webpack-dev-server --content-base build/ . So, in general: if there is no reference to external relative resources in the HTML template, we do not need to specify content-base, but if there is a reference to external relative resources css/images, you can set the default static resource loading path by specifying content-base, unless all static resources are in the current directory .

webpack-dev-server Hot Reloading (HMR)

To enable HMR mode for webpack-dev-server, just add --hot to the command line, which will add the HotModuleReplacementPlugin plugin to the webpack configuration, so the easiest way to enable HotModuleReplacementPlugin is to use inline mode. In inline mode, just add --inline --hot to the command line to automatically achieve it.
At this time, webpack-dev-server will automatically add the webpack/hot/dev-server entry file to the configuration. You just need to access the following path http://«host»:«port»/«path». In the console, you can see the following content, where the part starting with [HMR] comes from the webpack/hot/dev-server module, and the part starting with [WDS] comes from the client of webpack-dev-server. The following part is from webpack-dev-server/client/index.js, where all logs start with [WDS]:

function reloadApp() {
  if(hot) {
    log("info", "[WDS] App hot update...");
    window.postMessage("webpackHotUpdate" + currentHash, "*");
  } else {
    log("info", "[WDS] App updated. Reloading...");
    window.location.reload();
  }
}

The logs in webpack/hot/dev-server all start with [HMR] (it is a plugin from Webpack itself):

if(!updatedModules) {
        console.warn("[HMR] Cannot find update. Need to do a full reload!");
        console.warn("[HMR] (Probably because of restarting the webpack-dev-server)");
        window.location.reload();
        return;
      }

So how to use HMR function in nodejs? At this time, you need to modify three configuration files:

1. Add a Webpack entry point, which is webpack/hot/dev-server
2. Add a new webpack.HotModuleReplacementPlugin() to the webpack configuration
3. Add hot:true to the webpack-dev-server configuration to enable HMR on the server (you can use webpack-dev-server --hot in the cli)
For example, the following code shows how webpack-dev-server handles entry files in order to implement HMR:

if(options.inline) {
  var devClient = [require.resolve("../client/") + "?" + protocol + "://" + (options.public || (options.host + ":" + options.port))];
  //Add the client entry of webpack-dev-server to the bundle to achieve automatic refresh if(options.hot)
    devClient.push("webpack/hot/dev-server");
    //Here is the processing of hot configuration in webpack-dev-server [].concat(wpOpt).forEach(function(wpOpt) {
    if(typeof wpOpt.entry === "object" && !Array.isArray(wpOpt.entry)) {
      Object.keys(wpOpt.entry).forEach(function(key) {
        wpOpt.entry[key] = devClient.concat(wpOpt.entry[key]);
      });
    } else {
      wpOpt.entry = devClient.concat(wpOpt.entry);
    }
  });
}

The usage of nodejs that meets the above three conditions is as follows:

var config = require("./webpack.config.js");
config.entry.app.unshift("webpack-dev-server/client?http://localhost:8080/", "webpack/hot/dev-server");
//Condition 1 (adding the client of webpack-dev-server and the server of HMR)
var compiler = webpack(config);
var server = new webpackDevServer(compiler, {
  hot: true //Condition 2 (--hot configuration, webpack-dev-server will automatically add HotModuleReplacementPlugin)
  ...
});
server.listen(8080);

webpack-dev-server starts proxy

webpack-dev-server usage

http-proxy-middleware

To proxy the request to an external server, the configuration example is as follows:

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
      }
    }
  }
}
// Multiple entry
proxy: [
  {
    context: ['/api-v1/**', '/api-v2/**'],
    target: 'https://other-server.example.com',
    secure: false
  }
]

This kind of proxy is very important in many cases. For example, some static files can be loaded through a local server, while some API requests are all completed through a remote server. Another scenario is to split requests between two separate servers, such as one server responsible for authorization and another server responsible for the application itself. Here is an example encountered in daily development:

(1) A request is made through a relative path, such as the address "/msg/show.htm". However, different domain names will be added in front of the daily and production environments, such as you.test.com for daily use and you.inc.com for production environments.

(2) For example, if you want to start a webpack-dev-server locally and then access the daily server through webpack-dev-server, and the daily server address is 11.160.119.131, you can complete it through the following configuration:

devServer: {
    port: 8000,
    proxy: {
      "/msg/show.htm": {
        target: "http://11.160.119.131/",
        secure: false
      }
    }
  }

At this time, when "/msg/show.htm" is requested, the actual URL address requested is "http//11.160.119.131/msg/show.htm".

(3) A problem was encountered in the development environment. If the local devServer was started at "http://30.11.160.255:8000/" or the more common "http://0.0.0.0:8000/", the real server would return a URL requesting login. However, starting the local devServer on localhost would not cause this problem (a possible reason is that localhost has the cookies required by the backend, while other domain names have not, resulting in the proxy server not having the corresponding cookies when accessing the regular server, thus requiring permission verification). The way to specify localhost is through

wcf

To complete, because wcf can support IP or localhost access by default. Of course, this can also be done by adding the following code:

devServer: {
    port: 8000,
    host:'localhost',
    proxy: {
      "/msg/show.htm": {
        target: "http://11.160.119.131/",
        secure: false
      }
    }
  }

(4) Regarding the principle of webpack-dev-server, readers can refer to the information such as "Why is the reverse proxy called a reverse proxy" to learn more. In fact, the forward proxy and reverse proxy can be summarized in one sentence: "The forward proxy hides the real client, while the reverse proxy hides the real server." The webpack-dev-server actually plays the role of a proxy server. There is no common same-origin policy between servers. When webpack-dev-server is requested, it will request data from the real server and then send the data to your browser.

  browser => localhost:8080 (webpack-dev-server without proxy) => http://you.test.com
  browser => localhost:8080 (webpack-dev-server has a proxy) => http://you.test.com

The first case above is the case without a proxy. When the page at localhost:8080 accesses http://you.test.com through the front-end policy, there will be a same-origin policy, that is, the second step is to access another address through the front-end policy. However, in the second case, the second step is actually completed through the proxy, that is, the communication between servers, and there is no same-origin policy problem. Instead, we directly access the proxy server, which returns a page. For some front-end requests (proxy, rewrite configuration) that meet specific conditions in the page, all are completed by the proxy server. In this way, the same-origin problem is solved by means of the proxy server.

(5) The above describes the case where the target is an IP. If the target is to be specified as a domain name, it may be necessary to bind the host. For example, the host bound below:
11.160.119.131 youku.min.com
Then the following proxy configuration can use the domain name:

devServer: {
    port: 8000,
    proxy: {
      "/msg/show.htm": {
        target: "http://youku.min.com/",
        secure: false
      }
    }
  }

This is exactly the same as binding the target to an IP address. To sum up in one sentence: "target specifies which host the request that satisfies a specific URL should correspond to, that is, the real host address that the proxy server should access."
In fact, the proxy can also bypass a proxy as appropriate by configuring the return value of a bypass() function. This function can inspect HTTP requests and responses as well as some proxy options. It returns either false or a URL path that will be used to handle the request instead of using the original proxy method. The following example configuration will ignore HTTP requests from the browser, which is similar to the historyApiFallback configuration. Browser requests will receive the html file as usual, but API requests will be proxied to another server:

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';
    }
  }
 }
}

Requests to the proxy can also be overridden by providing a function that can inspect or alter the HTTP request. The following example will rewrite the HTTP request, its main function is to remove the /api part in front of the URL.

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

The pathRewrite configuration comes from http-proxy-middleware. More configurations can be viewed

http-proxy-middleware official documentation.

historyApiFallback option

When using HTML 5's history API, you may want to use index.html as the requested resource when a 404 error occurs. In this case, you can use this configuration: historyApiFallback:true. However, if you modify output.publicPath, you need to specify the redirect URL, you can use the historyApiFallback.index option.

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

Use the rewrite option to re-set static resources

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' },
    ],
},

Use disableDotRule to meet a requirement that if a resource request contains a
. symbol, then it indicates a request for a specific resource, which satisfies dotRule. Let's see
How connect-history-api-fallback handles this internally:

if (parsedUrl.pathname.indexOf('.') !== -1 &&
        options.disableDotRule !== true) {
      logger(
        'Not rewriting',
        req.method,
        req.url,
        'because the path includes a dot (.) character.'
      );
      return next();
    }
    rewriteTarget = options.index || '/index.html';
    logger('Rewriting', req.method, req.url, 'to', rewriteTarget);
    req.url = rewriteTarget;
    next();
  };

That is to say, if it is a request for an absolute resource, that is, it satisfies dotRule, but disableDotRule (disable dot rule file request) is false, it means that we will process the resources that satisfy dotRule ourselves, so there is no need to direct them to index.html! If disableDotRule is true, it means that resources that meet dotRule will not be processed, so they will be directed directly to index.html!

history({
  disableDotRule: true
})

More webpack-dev-server configuration

var server = new WebpackDevServer(compiler, {
  contentBase: "/path/to/directory",
  //content-base configuration hot: true,
  // Enable HMR, and webpack-dev-server sends a "webpackHotUpdate" message to the client code historyApiFallback: false,
  //Single-page application 404 redirects to index.html
  compress: true,
  // Enable gzip compression of resources proxy: {
    "**": "http://localhost:9090"
  },
  //Proxy configuration, from http-proxy-middleware
  setup: function(app) {
     //webpack-dev-server itself is an Express server that can add its own routes // app.get('/some/path', function(req, res) {
    // res.json({ custom: 'response' });
    // });
  },
  //Configure parameters for the express.static method of the Express server http://expressjs.com/en/4x/api.html#express.static
  staticOptions: {
  },
  //In inline mode, it is used to control the log level printed in the browser, such as `error`, `warning`, `info` or `none`.
  clientLogLevel: "info",
  //Do not print any logs in the console
  quiet: false,
  //Do not output startup log
  noInfo: false,
  //webpack does not monitor file changes and recompiles each time a request comes lazy: true,
  //File name filename: "bundle.js",
  //webpack's watch configuration, how many seconds to check file changes watchOptions: {
    aggregateTimeout: 300,
    poll: 1000
  },
  //Virtual path mapping of output.path publicPath: "/assets/",
  //Set custom http headers: { "X-Custom-Header": "yes" },
  //Package status information output configuration stats: { colors: true },
  //Configure the certificates required for https: {
    cert: fs.readFileSync("path-to-cert-file.pem"),
    key: fs.readFileSync("path-to-key-file.pem"),
    cacert: fs.readFileSync("path-to-cacert-file.pem")
  }
});
server.listen(8080, "localhost", function() {});
// server.close();

The other configurations above are easy to understand except filename and lazy. Let's continue to analyze the specific usage scenarios of lazy and filename. We know that in the lazy phase, webpack-dev-server does not call the compiler.watch method, but waits for the request to arrive before compiling. The source code is as follows:

startWatch: function() {
      var options = context.options;
      var compiler = context.compiler;
      // start watching
      if(!options.lazy) {
        var watching = compiler.watch(options.watchOptions, share.handleCompilerCallback);
        context.watching = watching;
        //context.watching gets the Watching object returned as is} else {
       //If it is lazy, it means we are not watching, but compiling when requested.context.state = true;
      }
    }

When calling rebuild, context.state will be checked. After each recompilation, context.state will be reset to true in compiler.done!

rebuild: function rebuild() {
      //If no Stats object has been generated through compiler.done, set forceRebuild to true
      //If there are Stats indicating that it has been built before, then call the run method if (context.state) {
        context.state = false;
        //In lazy state, context.state is true, rebuild
        context.compiler.run(share.handleCompilerCallback);
      } else {
        context.forceRebuild = true;
      }
    },

Here is how we call the rebuild above to continue recompiling when a request comes in:

handleRequest: function(filename, processRequest, req) {
      // in lazy mode, rebuild on bundle request
      if(context.options.lazy && (!context.options.filename || context.options.filename.test(filename)))
        share.rebuild();
      //If filename contains hash, then read the file name from memory through fs, and the callback is to send the message directly to the client!!!
      if(HASH_REGEXP.test(filename)) {
        try {
          if(context.fs.statSync(filename).isFile()) {
            processRequest();
            return;
          }
        } catch(e) {
        }
      }
      share.ready(processRequest, req);
      //The callback function sends the file result to the client},

Among them, processRequest directly sends the compiled resources to the client:

function processRequest() {
      try {
        var stat = context.fs.statSync(filename);
        //Get the file name if(!stat.isFile()) {
          if(stat.isDirectory()) {
            filename = pathJoin(filename, context.options.index || "index.html");
            //File name stat = context.fs.statSync(filename);
            if(!stat.isFile()) throw "next";
          } else {
            throw "next";
          }
        }
      } catch(e) {
        return goNext();
      }
      // server content
      // If the file is accessed directly, read it. If it is a folder, access the folder var content = context.fs.readFileSync(filename);
      content = shared.handleRangeHeaders(content, req, res);
      res.setHeader("Access-Control-Allow-Origin", "*"); 
      // To support XHR, etc.
      res.setHeader("Content-Type", mime.lookup(filename) + "; charset=UTF-8");
      res.setHeader("Content-Length", content.length);
      if (context.options.headers) {
        for(var name in context.options.headers) {
          res.setHeader(name, context.options.headers[name]);
        }
      }
      // Express automatically sets the statusCode to 200, but not all servers do (Koa).
      res.statusCode = res.statusCode || 200;
      if(res.send) res.send(content);
      else res.end(content);
    }
  }

Therefore, in lazy mode, if we do not specify the filename, that is, each request is for the Webpack output file (chunk), then it will be rebuilt every time! But if a file name is specified, it will only be rebuilt when the file name is accessed!

This concludes this article on the core concepts and cases of webpack-dev-server. For more relevant webpack-dev-server core content, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!

You may also be interested in:

Solve the problem that webpack dev-server cannot match post requests
A brief discussion on the configuration and use of webpack-dev-server
How to use webpack-dev-server to handle cross-domain requests
Detailed explanation of webpack-dev-server setting up reverse proxy to solve cross-domain problems
Detailed explanation of the simple use of webpack-dev-server
Webpack-dev-server remote access configuration method

<<: How to create users and manage permissions in MySQL

>>: Understanding MySQL precompilation in one article

How to deploy Vue project using Docker image + nginx

Detailed explanation of webpack-dev-server core concepts and cases

webpack-dev-server core concepts

Webpack's ContentBase vs publicPath vs output.path

webpack-dev-server Hot Reloading (HMR)

webpack-dev-server starts proxy

historyApiFallback option

More webpack-dev-server configuration

How to deploy Vue project using Docker image + nginx

Docker container from entry to obsession (recommended)

HTML framework_Powernode Java Academy

Example usage of JavaScript tamper-proof object

Detailed tutorial on installing MySQL 8.0.19 in zip version on win10

Seven different color schemes for website design experience

Form submission refresh page does not jump source code design

Difference and principle analysis of Nginx forward and reverse proxy

Implementation steps for Docker deployment of SpringBoot applications

Element's el-tree multiple-select tree (checkbox) parent-child node association is not associated

Recommend

CentOS 6 uses Docker to deploy redis master-slave database operation example

How does Vue track data changes?

Docker realizes the connection with the same IP network segment

Two ways to implement HTML page click download file

CSS sprites technology integrates multiple backgrounds into one PNG image CSS positioning

A brief talk about JavaScript variable promotion

HTML table markup tutorial (16): title horizontal alignment attribute ALIGN

Detailed explanation of the master-slave configuration tutorial of redis under Docker

How to use docker compose to build fastDFS file server

Implementation of docker redis5.0 cluster cluster construction

A brief discussion on HTML ordered lists, unordered lists and definition lists

What is em? Introduction and conversion method of em and px

Notes on matching MySql 8.0 and corresponding driver packages

How to use CSS to pull down a small image to view a large image and information

Building an image server with FastDFS under Linux