[Placeholder]: Clear up situation with assets paths in production for css-loader

[LinusBorg]

We have had multiple issues like #208 (#563, #552 ) which seem to show that under specific circumstances the paths generated by url-loader/file-loader are wrong.

But to be perfectly honest, I wasn't able to wrap my head around it, especially when trying to thing about how to test the proposed solution of using relative paths under various circumstances:

• requiring assets in JS vs.in CSS
• working paths when using vue-router in 'history' mode
• working paths when using code-splitting

So If anyone can help shed some light on this and work out a robust solution, I'd be delighted.

[robertmain]

I'm trying to use Vue to generate a nice portfolio page for me on github pages. I'm just getting a white page and the reason seems to be related to the fact that all the asset paths are wrong:

See how it's putting in robertmain.github.io/static/whatever.js and basically slicing the URL segment off the end of the URL. Basically it seems to happen if you're not running a vue app in a subdirectory.

One temporary hack that appears to fix it (in the .3 seconds I spent playing with it) is to remove assetsPublicPath in config/index.js so that it's just an empty string. Though, I don't know what knock-on effect that may have so...

[LinusBorg]

I'm not sure I can follow. Does your pahge live at robettmain.github.io/portfolio? If so, the behaviour is expected because the default publicPath is an absolute root path.

You "fixed" it by changing it to an empty string, which essentially is the same as changing it to './' - a relative path.

The other solution would be to use change it to /portfolio.

So why do we start with an absolute path to begin with? Because many, many apps use vue-Router with history mode, and this mode doesn't play nice with relative assets paths.

But since history mode doesn't work on github pages anyway, your solution is fine for your usecase, I think.

Sidenote: This doesn't really have anythign to do with the topic of this issue - it's about other assets path problems.

[robertmain]

The other solution would be to use change it to /portfolio.

Yeah, I'm kind of (ab)using GitHub pages for the time being to host a professional portfolio. The problem with changing it to portfolio would be that it then wouldn't work on my local box.

You "fixed" it by changing it to an empty string, which essentially is the same as changing it to './' - a relative path.

Yeah, I bought this up because I wasn't sure if that was likely to screw with other things or if it was an okay thing to do without breaking things..

But since history mode doesn't work on github pages anyway,

Oh, it doesn't? Huh. TIL.

Sidenote: This doesn't really have anything to do with the topic of this issue - it's about other assets path problems.

Oh, sorry - I thought it was a manifestation of the same issue

[LinusBorg]

Oh, it doesn't? Huh. TIL.

Well, history mode requires some settings on the webserver, which you can't influence o github pages. the normal navigation works, but refrrshing a page will lead to a 404.

[robertmain]

That....kind of makes sense now that I think about it, yeah.

[codetheorist]

PR #1230 fixes this issue, by obtaining this data during the install process, which sets the base URL during the build process and then deploys directly to the gh-pages branch.