fix: only run DOM operations in the client when there is a document (#17570)

[schontz]

Description

Fixes #17570

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sapphi-red]

I think we need a warning that tells importing CSS inside worker does not work.

[sapphi-red]

I think the only change needed is this line?

[schontz]

Why would we only change this line? There are many DOM operations that will fail in workers, so it seemed best to make each one of them safe. Even if some may be safe today (e.g., first hasDocument check prevents others from running), if the code paths change at all they will throw errors as well.

[sapphi-red]

Hmm, that's true. I actually forgot about this line.

vite/packages/vite/src/node/plugins/css.ts

Line 522 in a577828

`import { updateStyle as __vite__updateStyle, removeStyle as __vite__removeStyle } from ${JSON.stringify(

While I think adding hasDocument check everywhere feels error prone as well, I think it's fine for now.

[schontz]

I agree that it is still somewhat error prone, and there are other latent bugs, such as location.reload(), which isn't available in workers either.

I suppose we could make the client more headless with hooks and guard all the "has DOM" things in one spot, but that would require some extra refactoring.

[schontz]

I ran prettier and created another commit but the linter still fails. Not sure what to do.

[sapphi-red]

I ran prettier and created another commit but the linter still fails. Not sure what to do.

Probably you need to run pnpm i before running pnpm format.

[sapphi-red]

I think we need a warning that tells importing CSS inside worker does not work.

For dev, at this line

vite/packages/vite/src/node/plugins/css.ts

Line 527 in 78e749e

`__vite__updateStyle(__vite__id, __vite__css)`,

For build, at this line (when a CSS chunk is extracted and config.isWorker is true)

vite/packages/vite/src/node/plugins/css.ts

Line 590 in 78e749e

[schontz]

Do you mean we would display a warning? Or that the code should be skipped? I'm not sure how a warning would make sense, as there is no CSS in a worker, so it's not something that you would want to hear about not happening.

[sapphi-red]

I mean displaying a warning. There's no CSS in a worker and the CSS import won't work, so I think a warning should be there. Why do you think the warning shouldn't be happening? (I am trying to understand your thoughts.)

[schontz]

The way I see it is that the client is just vite injected code that I have no control over as a developer. I am just trying to write code, and I don't even "care" that vite injects that code into my browser and worker modules.

The whole reason I started this PR is because I was getting errors in the console. It is not obvious that these are worker errors from dev tools. My thought is that adding other warnings would just cause confusion because seeing something like "CSS could not load in a worker" would not make sense because I am not trying to load CSS in a worker consciously. Maybe I happen to import a file that also imports CSS, but since CSS doesn't work in that context, it would just not be loaded.

In other words, what would I do with that warning, other than be slightly confused where it is coming from?

I would suggest that we keep each PR focused. This one fixes a bug: throwing uncaught errors in workers (which can cause real problems in workers). If there is a desire to add more warnings around things, or to refactor to be more worker-conscious, that could happen in a follow-up PR as a feature not a bug.

[sapphi-red]

I agree that the client is not something that developers would / should care about. But the CSS import means appending that CSS into the document and if that is not desired the developer should remove that import. I think this is same situation when you have a code that depends on document (e.g. document.title = 'title'), in this case you have to remove that code. The warning will tell the developers to remove the CSS import.

If you want to trim down the scope much more, I'd say let's only changing the error message and don't ignore the error. If we're ignoring the developer's code error, IMO we should have a warning message. But I'll let others chime in.

[schontz]

I don't have enough insight into vite to make a call on this. All I know is that the error messages I fixed are ones that are showing up as a result of errors in the client and had nothing to do with my code. I started this PR because the client was trying to look for its own overlays, which causes errors. That is why I'm suggesting that we separate "don't let vite client break" from "find the right amount of warnings."

[schontz]

In other words, this addresses #17570. If we want to address warnings, I'd prefer that be a separate issue with a separate PR. I don't have the time to contribute more than this fix anyway, so either this goes stale and the bug persists, or there can be a separate issue on the back log.