Service worker rebuilds gets increasingly slower despite being reportedly fast

[jakobrosenberg]

Describe the bug
After a fresh start of npm run dev Sapper is fast and there's no delay between client and service worker finishing their rebuilds. However the longer Sapper runs, the slower the rebuild of the service worker gets. After a while the delay between client and service worker being rebuilt increases to over 10+ seconds. Despite the long rebuild time, the service worker reports its rebuild time to be only ~50 ms.

✔ server (902ms)
✔ client (1.2s)  
//increasing delay here up to +10 secs
✔ service worker (40ms)

Logs
The logs show that the build times are normal. Service worker is shown to have been rebuilt in ~50 ms even though it can take more than 10 seconds.

To Reproduce
I have no idea how to reproduce it, but I've experienced it a few times on different projects.

Information about your Sapper Installation:

• Your operating system: Windows 10 x64

• Your hosting environment: local

• Sapper version: 0.27.8

• Svelte version (Please check you can reproduce the issue with the latest release!)
  3.9.1 and 3.12.1

• Whether your application uses Webpack or Rollup
  Rollup

Severity
It's not breaking in any way, just annoying as it breaks the flow of development.

Additional context
The problem goes away if I stop Sapper restart it with npm run dev
I could probably solve this on my own, but I wouldn't know where to start. client and service worker both shows fast build times, yet there's a long delay between them. Can I debug the rebuild process for further information?

[jakobrosenberg]

I attached the debugger and as expected the same thing happens. I don't know if anything can be determined from the fact that the debugger reports after the long pause and not before.

src\components\Modal.svelte changed. rebuilding...
✔ server (1.1s)
✔ client (1.4s)
----------> 10 SECONDS PAUSE HERE <----------
Debugger listening on ws://127.0.0.1:9222/a77d8a21-c85b-47b3-b12e-6546792e3cee
For help, see: https://nodejs.org/en/docs/inspector
✔ service worker (30ms)

[jakobrosenberg]

I've made a small script small script that shows this bug.

Simply save the below script as trigger-rebuild.js in src folder and then add import "./trigger-rebuild.js" to server.js

//trigger-rebuild.js
import path from 'path'
import fs from 'fs'



(async function() {
    const timerFile = path.resolve(__dirname, 'timer')
    const tfExists = await fs.existsSync(timerFile)
    if (tfExists) {
        const timerFileHandle = fs.readFileSync(timerFile, 'utf8')
        console.log('BUILD LOOP: ' + (Date.now() - timerFileHandle) / 1000)
    }


    setTimeout(async () => {
        const file = path.resolve(__dirname, '../../../src/routes/generatedfile.svelte')        
        fs.writeFile(timerFile, Date.now(), ()=>{})
        fs.writeFile(file, `
            <style>.foo {color: red}</style>    
            <div class="foo">foo</div>
            <div>${Math.random()}</div>`, ()=>{})
    }, 2000);
})()

The script will create a .svelte file and update it two seconds after each rebuild, causing a new rebuild. The loop will continue as the build time keeps increasing.

[thgh]

I have noticed the logs appearing up to 5 seconds after the build was already done, it reminds me of the time that server logs were not coming through at all.

[jakobrosenberg]

@thgh Logs?

[mlusca]

Any feedback on that? Happens to me too.

[f-elix]

Same here. If I don't restart the dev server regularly I can get up to +10sec builds.

[hongnk]

I have to remove [hash] in node_modules/sapper/dist/rollup.js to solve this problem (I don't think dev build needs to have hash anyway).

[benmccann]

@jakobrosenberg said he's on Windows. How about everyone else? I'm wondering if this happens on any OS

[antony]

I don't think I see this on Linux, but I'll keep an eye out.

[hongnk]

This happens for me on Windows. Every new build generates new output files with a new hash in __sapper__/dev without deleting old files and I think that's why it's getting slower once there are too many files. Removing hash in rollup.js temporarily solves problem so new build will overwrite old files, but with the expense of files being cached cannot automatically refreshed unless disable cache in browser.

[yorgyetson]

I've been running into this too. The dev server is not removing old files and things really start slowing down if I don't restart it.
Win 10 x64
3.23.2 svelte
0.27.16 sapper
2.17.0 rollup

[jormaj]

It looks like things are much better now that I'm on WSL2 (and all project files on the Linux/Ubuntu drive).
Does anyone notice slowdowns on that setup?

[yorgyetson]

Minor update. I had a VS Code git extension that seemed to not respect the .gitignore contents and was trying to do things with the build files. I still have build files piling up, but removing the faulty extension reduced my build times from 30s to 2s. Even after multiple rebuilds VSCode no longer shoots up to 100% CPU usage.

I still have to restart the dev server to clear out the pileup of files, but I'm able to do so far less frequently now since they don't kill performance like they used to.

Maybe this will be helpful to someone else.