Importing public files with `/* @vite-ignore */` dynamic imports throws an error

[appsforartists]

Description

My project generates JavaScript templates for non-technical users. Before Vite, I published a zip file that looked like this:

• index.html
• config.js
• bundles/
  • mount.js

I'm trying to port this project to Vite.

To prevent Vite from minifying the source and mangling the name, I've tried putting config.js in public. However, when I run vite serve, I'm met with this error message:

Failed to load url /config.js (resolved id: /config.js). This file is in /public and will be copied 
as-is during build without going through the plugin transforms, and therefore should not be 
imported from source code. It can only be referenced via HTML tags.

Reproduction

While I respect the effort to prevent people from making mistakes, there ought to be the ability to say "no really, this is on purpose."

In short, I want to be able to tell Vite "Treat this JS file like any other asset. Don't change its name or its contents, and allow it to be imported from the devserver."

Suggested solution

The easiest solution from both an implementation and a user's POV would be a config flag, like server.allowDangerousPublicDirImports. If it's set, Vite skips throwing the error and serves the requested file as if it's any other asset.

This gives the user the final decision about what is and is not permissible in their architecture, without resorting to crazy backdoors like writing a plugin to serve JS as an assetInclude.

The term Dangerous in the flag name warns people to not set it without consideration. Using a flag gives it an obvious place to live in the documentation to make it easier for people to find. (A nod could also be included in ERR_LOAD_PUBLIC_URL.) I'm not convinced that the risk of serving files from publicDir is so high that they need to individually be whitelisted.

Alternative

Whitelisting, either by:

1. an inline comment, like import(/* vite-treat-as-asset */ 'config.js), or
2. a config field, like jsModulesInPublicDir: ['**/*config.js'].

The comment is less discoverable than a config field, but easier to use. You explicitly grant permission at the call site, so there is nothing to maintain. (Imagine if the file name changes.)

A config field is DRYer (for instance, if many packages in a monorepo share a vite.config, one setting repairs the whole project).

Additional context

config.js is effectively a JSON with generous commenting and some dependency injection to provide functionality like shuffling and centering.

It's designed to be hand-edited by people who aren't technical enough to create or maintain a web app, but are capable of editing some strings. All the complexity is in mount.js, which is just a blob to them. They can edit the config file, drag it to a file server, and have an app that meets their needs without touching the command line. Moreover, config can be generated by a web app after mount has already been minted.

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.