fix(bridge,nitro,nuxi,nuxt3,vite): ensure debounced/async handlers run in order

[danielroe]

🔗 Linked issue

resolves nuxt/nuxt#13492

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Across the nuxt codebase, this PR uses debounce + debounce.promise to prevent initialising a new handler before the old one has finished running (which should prevent double access to files, for example, or multiple callbacks pushing the same plugin to app.plugins, as in the issue linked above).

At the same time, we drop the timeout from (for example) 300 to 1. This leads to a significant increase in DX as it feels much faster.

This PR also:

• fixes a bug with nuxi dev where any path starting with .nuxt was not triggering a reload (such as .nuxtignore)
• adds .env and .nuxtrc files to trigger a full nuxt reload

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[netlify]

✔️ Deploy Preview for nuxt3-docs canceled.

🔨 Explore the source changes: 9acb39f

🔍 Inspect the deploy log: https://app.netlify.com/sites/nuxt3-docs/deploys/62306f1d05fa67000813b074

[pi0]

pdebounce.promise waits for the previous promise. When saving file multiple times, the first call takes precedence which is usually an unwanted behavior to build not the latest code. I think we shouldn't set debounce value to a low number like 1ms. It will loose it's purpose of debouncing effect.

[danielroe]

The reason I've combined debounce.promise + debounce is that it will wait for the previous promise to resolve, and then run the function again, ensuring the latest changes are reflected.

What would you say is the purpose of the debouncing effect?

[pi0]

Awaiting on the promise and combining are fine. Changing debounce delay from 200ms to 1ms is almost the same as not having a debnounce effect but a serial await which uses first change not last as .promise avoid calling function if previously running.

[danielroe]

I think I might be misunderstanding you. The current implementation will use both first and last change, as I've explained.

Might be worth considering not debouncing then, because honestly the experience of speed without the artificial 300ms delay is 🔥

[pi0]

See this sandbox please: https://stackblitz.com/edit/node-vnqatc?dev=dev&file=index.mjs

Running pdebounce with 1ms saves one delay but randomly missing last update (v3 should normally be shown in output)

[pi0]

As a regression of this PR, the last build might still be skipped. We are working on a better solutioon.