npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

webpack-dev-middleware-multi-compiler

v1.0.0

Published

Offers a dev middleware for webpack, which arguments a live bundle to a directory

Downloads

31

Readme

npm node deps tests coverage chat

NOTE: This is a temporary package that adds support for multiple compilers with a pending PR that likely will be merged soon: https://github.com/webpack/webpack-dev-middleware/pull/187 ...don't sweat it.

It's a simple wrapper middleware for webpack. It serves the files emitted from webpack over a connect server. This should be used for development only.

It has a few advantages over bundling it as files:

  • No files are written to disk, it handle the files in memory
  • If files changed in watch mode, the middleware no longer serves the old bundle, but delays requests until the compiling has finished. You don't have to wait before refreshing the page after a file modification.
  • I may add some specific optimization in future releases.
npm install webpack-dev-middleware --save-dev
var webpackMiddleware = require("webpack-dev-middleware");
app.use(webpackMiddleware(...));

Example usage:

app.use(webpackMiddleware(webpack({
	// webpack options
	// webpackMiddleware takes a Compiler object as first parameter
	// which is returned by webpack(...) without callback.
	entry: "...",
	output: {
		path: "/"
		// no real path is required, just pass "/"
		// but it will work with other paths too.
	}
}), {
	// publicPath is required, whereas all other options are optional

	noInfo: false,
	// display no info to console (only warnings and errors)

	quiet: false,
	// display nothing to the console

	lazy: true,
	// switch into lazy mode
	// that means no watching, but recompilation on every request

	watchOptions: {
		aggregateTimeout: 300,
		poll: true
	},
	// watch options (only lazy: false)

	publicPath: "/assets/",
	// public path to bind the middleware to
	// use the same as in webpack
	
	index: "index.html",
	// the index path for web server

	headers: { "X-Custom-Header": "yes" },
	// custom headers

	stats: {
		colors: true
	},
	// options for formating the statistics

	reporter: null,
	// Provide a custom reporter to change the way how logs are shown.

	serverSideRender: false,
	// Turn off the server-side rendering mode. See Server-Side Rendering part for more info.
}));

Advanced API

This part shows how you might interact with the middleware during runtime:

  • close(callback) - stop watching for file changes

    var webpackDevMiddlewareInstance = webpackMiddleware(/* see example usage */);
    app.use(webpackDevMiddlewareInstance);
    // After 10 seconds stop watching for file changes:
    setTimeout(function(){
      webpackDevMiddlewareInstance.close();
    }, 10000);
  • invalidate() - recompile the bundle - e.g. after you changed the configuration

    var compiler = webpack(/* see example usage */);
    var webpackDevMiddlewareInstance = webpackMiddleware(compiler);
    app.use(webpackDevMiddlewareInstance);
    setTimeout(function(){
      // After a short delay the configuration is changed
      // in this example we will just add a banner plugin:
      compiler.apply(new webpack.BannerPlugin('A new banner'));
      // Recompile the bundle with the banner plugin:
      webpackDevMiddlewareInstance.invalidate();
    }, 1000);
  • waitUntilValid(callback) - executes the callback if the bundle is valid or after it is valid again:

    var webpackDevMiddlewareInstance = webpackMiddleware(/* see example usage */);
    app.use(webpackDevMiddlewareInstance);
    webpackDevMiddlewareInstance.waitUntilValid(function(){
      console.log('Package is in a valid state');
    });

Server-Side Rendering

Note: this feature is experimental and may be removed or changed completely in the future.

In order to develop a server-side rendering application, we need access to the stats, which is generated with the latest build.

In the server-side rendering mode, webpack-dev-middleware would sets the stat to res.locals.webpackStats before invoking the next middleware, where we can render pages and response to clients.

Notice that requests for bundle files would still be responded by webpack-dev-middleware and all requests will be pending until the building process is finished in the server-side rendering mode.

app.use(webpackMiddleware(compiler, { serverSideRender: true })

// The following middleware would not be invoked until the latest build is finished.
app.use((req, res) => {
  const assetsByChunkName = res.locals.webpackStats.toJson().assetsByChunkName

  // then use `assetsByChunkName` for server-sider rendering
	// For example, if you have only one main chunk:

	res.send(`
<html>
  <head>
    <title>My App</title>
		${
			assetsByChunkName.main
			.filter(path => path.endsWith('.css'))
			.map(path => `<link rel="stylesheet" href="${path}" />`)
		}
  </head>
  <body>
    <div id="root"></div>
		${
			assetsByChunkName.main
			.filter(path => path.endsWith('.js'))
			.map(path => `<script src="${path}" />`)
		}
  </body>
</html>		
	`)

})

Don't hesitate to create a pull request. Every contribution is appreciated. In development you can start the tests by calling npm test.

MIT