There will be temporary vite.config.js.timestamp files that have not been cleaned up
Describe the bug
When I use Ctrl+C to terminate the process of launching vite, I may leave behind the temporary file vite.config.js.timestamp.xxxxx.mjs
By checking the code, I found that the problem may be caused by the loadConfigFromBundledFile method in packages/vite/src/node/config.ts, for esm. When the temporary file is written locally and the process ends, this issue will be triggered, mainly when dynamicImport is time-consuming
I am considering whether it is possible to check and clean up temporary files every time the loadConfigFromBundledFile method is executed
Reproduction
https://stackblitz.com/edit/vitejs-vite-rmx6nh?file=index.html&terminal=dev
Steps to reproduce
No response
System Info
System:
OS: Windows 10 10.0.19045
CPU: (8) x64 Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
Memory: 1.05 GB / 7.76 GB
Binaries:
Node: 16.13.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
npm: 8.12.1 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: Spartan (44.19041.1266.0), Chromium (113.0.1774.42)
Internet Explorer: 11.0.19041.1566
npmPackages:
@vitejs/plugin-react: ^4.0.0 => 4.0.0
vite: ^4.3.5 => 4.3.5
Used Package Manager
pnpm
Logs
No response
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 reports the same bug to avoid creating a duplicate.
- [X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
- [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
- [X] The provided reproduction is a minimal reproducible example of the bug.
Related to this, these files should not be generated within the project root. Their existence causes race conditions when running multiple build/lint/type-checking/etc processes simultaneously.
Here's a sample error from my CI/CD output.
@cat/rambo:build: transforming...
Error: @cat/rambo:type: vite.config.ts.timestamp-1685726155761-9773a069c871a.mjs(2,25): error TS2307: Cannot find module 'file:///home/runner/work/core/core/tools/vite-config/.out/index.js' or its corresponding type declarations.
Having the same issue using this Chrome Extension vite template
Organizing the issues with the approach with using data: (#13269, reverted by #13731):
- There's a bug in Node.js 17.5.0 - 17.x.x: #13631
- This can be ignored as we'll drop Node.js 17 in Vite 5
- Vite wasn't able to replace non-static dynamic
imports to absolute paths: #13730- Maybe we can inject a function (or import a function from Vite package) that resolves relative/bare imports and replace all dynamic
importcalls with that function
- Maybe we can inject a function (or import a function from Vite package) that resolves relative/bare imports and replace all dynamic
Same here. Is there a way to set location of it somewhere in /tmp/ at least? Or process with SWC?
Same here. Is there a way to set location of it somewhere in
/tmp/at least? Or process with SWC?
this is need
could these files be created in cacheDir by default?
Same problem here: we have a plugin that is loaded in vite to inject git hash in the build, So it fails because the git directory non clean at that time. Workaround was to add an exclusion in gitignore.
A better place could be /tmp or somewhere in ./node_modules/.vite
i didnt get the solution,same issue at my production level README.md ecosystem.dev.config.cjs package-lock.json src vite.config.ts TODO.md index.d.ts package.json tailwind.config.js vite.config.ts.timestamp-1702552301768-9c4937d01b86.mjs azure-pipelines.yml index.html postcss.config.js tsconfig.build.json vite.config.ts.timestamp-1702552358222-31b40cd2cec51.mjs biome.json.txt init.sh public tsconfig.json dist node_modules push.sh tsconfig.node.json
I solved this issue. vite.config.ts.timestamp-* generates in node 16 version, node 20 version.
- I degrade my node version to 18 and I added below commands in my package.json, finally it works. Before build execute, it removes the vite.config.ts.timestamp-* generation and then build is applied.
In my package.json,_
"scripts": {
"build": "tsc && rm -rf dist/vite.config.ts.timestamp-* && vite build",
}
Note that : Same way I tried in node 16, 20 version, it didnt worked, but finally worked for node 18 version which stops generating timestamp and deployed to production in my pm2.
These temporary files also cause tsconfig.json to throw a linter warning with configurations that do not have any issues in the absence of these files:
Cannot write file 'D:/ExampleProject/Config/Vite/index.ts.timestamp-1705304356087-78af772b6fa5d.mjs' because it would overwrite input file.
also having this issue on node v21, i'm running vite with child_process.exec
I think a related issue I'm having to this one..
For me vite.config.mts is building in a loop, or vite.config.ts does if I specify type: module in package.json
So going to go back to seeing the deprecated warnings since it doesn't do this with vite.config.ts
Having this issue when I try to run a Vite+Svelte project with PM2
This (or something similar) happens regularly when eg. the Vite dev server is running while doing a git rebase and the dev server terminates due to some error, and then causes the dev server startup to fail permanently until the vite.config.js file is deleted, in case the original .ts file uses eg. ESM default imports, which for some reason will fail in the transpiled .js.
This might be a separate bug though, because this happens due to .ts transpilation and the file does not have the timestamp suffix.
seems like i can't find any solution to solve this matter. Is there any way to resolve this? thanks
My process is simple:
I have added it to my .gitignore
.gitignore
vite.config.*.timestamp-*
And I've created a script to delete these files on my main package.json ( I have a mono repo)
package.json
{
"scripts": {
"clean": "find . -type f -name 'vite.config.*.timestamp-*' -ls -delete 2>/dev/null"
}
}
Then I run
pnpm run clean
and ✨ gone!
Probably partially related, but sometimes in nx monorepo when running multiple vite builds in parrarel, I get this error:
error TS6053: File 'package/package/vite.config.package.ts.timestamp-1710918996371-a57b80255a0c5.mjs' not found.
The file is in the program because:
I got same problem!
These temporary files also cause
tsconfig.jsonto throw a linter warning with configurations that do not have any issues in the absence of these files:Cannot write file 'D:/ExampleProject/Config/Vite/index.ts.timestamp-1705304356087-78af772b6fa5d.mjs' because it would overwrite input file.
The files will also cause a problem with my setup because I am using turborepo to prebuild my vite workspaces and then lint. The error will happen on eslint or prettier, when file is not cleaned up.
[warn] vite.config.ts.timestamp-1711554296877-215d5766798.mjs
html-ui:lint: [warn] Code style issues found in the above file. Run Prettier to fix.
vite.config.ts.timestamp-1711553549825-4b69edd70157b.mjs
html-ui:lint: [error] Unable to read file "vite.config.ts.timestamp-1711553549825-4b69edd70157b.mjs":
html-ui:lint: [error] ENOENT: no such file or directory, open '<project_home>/vite-storybook-boilerplate/packages/html-ui/vite.config.ts.timestamp-1711553549825-4b69edd70157b.mjs'
Adding the file to ignores is a workaround, but we have to ensure it gets added to each tool...
Adding them to .gitignore and using clean seems like not be 100% effective, atleast when ran in Gitlab using NX monorepo :/
worst problem is that, it either doesn't happens for a weeks, or happens multiple times in a row, hence reproduction is hard :/
Wouldn't it be a better solution to write the generated .mjs to the OS's defined tmpdir or are there other reasons this folder is generated in the project root? https://github.com/vitejs/vite/blob/6cccef78a52492c24d9b28f3a1784824f34f5cc3/packages/vite/src/node/config.ts#L1217-L1227
Wouldn't it be a better solution to write the generated .mjs to the OS's defined
tmpdiror are there other reasons this folder is generated in the project root?https://github.com/vitejs/vite/blob/6cccef78a52492c24d9b28f3a1784824f34f5cc3/packages/vite/src/node/config.ts#L1217-L1227
One of our projects is currently struggling with annoying errors caused by these tmp files interfering with Nx and this suggested fix would resolve them, but I am also not knowledgeable enough to judge potential reprecussions.
I'm getting a similar issue to @OndraSlejtr
[Failed to process project graph. Run "nx reset" to fix this. Please report the issue if you keep seeing it.
The "nx/js/dependencies-and-lockfile" plugin threw an error while creating dependencies:
Error: "Unable to load /Users/.../apps/frontend/vite.config.mts.timestamp-1716994186861-389651fa93221.mjs: No such file or directory (os error 2)
Wouldn't it be a better solution to write the generated .mjs to the OS's defined
tmpdiror are there other reasons this folder is generated in the project root? https://github.com/vitejs/vite/blob/6cccef78a52492c24d9b28f3a1784824f34f5cc3/packages/vite/src/node/config.ts#L1217-L1227One of our projects is currently struggling with annoying errors caused by these tmp files interfering with Nx and this suggested fix would resolve them, but I am also not knowledgeable enough to judge potential reprecussions.
Workaround that fixed our problem, at least from what we have observed so far, was simple adding wildcard for these tmp files into every ignore possible (.nxignore, .eslintignore, tsconfig and any other tools that might have a problem with these files).
Workaround that fixed our problem, at least from what we have observed so far, was simple adding wildcard for these tmp files into every ignore possible (.nxignore, .eslintignore, tsconfig and any other tools that might have a problem with these files).
Unfortunately, as has been mentioned, this does nothing to help in certain environments where the directory isn't writeable. I have containerised my app using docker and the project folder where these files is written is a read-only bind-mount, and even if it wasn't read-only, root permissions would still be required. If I have to allow writes to the host filesystem I start to question the benefit of containerisation in the first place.