You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 calls deno info just to obtain the file location.
There are some temporary paths from vite that will not resolve to anything, but we still perform deno info for 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 resolveId in parallel. Therefore, to make caching utilized, we need a lock around deno info and 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 info for them, as we can parse deno.json for 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:
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 info
just to obtain the file location.There are some temporary paths from vite that will not resolve to anything, but we still perform
deno info
for 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
resolveId
in parallel. Therefore, to make caching utilized, we need a lock arounddeno info
and 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 info
for them, as we can parsedeno.json
for 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: