Devserver has problems serving static assets with assetsPublicPath != '/'

[jbayona89]

Hello I have made a Vuetify app using vue-cli and vue init vuetifyjs/webpack-advanced the resulting code is this https://github.com/vuetifyjs/webpack-advanced/tree/master/template

The problem I have is that my production app isn't in the root of the server and it is a subpath in www.example.com/foo. When I run npm run build all my static assets like images and fonts are referenced like /static/images/example.png, so the server doesn't find them as they are being looked in www.example.com/static/images/example.png instead of www.example.com/foo/static/images/example.png

If I change config/index.js and set assetsPublicPath: '/foo' and change all my references from /static/... to /foo/static/... then my production server finds all my static assets but then my dev server using npm run dev can't find them as they are being referenced as localhost:8080/foo/static/images/example.png but they seem to be at localhost:8080/static/images/example.png for some reason.

My ideal solution would be just to keep the references as /static and tell webpack or vueloader somehow that on npm run build it should prepend /foo to all of my assets urls. If that is impossible at least I would like to know a way to make my dev and production environments to work with the same code even though it implies to prepend manually /foo to my static assets urls

Thank you

[LinusBorg]

First of all, why are you treating them as static assets instead of letting Webpack handle them by putting them into ./assets? that would prevent the whole problem.

If that's not possible, we will have to work something out, becaue it seems that webpack-dev-server doesn't apply the publicPath setting to static files (but he does to built files) - that's a pity.

I will investigate a bit more if that's really the case and what to do about that, but for now we will have to work around that.

We can do that by generating the static paths dynamically depending on environment:

// /config/dev.env.js
STATIC_PATH_PREFIX: '"/"' 

// /config/prod.env.js
STATIC_PATH_PREFIX: '"/foo/"' 

Then add a helper to your app:

Vue.mixin({
  methods: {
    $toStaticPath(path = '') {
      return process.env.STATIC_PATH_PREFIX + path
    }
  }
})

and use it like this:

<img v-bind:src="$toStaticPath('static/images/example.png')">

[jbayona89]

Thank you, I will try to use assets whenever it's possible and Will use this for the rest of my urls

[nkovacs]

Like I said in #1141, adding CopyWebpackPlugin to the dev config (with the exact same configuration except with config.dev.assetsSubDirectory) fixed my issue. You could try that.

[LinusBorg]

I see how that could provide a workaround, but it would have to copy to a different location, e.g. /public, so that it doesn't mess with /dist - that would have to be docoumented and explained to users.

So thanks, I will fall back to this if I don't find a way to make webpack-dev-server serve the files appropriately.

[LinusBorg]

Oh, I just saw this: https://github.com/webpack-contrib/copy-webpack-plugin#this-doesnt-copy-my-files-with-webpack-dev-server

Starting in version 3.0.0, we stopped using fs to copy files to the filesystem and started depending on webpack's in-memory filesystem:

That could work after all. Thanks!

[alxppp]

Thanks @LinusBorg! That has been bugging me for a while now. The latest development branch is working fine for me!

Two small hints for others updating from the old dev server:

• Instead of assetsPublicPath: '/abc/' it now has to be assetsPublicPath: '/abc'
• To get browser reloads working again, I had to change history api fallback to:

historyApiFallback: {
  rewrites: [
    { from: /.*/, to: `${config.dev.assetsPublicPath}/index.html` },
  ],
},

[LinusBorg]

Hey, thanks for the feedback, that's very valuable.

I'll add those fixes when I can.

[SirM2z]

Hello @LinusBorg
My browser generated extra duplicate requests when I added this configuration

historyApiFallback: {
  rewrites: [
    { from: /.*/, to: `${config.dev.assetsPublicPath}/index.html` },
  ],
},

before modifying:

after modification:

I found that extra requests are related to favicon.ico.

But it can work normally when I change back historyApiFallback: true