Vite plugin: setTimeout() in stylesPlugin.ts #225
Comments
We need to wait for all the other modules to resolve so we can collect all the used components. 500ms was just a guess that seemed to work most of the time, I need to see if there's an actual way to wait until no other modules are pending. |
|
Can you try with this? vuetify-vite-plugin-1.0.0-alpha.9.tar.gz ( Add |
|
Rollup doesn't expose pendingRequests unfortunately, it needs something like this to work for production builds too: diff --git a/node_modules/rollup/dist/shared/rollup.js b/node_modules/rollup/dist/shared/rollup.js
index 3ea3308..494e346 100644
--- a/node_modules/rollup/dist/shared/rollup.js
+++ b/node_modules/rollup/dist/shared/rollup.js
@@ -21969,6 +21969,8 @@ function transform(source, module, pluginDriver, warn) {
});
}
+const pendingRequests = new Map()
+
class ModuleLoader {
constructor(graph, modulesById, options, pluginDriver) {
this.graph = graph;
@@ -22155,7 +22157,13 @@ class ModuleLoader {
const module = new Module(this.graph, id, this.options, isEntry, moduleSideEffects, syntheticNamedExports, meta);
this.modulesById.set(id, module);
this.graph.watchFiles[id] = true;
- await this.addModuleSource(id, importer, module);
+ const promise = this.addModuleSource(id, importer, module)
+ pendingRequests.set(id, promise)
+ await promise;
+ pendingRequests.delete(id)
const resolveStaticDependencyPromises = this.getResolveStaticDependencyPromises(module);
const resolveDynamicImportPromises = this.getResolveDynamicImportPromises(module);
Promise.all([
@@ -22401,6 +22409,7 @@ function getPluginContext(plugin, pluginCache, graph, options, fileEmitter, exis
cacheInstance = getCacheForUncacheablePlugin(plugin.name);
}
const context = {
+ pendingRequests,
addWatchFile(id) {
if (graph.phase >= BuildPhase.GENERATE) {
return this.error(errInvalidRollupPhaseForAddWatchFile());
|
|
Ok, that explains everything, thank you very much for your quick answer. I'm trying your build this afternoon, I'm coming back to you right after. I thought about a possible workaround: would it be possible to set the time based on the number of files/imports? Do you intend to suggest that update to rollup? |
Not really, it depends on the size of the project (and processor speed/other plugins) which we don't know until the build is complete. |
|
@BreizhReloaded Did you try with my changes? |
|
Hello, Sorry I took time to answer. I tried your fix and got: The currently transforming file is always different when it crashes. |
|
That's from WSL, but I got the same result from Windows. |
|
Yeah it won't work in build mode, only development |
|
Stupid me. Here it it: After that, it's only calls between 100ms and 120ms. |
|
Interestingly, the result is a bit different from WSL: |
|
Turns out that one only works in vite 2.6, I've pushed an improved version that should work with 2.7 (and prod mode) |
|
Ok. Here is the result with your new build, for Windows: And WSL: No more logs after that, even when I move across the webapp. |
|
Hmm, not sure why it's hitting the timeout there. What happens if you reduce it back to 500ms? |
|
With timer reduced from 10s to 500ms, on Windows: On WSL, I got the override error back. But that makes sense, because it's a NTFS folder, access is slower. I can make a test on a regular WSL folder, not a mounted one if you're interested. |
|
Can you change line 49 (the timeout log) from File system isn't really relevant here, in fact the WSL example is probably helpful because it's so much slower than normal. |
|
And with all the keys: |
|
Is that still with the short timeout? |
|
Yes, 500ms. It doesn't trigger the error at 10s now, even on WSL. |
|
Ok I guess that's fixed then. In alpha 10 I also added an option to configure the timeout just in case. |
|
Lovely, huge thanks for your help Kael. I'm giving a try at the alpha 10 and let you know if I notice anything. Have a nice weekend! |
|
Alpha 10 works like a charm on Windows, but crashes on WSL. That said, let's be honest: it's not a really good habit to work via WSL on a NTFS folder. I haven't tried it yet, but I'm sure it's ok on a regular non-mounted WSL folder. (I'm writing this in case people hit the same error when working on folders shared on different file systems, like containers) |
Hello,
I get
This variable was not declared with !default in the @used modulewhen overriding component Sass variables. It's not always the same variable, and the build goes sometimes through. It's less common a on small project than on a bigger one. When it crashes, the .scss cache file it not complete.I couldn't find a defined protocol to reproduce the error all the time (working on it), but I can say at the moment that it's not OS-related (tested on Windows, WSL and Ubuntu).
That seems to happen randomly, which is quite annoying. After some analysis, it seems to be related with the
setTimeout()call instylesPlugin.ts. Setting a bigger time value reduces my build error rate. What is this call made for? Why 500ms exactly?Thanks!
Edit: obviously working with the alpha 9, and using the latest Vuetify nightly.
The text was updated successfully, but these errors were encountered: