Vue-cli: Make public folder path configurable

[marvinrabe]

What problem does this feature solve?

Renaming or moving the public folder in order to use vue-cli alongside other frameworks (e.g. Laravel).

Yes, it is possible to achieve it with this configuration:

const path = require('path')

const publicDir = 'assets/html';

module.exports = {
    chainWebpack: config => {
        config
            .plugin('html')
            .tap(args => {
                args[0].template = path.resolve(publicDir + '/index.html');
                return args
            })

        config
            .plugin('copy')
            .tap(([pathConfigs]) => {
                pathConfigs[0].from = path.resolve(publicDir);
                return [pathConfigs]
            })
    }
}

But for such a simple configuration this feels ridiculous.

What does the proposed API look like?

Specify the public directory path in the vue.config.js

module.exports = {
    publicDir: 'assets/html' // Defaults to 'public'
}

[yyx990803]

The public directory is NOT the actual assets that are getting served. All final deliverable assets are in dist when you build your app. (static assets in public are copied into dist)

The workflow for using Vue CLI with a backend framework is let the Vue CLI app live in its own isolated directory and (after build) target/copy your dist folder to proper location in your backend framework.

[marvinrabe]

I know that the public folder is copied into dist. But then why is the directory public called public, when it should not be public? dist should be public (but is not called public).

For the current issue I really don't care if the default name is public or not. But at least add the option to change the path - if one needs to.

Your proposition (https://github.com/yyx990803/laravel-vue-cli-3) with integrating Vue CLI with a backend framework is not optimal. It works. But on a daily basis it is quite inconvenient. I work on the client and backend at the same time. This means I have to change between folders often (root project folder and client folder) respectively switch between multiple terminal sessions for running CLI commands (like artisan, yarn ...). Occasionally I run a command in the wrong folder. Therefore, I prefer having the client and backend in the same root directory.

[yyx990803]

@marvinrabe in that case you should just use the default config from Laravel (via Mix) instead of the CLI.

[marvinrabe]

No. In my opinion Laravel Mix is not really suited for SPA. Vue CLI is. But Vue CLI has one little quirk: no configurable public directory. It assumes a strict separation between client and backend which is not sensible in smaller projects. The client and backend are developed and deployed together.

I spend some time digging through older issues to fully understand your reasons. For future reference the reasons for not providing a configuration for the public directory are:

1. The CLI is designed for SPAs or projects that separates front-end from the backend.
2. There's little practical benefits in changing the src or public directory names.
3. Consistent source code structure across all Vue CLI projects.
4. Maintenance cost

I strongly disagree on the first 3 points. But as explained by @LinusBorg in #3061 the maintenance cost is a good reason for rejecting this feature.

Thank you for taking time responding to this issue.

Sources:

• https://github.com/vuejs/vue-cli/issues/1134#issuecomment-384856754
• https://github.com/vuejs/vue-cli/issues/3061#issuecomment-443856018
• https://github.com/vuejs/vue-cli/issues/3040#issuecomment-443460624

[yyx990803]

Yes, your summary is basically my reason for rejecting this. Note that (1) is the whole premise for providing the CLI, so disagreeing with that means you have a different vision for what this project should be - in that case you should probably fork it.

[thinsoldier]

@marvinrabe Thank you for the config example. I have been struggling with this same problem for days.

At the very least I wish I could tell vue to not copy any or at least certain files from the public folder over to the /dist. My several gigabytes of files in the /public/gallery folder takes a while to copy and it's a waste of space to make a copy of it.

Something I very much do not understand is why the results of npm run serve does not create a dist folder but the photos are loading properly (from /public/gallery) but the results of npm run build does not put a gallery folder in /dist because I used your configuration and therefore the photos do not load, which is expected. What magic is npm run server doing to make it different from build. If build doesn't load the photos then server should not either. Strange.

[livthomas]

I also ran into this issue in the CLI. How come these two very popular frameworks (Vue.js and Laravel) have conflicting folder structures when they are so often used together? Cannot the teams cooperate together if it is a typical technology stack?

@yyx990803 I see your point here. But sometimes you need to have a thin Laravel wrapper around your Vue.js SPA and you don't want to move all Vue.js code to a subfolder if that's the place where you spend the most time during development. So having it at least configurable would be a great improvement. Although the ultimate solution would be not to have any conflicts between Vue.js and Laravel default folder structure.

[kakenbok]

I have a number of vue projects running, and to avoid boilerplate I put all common configuration in a node package called 'vue2-bootsrap', which is installed via npm and from which the vue-cli gets started:

vue-cli-service serve $INIT_CWD/src/main.js

While this works perfectly fine, the cli serve/build tasks are looking into the local vue2-bootstrap/public folder and do not respect the projects public folder index.html template or local static assets like a favicon.ico or a logo.png.

It would be greate to have a publicFolder option.

[marvinrabe]

Anyone using Laravel have a look at nuxt.js and this boilerplate:

https://github.com/acidjazz/laranuxt

You can create a SPA in combination with a Laravel backend without the public folder issues of vue-cli.

Simply stop using vue-cli. In my opinion nuxt.js has the overall better design nonetheless.