HMR Very Slow
I have to save my files a few times, and then still wait a while before any changes are reflected. The tab reloads, but the changes aren't present, any ideas?
26 Replies
This is when you are working with the CSUI right?
check your bundle size - how large is the output content script? And what are you importing inside of it?
It's both, BGSW and CSUI
its just incredibly slow
the frontend reloads, but it doesn't actually reflect changes
and the background doesn't even show that it was reloaded
on bgsw - there's a missing condition in its runtime atm to reload, I will get that fixed in the next patch
on CSUI - can you inspect the final dev build and see what's the size of the resulting content scripts?
And what are you importing inside these things? CSUI cannot use HMR atm btw, it can only autoreload (we haven't figure out how to inject new script specifically to the react dev instance of CSUI, since it's mounted much later)
hmmmm
@rocket has reached level 1. GG!
gimme a second, ill get that info for u
content bundle looks to be about 3.7MB
in dev tho
in prod, its 170kb
im using tailwind, could be the issue potentially
While we are here, is there any way to use a different bundler, namely vite? I am running parcel with bun, but it's still slow. I was previously using vite, and the DX/speed was next level
Vite uses esbuild internally whereas parcel uses SWC. PR is welcome to add an esbuild based js transformer, but the gist is they are pretty similar (both skip the type checking step)
Is it speed that you seek from vite, or is there other DX feature from it that you miss?
Also, when working with csui, did you save the CS file itself, or did you save another component? On my end with tw in CSUI, it took about 50ms for incremental bundling
Speed mainly, but the speed rn is pretty fast
I save the
context.tsx file, I am doing like a rough draft on my extension right now, so its not really broken down just yet
I get fast incremental builds, but they don't update in the browser
I either have to remove the extension
or
spam reload the extension, until I see the actual changes
rn, it builds, the frontend reloads, but the changes aren't reflected, I can tell because I update a class and the class line remains the same, even after multiple page reloads
Compared to the other boilerplate I was using, this is way better, everything is exported configs, with a dynamic manifest which I love
but the other one I used, when I saved background.js, it showed reload immediately, and reflected the changes, same with content.jsyeah it's tricky with csui. I will fix the bgsw reload next year tho ;p
when it comes to bgsw reload, what was the behavior in the other tool? Does it like reload the whole extension for you, or does the bgsw silently applies change and rerun itself?
afaik the 2nd requires to figure out how to reset just bgsw, but not sure how (?). BTW if you can link me to your other boilerplate with the bgsw reload working I can study and incorporate it into plasmo
applies changes and reruns
@rocket has reached level 2. GG!
it was called
one sec
GitHub
GitHub - guocaoyi/create-chrome-ext: 🚀 Scaffolding your chrome exte...
🚀 Scaffolding your chrome extension, boilerplates:react \ vue \ svelte \ solid \ preact \ alpine \ lit \ stencil \ inferno \ vanilla - GitHub - guocaoyi/create-chrome-ext: 🚀 Scaffolding your chrome...
i have found that when i move the components to separate files
live reload is instant
although
incremental builds are taking some time
3s
occasionally faster
So that's the only real issue now, incremental build times
Got a break thru with HMR, PR coming soon
I'm not sure about incremental bundling - that's really depends on the size of your bundle and how fast tailwind compile
but the latest runtime has largely resolved most of the issues regarding livereload race condition
yeah this use vite and the crx-vite plugin directly, which are a series of esbuild plugins.
their implementation is very similar to what I just did lol