Potential optimizations to improve the plugin's speed significantly #55
Comments
|
Go for it, these are all valid optimization strategies 👍 |
3 tasks
lbsal
added a commit
to masslbs/deno-vite-plugin
that referenced
this issue
Apr 14, 2025
This fix builds on the insight in denoland#55 but does so by performing the minimal change required to fix the underlying issue. The reason for this departure from denoland#55 is due to our project's build failing when executed using the proof of concept's plugin, presumably due to some unknown change introduced on part of the proof of concept's extensive revision. The fix reuses @notcome's lock component and threads said lock through the codebase to ultimately place it around the `deno info --json ${id}` calls.
lbsal
added a commit
to masslbs/deno-vite-plugin
that referenced
this issue
May 7, 2025
This fix builds on the insight in denoland#55 but does so by performing the minimal change required to fix the underlying issue. The reason for this departure from denoland#55 is due to our project's build failing when executed using the proof of concept's plugin, presumably due to some unknown change introduced on part of the proof of concept's extensive revision. The fix reuses @notcome's lock component and threads said lock through the codebase to ultimately place it around the `deno info --json ${id}` calls.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I have made a proof-of-concept plugin that brings a 10x speedup in my mini-sized monorepo + react router setup, from 50s ish to 5s ish in initial dev build, and slashes my production build time by half.
The following optimizations are possible:
When we call
deno info --json, we get not only that particular file's location, but also all of its imports'. The current code partially uses that info to resolve a relative import path to the absolute path within that module, but nonetheless callsdeno infojust to obtain the file location.There are some temporary paths from vite that will not resolve to anything, but we still perform
deno infofor them. I am not familiar with vite or front-end bundling in general, but in my code base, I have found at least the following:/__manifest?/@id/__x00/shadcn/The last one is project-specific. Still, it is nice to allow users of this plugin to enter a list of prefixes to do a fast failure.
Vite currently runs
resolveIdin parallel. Therefore, to make caching utilized, we need a lock arounddeno infoand all the post-processing from step 1.Right now, I am using the final resolved file path as the absolute unique ID for a file, just as your original code. However, I think for local packages within a workspace, we shall be able to cache them also by their package names. Furthermore, we might not need to call
deno infofor them, as we can parsedeno.jsonfor each local package manually.Maybe we can cache those results in a local SQLite file to further improve the performance.
I am very new to Deno and honestly not very familiar with Vite either. Therefore, I am not very confident about my optimization steps outlined above -- though it does work for my build and brings much joy to the developer experience. I am willing to start a pull request to improve the package, but I would like to have a discussion on these matters, to make sure my understanding of the whole thing is correct.
The text was updated successfully, but these errors were encountered: