Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

webpackDevMiddleware fails to host files at publicPath

See original GitHub issue

I’ve fallen back to using new WriteFilePlugin()



I.e. hosting the files from the file system manually. But I shouldn’t have to do that. I noticed this PR to webpack-dev-middleware:

So I’m curious how this package successfully hosted files if webpack-dev-middleware itself is struggling to host files from a multi-compiler.

…ps. otherwise, amazing package! I love that require-from-string implementation, pure magic!

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:1
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

faceyspaceycommented, Apr 27, 2017

@richardscarrott What’s going on brother, I finally finished my tools revolving around chunk flushing. Along with it is a boilerplate that reproduces it:

The only thing is that it now uses a fork of webpack-dev-middleware which supports multiple compilers:

If you git clone the boilerplate, run yarn add webpack-dev-middleware and switchout the corresponding code in server/index.webpack.js you will see the issue.

Here’s the pending PR for the fix by the way:

I think you got it working by one of 2 ways:

  • you are hosting the files in your file system separately. This is what I used to do in conjunction with the write-file-webpack-plugin and app.use(publicPath, express.static(outputPath)).
  • somehow maybe you got the compiler names set a certain way, or maybe their array order so that webpack-dev-middleware accidentally picks the correct publicPath.

It’s probably the first of the 2 in whatever code you’re usually running…not that it matters now if you wanna use my fork or upgrade webpack-dev-middleware once the PR is merged.

Otherwise, I got some good news: I finally finished the chunk flushing stuff I was working on; here’s a PR to React Loadable that explains it all:

I’d be really interested for you to join the conversation in that PR regarding all the new tools mentioned there.

I replaced my serverStats-clientStats linking with your deterministic module ID solution. Very nice! And I’m also using the cleaner webpack-hot-server-middleware API now that takes an options object. I was actually gonna ask you if we could go that route (since I now had null for the serverStats everywhere just complicating my boilerplates), but then I saw you already did it. I do feel like serverRendererOptions is unnecessary nesting and any additional keys can exist parallel to chunkName on the options object and then you just pass the whole thing–just a thought. Either way having that options object is a very useful touch for communicating from Babel code where paths resolve easily to Webpack code where it gets complicated. I’m sure people will find many other reasons to use that.

Anyway, I just wanted to touch base about these things as I basically just launched all my stuff. Checkout the PR to React Loadable for all the relevant links. I have several packages, one very interesting one handling CSS chunks and CSS HMR that I forked from extract-text-webpack-plugin which I’m eager to hear people’s opinions about. I won’t clutter you with links–it’s in the PR.

…but oh yea, so your package (this package, webpack-hot-server-middleware) plays a very important role in the workflow I’ve laid out. I mean I think this package is fantastic. Everybody should be using it. I give you a lot of props for this package (not as in the ones you pass to React components) in my documentation. It should be just as popular as the client middleware. Not using Webpack on the server is a mistake if you’re using it on the client. And if you’re using webpack on the server without proper HMR, ur doing it all wrong. I really don’t understand why it hasn’t blown up…In short, let’s blow it up! Talk soon.

richardscarrottcommented, Apr 18, 2017

@faceyspacey I’ve been unable to reproduce this issue, could you push up an example repo so I can do some investigation / work out what I’ve been doing differently?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Cannot GET / error with my webpack-dev-middleware setup
It's not that it cannot find the bundle.js file; it simply cannot ... app.use(webpackDevMiddleware(compiler, { publicPath : config.output.
Read more >
Public Path - webpack
webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable...
Read more >
This modified bundle is served from memory at the relative path specified in publicPath (see API). It will not be written to your...
Read more >
webpack-dev-middleware -
Check Webpack-dev-middleware 5.3.3 package - Last release 5.3.3 with MIT ... as Array#filter in which a return value of false will not write...
Read more >
webpack-dev-server - npm
publicPath ' configuration. The static files will be available in the browser under this public path. --watch-files <value...> Allows to ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found