Better publicPath in webpack.conf

[zhangxin840]

Setting publicPath of webpack.conf to '/' is unnecessary. This will break the app if served form local file system, or a PhoneGap package.

[chrisvfritz]

@zhangxin840 I believe that was originally added because it was required for code splitting. Have you checked that code splitting still works when it's not set?

[mixedCase]

I'm a bit new to the whole SPA/JS/WebPack/modern webdev kerfuffle, could I be of help somehow? Building with build.assetsPublicPath set to './' the default template (also adding the component) works just fine and all scripts seem to be built correctly and load. Is that example too simple to test what you believe may break @chrisvfritz ?

[zhangxin840]

@chrisvfritz I set assetsPublicPath to '' and nothing goes wrong(at least in the project).

[LinusBorg]

publicPath != assetsPublicPath

without an absolute public path, webpack fails to load split chunks when the url has changed (e.g. from using vue.router).

[mixedCase]

@LinusBorg Regardless it fixes the problem. I now am able to run my application over file:// with no issues. Everything builds just fine, I can serve the files just fine.

[LinusBorg]

Yes, but we are not discussing assetPublicPath here.

[mixedCase]

@LinusBorg I think you're losing sight of the problem in favor of the details. In this case @zhangxin840 mentioned the problem explicitly. Changing assetsPublicPath to './' (instead of publicPath) solves the problem and everything seems to work on my end just fine afterwards, which was @chrisvfritz's worry.

In any case, how would I go about reproducing the problem you mentioned? Do you mean LiveReload breaks? Because the change is only applied to the build script, not dev.

[LinusBorg]

when you use vue-router (or change the url history any other way), a relative publicpath (and most likely, also assetPublicPath will break your build.

At least I personally experienced that webpack will try to fetch chunks (from code splitting) relative to the current URL if public path is not absolute - which will fail if you are not in the root.

[mixedCase]

I use vue-router in my project. I have not touched publicPath, only assetPublicPath. As I said, everything builds and works just fine.

[LinusBorg]

have you used code-splitting?

[mixedCase]

@LinusBorg I'm using ES6 modules. They compile together just fine.

[mixedCase]

@LinusBorg This is still a bug and should be reopened. In config/index.js changing build.assetsPublicPath to './' and leaving dev.assetsPublicPath fixes serving over file:/// protocol while at the same time allowing the npm run dev webserver to keep working.

Everything builds correctly in both situations. The files in dist can be used both over file and tested hosting them with python -m http.server and npm's http-server package with no issues found.

I haven't seen an example using code-splitting to test wether it breaks or not. But not working under Cordova is as much an issue.

[LinusBorg]

This is still a bug

I fail to see why a config setting's default value should be considered a bug, just because it does not fit your specific usecase. If you need another value, change the config setting, that's what it is for.

Everything builds correctly in both situations.

Did you test with vue-router? Because relative asset Paths will break paths to your assets when using vue-router in history mode, which is a very popular usecase (or manipulate history API any other way): When you navigate from '/' to '/users', an asset's path will change with it, i.e. from './logo.png' will now point to './users/logo.npg' - and the file won't exist at that path, of course.