Allow importing public files for base support

[bluwy]

Currently the docs says:

Assets in public cannot be imported from JavaScript.

It is however possible to do so, with the caveat that we don't guarantee it to work. In fact plugin-vue's asset transform converts all URLs as import via includeAbsolute: true, so theorectically this have always been supported.

Proposal

We should allow importing from public and polish up any bugs regarding it.

Benefits

1. We can rebase public URLs depending on the base set, and how the advanced base options are used.
2. Potentially reload on change?

Note

If we follow the docs and specify "/image.png" as a string instead, this does not work for base ./ and /foo/ as the page would be requesting from https://example.com/ instead of https://example.com/foo/. Unless we hardcode as "/foo/image.png", this won't work with dynamic base too.

Related issues

• Vite strips base URL from request #9234
• Build 404 when importing fonts from public/ with import.meta.glob #9169

[sapphi-red]

Some references how this is handled by other tools:

• Create React App and Vue CLI provides %PUBLIC_URL%/process.env.PUBLIC_URL to handle base.
• Next.js requires users to add base on their own for images. For links, it's handled automatically.
• Sapper required users to add base on their own. (I guess, didn't find any document)
• esbuild has --public-path option that prepends a base path for import path from './foo.png'.
• parcel doesn't have a public directory, so users needs to handle on their own.

[sapphi-red]

IMO public directory is for:

1. assets not referenced in source code (e.g. robots.txt)
2. files needs to preserve the file name
3. files needs to preserve the content as-is

For 1, this proposal is not related since we don't reference it from code.

For 2, this happens when the file is referenced from a non-JS file. For a JS file, you can just use import url from './foo', but in non-JS file this is not possible. Because we cannot use import, we cannot take advantage of this proposal in this case.

For 3, we can take advantage of this proposal.

[sapphi-red]

I find it unnatural that the imports are not included in the bundle and only used to resolve paths. But that might be just because I'm not used to it.

[patak-dev]

I think it would be more clear if we go with @benmccann's suggestion of only allowing public files access when using absolute paths. I think having the file in the public folder is enough to know that it won't be bundled and users will get used to it.

[benmccann]

For reference, here's the issue I had filed: #7363

[Andre-ADPC]

Hi everyone. It seems that there is no clear resolution yet about leveraging the Advanced Base Option beyond the experimental scenarios, or am I simply not looking in the right places?

Admittedly, I'm still relatively uneducated regarding building component libraries. Still, after reviewing numerous articles about building component libraries, in my case specifically for Vue 3, I could not find clear-cut indications of how one would go about using a Font Awesome icon library, brand-specific custom CSS files or other brand-specific assets like various SVG and PNG image assets for example when building custom SFC's or globals for that matter, without being able to "pull" those assets in from some arbitrary or conditional distribution of project folders.

Any search on "how to apply the Advanced Base Option" when building component libraries comes back empty-handed, except for the relevant section in the Vite documentation. The rest of the planet is surprisingly silent about it, regarding use cases, tutorials or even articles mentioning this build approach.

Or am I stupidly ignorant and missing the actual functionality of this experimental feature?

Can any of you possibly give me pointers to other references, even if it's one pointing me to the "forget-about-it-go-to-exit" route?
Thanks!

[bluwy]

The "base" and building component libraries are kinda tangential and aren't really related. The "base" is largely related to hosting your site on a certain base path. Your component library shouldn't be a concern of it.

[Andre-ADPC]

Thanks for the feedback, @bluwy

[ondrejvelisek]

I just came around related issue. I will list my use-case here. Hope it helps with designing this feature.

Im using Vite to bundle my custom component library. (Vite Library mode)

There are also svg icons in icons/ folder. I want to expose all of the svg files to dist. So library consumer can use them.

There is components/ library with react components. Which are also exposed to the consumer. But some of the components also imports some icons.

If I add icons/ folder as publicDir Vite config option, the Vite yells at me "Assets in public directory cannot be imported from JavaScript.". If I do not do it, it does not copy all icons to dist folder.

Workaround Im currently using: Vite static copy plugin.

[mindingdata]

100% the exact same scenario here, even with icons.

We publish a component library that utilizes icons within it, but we also want consumers to utilize the icons by themselves (Or even hotlinked in emails and the like). So we need them references in code and in the public folder.

Admittedly, this doesn't necessarily mean they need to be in the public folder in source control, but I do then need to do a work around to have them xcopied into the public dir at compilation time.

The other thing to remember is that at times, the library itself may not use an icon, but we want it to be published anyway. In that scenario, due to treeshaking, it won't even end up be published anywhere. Which again, is a headache.

[nguyenbatranvan]

I'm not sure, but I wrote a library that supports multiple shared folders. You can see the library here, and the documentation here. Does it help you?