Remove --base option from vite:build command

[matteotrubini]

The --base option should be removed from the command to ensure that the base path is managed exclusively through vite.config.mjs, since the command line argument overrides the config file setting.

Since the base option determines the public base path that Vite uses during assets compilation, it needs to be managed on a per-package basis to ensure full customization of the process (e.g., custom path, CDN, etc.).

@jaxwilko do you agree?

[LukeTowers]

@matteotrubini is it the default value that's causing you problems?

[matteotrubini]

Yes

[jaxwilko]

Hi @matteotrubini sorry for the delay in replying.

From ourside, each "plugin" or "theme" is a unique package, therefore we define the base to be the root of that package.

Can you share an example of how this is effecting you or the issue with the current base value that is causing you problems?

[matteotrubini]

Install a font with:

npm i --save-dev @fontsource/nunito-sans

Then import it in your CSS:

@import "@fontsource/nunito-sans/latin-400.css";

Using the following configuration in vite.config.mjs:

build: {
  outDir: "assets/dist",
  assetsDir: "",
}

I get the files in the expected directory (/themes/mytheme/assets/dist/myfont.woff2), but the paths in CSS url() references are adjusted based on the --base value (e.g. /themes/mytheme/myfont.woff2), which results in 404 errors.

Removing the --base flag from the command line and instead specifying the correct value in vite.config.mjs:

base: "/themes/mytheme/assets/dist",
build: {
  outDir: "assets/dist",
  assetsDir: "",
}

makes everything work as expected.

Since Vite gives precedence to the option passed via the command line over the one defined in vite.config.mjs, my suggestion is to remove the --base flag from the command line and manage it within vite.config.mjs to allow maximum flexibility in configuration to anyone.

See also: https://vite.dev/guide/build.html#public-base-path

[jaxwilko]

I'm not necessarily again the change, but it will mean that everybody currently using vite will have to add the extra config or potentially run into issues.

As a work around, there are some options:

Vite renderBuiltUrl

This allows you to customise the url that vite will inject for the import (which could be useful if you wanted to load specific assets from a CDN). See: https://vite.dev/guide/build.html#advanced-base-options

const myCustomBase = '/plugins/acme/plugin/assets/dist/';

export default defineConfig({
    build: {
        // ...
    },
    experimental: {
        renderBuiltUrl(filename, { hostType }) {
            if (hostType === 'css') {
                return myCustomBase + filename;
            }
        },
    },
    plugins: [
        // ...
    ],
});

A custom Vite plugin

This allows you to override the base at runtime (which might be more useful to you than the above).

export default defineConfig({
    build: {
        // ...
    },
    plugins: [
        laravel({
            // ...  
        }),
        {
            name: "vite:base-override",
            async config() {
                return {
                    base: '/plugins/acme/plugin/assets/dist',
                };
            },
        }
    ],
});

I've tested both of the above and they solve the font not being loaded in the example you provided. I appreciate it's not a complete fix, but hopefully one of the above options can get you unstuck if you are currently blocked by this.

I have not massively looked into the runtime options since first intergrating Vite so just need to understand what implications there are from making this change, I'll take a look over the next few days and report back if I find any major issues that could cause problems.

[matteotrubini]

I agree with all your points. I hadn’t found a valid configuration to achieve the desired result, and that approach had led me to it anyway. At first glance, the plugin override solution seems perfect to cover my use case. I plan to run a test in the next few hours and provide feedback.

[matteotrubini]

The Vite plugin approach works like a charm and could be the solution for me. It might be worth including it as a suggestion in the documentation to ease adoption.

[LukeTowers]

Replaced by #1388