Closed grandsong closed 10 months ago
Start a new pull request in StackBlitz Codeflow.
I digged for the option base
and found a workaround.
Still, this is an issue introduced by Vite 5. It needs to be fixed.
我也遇到了这个问题,请问如何屏蔽这个错误。这并不是错误,并且在 5.0.7
版本之前也没有这个错误,是从 5.0.8
开始出现此错误!!!
I'm experiencing exactly the same issue on one of my projects (React + TS). It appeared after upgrading from vite 4.4.9 to vite 5.0.10. I'm also using a custom base:
// vite.config.ts
export default defineConfig({
plugins: [react()],
base: '/web/',
And I'm importing a small .js file that contains global configuration variables:
// index.html
<script src="/config.js"></script>
Every time I reload a page with the dev server, I get this misleading error message:
[vite] Pre-transform error: 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.
@bluwy May I ask, in which version will this issue be fixed?
It's not released yet. But I think we'll cut another patch that includes this fix this week before starting the next Vite minor next week.
Describe the bug
After migrating from Vite 4.x to 5.0.8, for dev server, whenever the page (index.html) loads, in terminal I get errors like:
I have 'pixi.min@7.3.1.js' in the '/public' folder and
<script src="/pixi.min@7.3.1.js"></script>
in the 'index.html'.Exactly as the message suggests: 'It can only be referenced via HTML tags.'
The program in browser actually runs without any error, as well as before (at Vite 4).
Such error messages in terminal is unnecessary and very very annoying!
I know "Assets in public cannot be imported from JavaScript."
I do not "import" pixi.js. I just use it as a lib so that a global variable
PIXI
is defined for my code to access.I guess the error message is a new feature in Vite 5 to warn some ignorant developers against misuse of modules which should not be in '/public' folder.
However, my practice is not a mistake. I have good reasons to do so instead of importing 'pixi.js' as a normal NPM module.
Note: There is a similar issue #14181 which however was automatically closed due to absence of minimal reproduction.
Why don't others encounter this issue?
Unlike most people, I dynamically define the option
base
in 'vite.config.ts':In this way, the entry URL of the web site is like 'http://localhost:3333/some/path/based/on/mode/'.
In my 'package.json', there are three mode for building.
In my company, part of the standard development process is:
1) Commit repo with branch 'test' 2) Build and get something like 'https://cdn-my.company.com/test/project-name/index.html' 3) Our QA team tests it 4) Merge changes from 'test' into branch 'prod' 5) Build and get something like 'https://cdn-my.company.com/prod/project-name/index.html' 6) Our QA team tests it
Is there a work around?
Yes.
When in 'development' mode, namely using dev server, an undefined
base
can still allow entry from 'http://localhost:3333/some/path/based/on/mode/' while any other path in this domain works as well...And now the error messages are gone.
What solution do I suggest?
Ideally, the dev server can smartly recognize that the js libs are indeed 'referenced via HTML tags', whereupon skip the warning. Just like when
base
is undefined.Or at least, add a config option for me to purposely mute the warning for good.
Where is the code for this error message?
In 'packages\vite\src\node\server\transformRequest.ts'
Why not as a normal NPM module?
I tried.
When building, if only a single js file is bundled into, it will be too big (more than 2.5Mb). And codes would grow and grow in the future.
So I use the API
build.roolupOptions.outpu.manualChunks
to split codes into small chunks.After I update my repo, I want the requests for changed files from the browser of each end user to be minimal (with browser cache and CDN, unchanged files take very little request costs).
My policy is:
However, there are too many chuncks from node_modules.
I managed to combine some (for example, 'vue' and '@vue' into just 'vue') but still quite a few stay.
Many tiny chunks are a waste of http requests and thus should be avoided.
The key for a good result is balance between the number of files and coverage of decoupling.
I found that more than half of my tiny chunks are dependencies of 'pixi.js' and 'pixi-spine'.
Besides, building time is increased for the these two large modules.
So I replaced them with public lib counterparts and had been very satisfied.
... until I migrated to Vite 5 and be ambushed by the annoying warning messages.
Reproduction
https://stackblitz.com/edit/vitejs-vite-eg4ypm?file=index.html
Steps to reproduce
pnpm dev
System Info
Used Package Manager
pnpm
Logs
Validations