Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Worker doesn't refresh after file changes #20104

Closed
oscarotero opened this issue Aug 9, 2023 · 4 comments
Closed

Worker doesn't refresh after file changes #20104

oscarotero opened this issue Aug 9, 2023 · 4 comments

Comments

@oscarotero
Copy link
Contributor

oscarotero commented Aug 9, 2023

Hi. I have the following code:

// worker.js

const now = Date.now();
const number = 33;

console.log(now, number);

In a different file, this is the code to run it using workers. There's a watcher to detect changes in the worker.js file and reload the worker to reflect these changes:

// run.js

let worker = new Worker(new URL('./worker.js', import.meta.url), { type: 'module' });

const watcher = Deno.watchFs("./worker.js");

for await (const _event of watcher) {
  worker.terminate();
  worker = new Worker(new URL('./worker.js', import.meta.url), { type: 'module' });
}

After running the code, if I change something in the worker.js file, the new Worker is created but the file content is freezed, so it always logs the current date and the same number, even if it was changed:

worker deno run -A run.js
1691593005115 33
1691593010247 33
1691593010270 33
1691593012773 33
1691593012796 33
1691593015992 33
1691593016017 33
1691593019023 33
1691593019053 33

I think this is an unfortunate behavior (probably a bug?)

@sigmaSd
Copy link
Contributor

sigmaSd commented Aug 9, 2023

This seems to work in the browser

index.html

<script type="module">
  export let worker = new Worker(new URL("./worker.js", import.meta.url), {
    type: "module",
  });
  const button = document.createElement("button")
  button.onclick = updateWorker
  button.textContent = "update"
  document.body.appendChild(button)

  export function updateWorker() {
    console.log(worker)
    worker = new Worker(new URL("./worker.js", import.meta.url), {
      type: "module",
    });

  }
</script>

worker.js

// worker.js

const now = Date.now();
const number = 33;

console.log(now, number);

updating worker.js then clicking the button correctly reflects the new change

@bartlomieju
Copy link
Member

I'm somewhat surprised this works in the browser. The reason that it doesn't work as you expect is that Deno will have the file after it's fetched initially and it won't be fetched again until the process restarts. You can "cache bust" by appending a querystring to the URL that will force Deno to treat it as different module:

new Worker(new URL(`./worker.js?cachebust=${Date.now()}`, import.meta.url), { type: 'module' });

@oscarotero
Copy link
Contributor Author

@bartlomieju thanks for the reply. Unfortunately, cache busting doesn't fix the problem because not only the worker.js file is cached but also any other module imported by the worker.

For example, I have the following module:

// mod.js

export const now = Date.now();
export const number = 33;

And the woker.js file import it to log the numbers

// worker.js

import { now, number } from "./mod.js";

console.log(now, number);

The result is the same:

1691658538005 34
1691658545295 34
1691658545318 34

The number never changes, but the Date does. I guess Deno only cache the file content, not the values exported by the module that are re-evaluated again in the Worker.

My use case is to create a way to safely refresh the build (from Lume) after any change in a JS/TS file. Something like the Deno's --watch mode but using a Worker, in order to better control when and how the rebuild has to be done.

AFAIK, Workers are the only way in JavaScript to run code in separated threads, completely independent to the main script and other Workers. So I think they shouldn't share the same file cache.

@oscarotero
Copy link
Contributor Author

I just realized that this bug was fixed in #23634 , so I'm closing this.
thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants