Webpack-dev-server: Serving static files from publicPath

[selbekk]

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
When you specify contentBase, the files in the given folder is always served from / - no matter what the publicPath is set to. If you have the following minimal config:

{
  devServer: {
    contentBase: path.resolve('static'),
    publicPath: '/some/sub-path/'
  },
}

, the file structure in ./static is served from /. So if I have ./static/fonts and ./static/pdfs, they'll be served from /fonts/ and /pdfs/ instead of /${publicPath}/fonts and /${publicPath}/images.

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
A new option contentPath (or w/e) that would let me set this explicitly, if / was not the behavior I needed.

If this is a feature request, what is motivation or use case for changing the behavior?

We work on a team that creates a webapp on some sub-domain /private/some/stuff/, and we need to run our app locally on localhost:7002/private/some/stuff in order for the app to work correctly. Currently we have scripted our own hacky dev-proxy that's in front of the webpack-dev-server, which is slowing down development.

Please mention your webpack and Operating System version.
Ubuntu 14.04, Webpack 2.3.3

[selbekk]

A workaround to this issue is to add this to your config:

{
  devServer: {
    contentBase: path.resolve('static'),
    publicPath: '/some/sub-path/',
    proxy: {
      '/some/sub-path/*': {
        target: 'http://localhost:[port]/',
        pathRewrite: { '^/some/sub-path': '' },
    },
  },
}

• in other words, proxying any requests that are not already handles to /. This works for me because I'm writing a SPA with a router - it might not work for you.

[rolandjohann]

IMO this configuration key is slightly confusing as the static files won't be affected by it.
It seems that it just prefixes output.filename - static file hosting will be unaffected.

I need to serve static files from a subpath so I can prox non asset requests like html to my server backend to be able to deliver the main html with initial state and be able to do HMR at development.

The fix will be easily possible and I'm keen to implement that. We just have to define what config key to use. Using publicPath - which will be the right key (public directory...), IMHO - will break existing apps when developers are updating webpack-dev-server without tweaking their code. staticAssetPath can be used.

@selbekk a possible workaround will be to hook into webpack-dev-server setup (app) { [...] } where you can access the underlying express.
https://webpack.js.org/configuration/dev-server/#devserver-setup

const express = require('express')

setup(app) {
  app.use('/assets', express.static('<some public path>'))
}

[selbekk]

@rmmjohann thanks for your reply. Yeah, using the setup escape hatch works fine - but I like the proxy workaround better to be honest. Starting to muck around with the actual server seems a bit too much for a config file ^^

[RifeWang]

@selbekk maybe I met the same problem, and I try to proxy it but didn't work . look at #978

[bneumann]

Oh man. I was getting really frustrated after 2 hours that I was too stupid to configure the server correctly. So I used the default '/' paths and everything worked. Was about to file a bug just to see you already have filed it. Thanks :)

[shellscape]

We're gonna mark this one as PR Welcome and a nice-to-have enhancement. Since there's a couple of possible workarounds, if there's no traction on the feature we'll probably archive this one after a while.

[shellscape]

this ticket is stale at 60+ days and will be closed if there's no response from the community. last chance to weigh in 😅

[Vandivier]

I think the setup() method should be standard; but I wouldn't complain if you could expose the express object natively, so I don't have to npm install express

you could do

//const express = require('express') // not needed now

setup(app, _express) {
  app.use('/assets', _express.static('<some public path>'))
}

[shellscape]

@Vandivier that would be exposing the static express object/fn and there's no functional difference between that and requiring express. Express will be installed along with webpack-dev-server, so you don't have to manage that dependency; simply require it since it's already there.

Closing up as we have a few workarounds that are solid.

[RhysyG]

Hey guys,

I have tried multiple setups from the comments but can't get the server working to get a subpath (http://localhost:8080/project/), does anyone know what I might be doing wrong?

In a sentence, I'm trying to run the server out of a Jekyll build folder called _site with an extra path in the url http://localhost:8080/project/

devServer: {
    contentBase: '_site/', //disk location
    watchContentBase: true,
    setup(app){
       app.use('_site/', express.static('/project/'));
    }
},

More of an explanation here:
https://stackoverflow.com/questions/47054824/webpack-middleware-with-jekyll-setup-for-context-path

[kellyrmilligan]

@RhysyG contentBase needs to be an absolute path on disk. something like path.resolve('_site')

[kellyrmilligan]

I was able to get the app.use... working for my setup.

Ideally what i'd like to see is the ability to have bundles served from the publicPath, in my case and looks like others, this could be something like:

/subapp/

and have static files served under /subapp/whatever/path

what i'm working around ATM is having publicPath being a sub path, then wanting to have files also served under this path.

is this possible ATM without this workaround of having middleware?

[shellscape]

Note that setup is deprecated and you should use before instead ;)

[kellyrmilligan]

@shellscape good call, I actually did use before. i'm wondering if this is related to the other issue, where websockets can't be under a subpath.

[kellyrmilligan]

before(app) {
      // This lets us open files from the runtime error overlay.
      app.use(errorOverlayMiddleware());
      // This service worker file is effectively a 'no-op' that will reset any
      // previous service worker registered for the same host:port combination.
      // We do this in development to avoid hitting the production cache if
      // it used the same host and port.
      // https://github.com/facebookincubator/create-react-app/issues/2272#issuecomment-302832432
      app.use(noopServiceWorkerMiddleware());

      app.use(`${config.output.publicPath.slice(0, -1)}/assets`, express.static(paths.appPublic))
    },

relevant section from CRA. would rather not have the /assets there.

[shellscape]

@kellyrmilligan the faux-sockets are a constant pain point in 2.x because of SockJS. v3 replaces that with native WebSockets so that should clear up. (first next release coming this week)

[kellyrmilligan]

great!! is there anything from what you know that would prevent publicPath and content base being the same? what's the best way to accomplish that?

[worc]

...so this was never fixed?

[alexander-akait]

What is problem?

[worc]

that contentBase doesn't use publicPath. that just seems like a weird miss. if you're setting up a public path, you're likely trying to mimic your deployed environment, so your assets wouldn't necessarily be at the root, they'd be alongside the other code at the public path.

[alexander-akait]

@worc publicPath !== contentBase (example CRA use https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/paths.js#L42 for wepback assets and static directory as contentBase) https://github.com/facebook/create-react-app/tree/master/packages/react-scripts/template

[alexander-akait]

What you expected, can you provide example or minimum reproducible test repo?

[worc]

@evilebottnawi obviously contentBase and publicPath are not the same thing. but there is a use-case for having static content be served from the same public path as the rest of the generated output.

as in, if your app is eventually going to be deployed to a non-root path on your domain and the static assets are siblings or within that same path... you would want to recreate that same setup on your dev server to catch 404s and other assets out of place before deploying to whatever host you're using.

[alexander-akait]

Can you create minimum reproducible test repo and describe in read what you actually have and what you expected, this will allow more productive solve the problem

[dantheuber]

I'm running into this problem as well and I've put up a basic repository that can demonstrate the issue: https://github.com/dantheuber/example-react-redux

If you run, npm run build notice how the dist/ directory has the compiled js and html, as well as having the other site files located in public/ copied as well. The intention being that in the end the compiled output will be served alongside the other files within the same directory.

Now run npm start to have webpack-dev-server host serve the files. Take note of the 404 errors present in the console as a result of the other files not being present.

I get the feeling that the issue has been addressed with the merged PR but it is still not clear to me how to setup devServer config to handle this properly..

I hope this helps.