Changes to #included shaders not taking effect, unless parent shader is changed or vite is restarted

Question

Changes to #included shaders not taking effect, unless parent shader is changed or vite is restarted

jonikorpi opened this issue 2 years ago · 7 comments

jonikorpi commented 2 years ago

Reproducible here:
https://stackblitz.com/edit/vitejs-vite-hwdvnu?file=included.glsl

Change something in index.glsl
→ changes take effect, refresh happens
Change something in included.glsl
→ changes don't take effect, nothing happens, even a manual refresh doesn't help
Change something in index.glsl, or restart vite
→ changes to included.glsl take effect

This sounds like it could be related to #12?

P.S. Thank you for building this plugin! It's been a great help for wrangling shaders in my game projects. :)

Answer 1 · 2022-09-01T16:32:39.000Z

Hi @jonikorpi ! Thanks for opening this issue and creating a reproducible demo. You're totally right, this is one feature I'm still missing here and yes, it's related to #12 . Actually it's the same and my comment there is still relevant. So any help would be very appreciated. 😅

Anyways, I'm going to close that one since I've added other improvements mentioned there and one thing left is this "hot reloading". Hopefully that's possible... 🤞

Feel free to take a look & create a pull request if you have some time, I'd really appreciate that.
And thanks for using this plugin. Please consider smashing a ⭐if you've found it useful, thanks!

Answer 2 · 2022-10-12T15:29:02.000Z

Hi @jonikorpi! I've just published a new version that should solve this issue. If you have some time, feel free to test v0.5.1 on your project and open a new issue if something still doesn't feel right. Any feedback would be much appreciated, thanks!

Answer 3 · 2022-10-13T15:05:47.000Z

Thank you so much! It's working nicely. ^_^

Only issue I can see is that if I save a shader multiple times in a row too quickly, I get the following Vite error:

18:02:41 [vite] Internal server error: Cannot read properties of undefined (reading '0')
      at Context.load (file:///.../node_modules/.pnpm/vite@3.1.8/node_modules/vite/dist/node/chunks/dep-4da11a5e.js:43270:65)
      at Object.load (file:///.../node_modules/.pnpm/vite@3.1.8/node_modules/vite/dist/node/chunks/dep-4da11a5e.js:41084:46)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at async loadAndTransform (file:///.../node_modules/.pnpm/vite@3.1.8/node_modules/vite/dist/node/chunks/dep-4da11a5e.js:37312:24)

BUT the same thing seems to also happen if I spam-save vite.config.js, so I'm guessing it might just be an issue with Vite itself. Probably not worth looking into for now. :)

Answer 4 · 2022-10-13T15:52:56.000Z

Probably you're right, @jonikorpi , but can you do me a favor and test again this spam-save after a small change here. Just wrap these rows into a setTimeout callback and tell me if this issue still persists. (You can do it right in the node_modules directory and restart the dev server) Thank you so much!

setTimeout(() => {
  const now = Date.now() / 1e3;
  utimes(configFile, now, now, () => {});
}, 500);

Answer 5 · 2022-10-14T08:40:52.000Z

@UstymUkhman the setTimeout makes it happen less, but I still got it to happen by spamming a bit. 🤷

Answer 6 · 2022-10-14T10:41:15.000Z

Great, thanks for your help @jonikorpi! I'm going to implement some throttling in there for the next release, but I guess that's pretty much all I can do. 🙂

Answer 7 · 2022-10-16T16:59:24.000Z

Closing this since v0.5.2 was released with use of debounced callback to avoid server crashes when spamming file saves.