Uncaught (in promise) ReferenceError: window is not defined

[amal]

Describe the bug

Tried with 0.19.2 and 0.18.15.

This error persists both in dev and prod builds.

Reproduction

Archive.zip

Steps to reproduce

Just run the extension form attached archive and see.

System Info

System:
    OS: macOS 14.5
    CPU: (11) arm64 Apple M3 Pro
    Memory: 76.47 MB / 18.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.4.0 - ~/.nvm/versions/node/v22.4.0/bin/node
    npm: 10.8.1 - ~/.nvm/versions/node/v22.4.0/bin/npm
    pnpm: 9.6.0 - ~/.nvm/versions/node/v22.4.0/bin/pnpm
    bun: 1.1.18 - ~/.bun/bin/bun
  Browsers:
    Chrome: 127.0.6533.72
    Safari: 17.5
  npmPackages:
    vite: ^5.3.5 => 5.3.5 
    wxt: ^0.18.2 => 0.18.15 

Used Package Manager

pnpm

Validations

• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[amal]

Another issue is that some styles are lost in prod build, but it probably can be workarounded.

[amal]

Tried to not set a Vite version in the package.json, but with no luck.

[aklinker1]

Interesting error, thanks for reporting, will look into this soon!

[1natsu172]

It looks like the might be importing files related to typesafe-i18n in background.ts. Some modules that depend on the window object are being unintentionally included?

[aiktb]

I have encountered this error, which is actually an error of vite dynamic import failure. Let me guess, you used dynamic import in the background.

FYI - Background does not support the use of dynamic import. w3c/webextensions#212

[amal]

I've tried to remove typesafe-i18n usage from the background entrypoint. It helped to change things slightly, but now I have another error for dev build:

Uncaught (in promise) Error: Not implemented: file:// pattern matching. Open a PR to add support Context

Nothing is changed for the prod build, though:

Why are these things even happening?

Also, typesafe-i18n maybe can use a window somewhere inside, but it's not necessary to work. Can it be just ignored? The original error is happening not in the typesafe-i18n but somewhere in the code from WXT or Vite.

[amal]

Even for empty background.ts entrypoint with only console.log('Hello background!'); it still shows this error.

But I've found how to work around this issue: remove type: 'module' from the background entrypoint config.

Probably something is wrong there when the entrypoint is declared as a module.

[1natsu172]

@amal In the repro zip you submitted, simply commenting out i18next results in both dev and prod working fine on my machine. Have you made any other changes?

[amal]

Actually, I left i18next as is and just commented out type: 'module' in the entrypoint declaration.

[1natsu172]

@amal Wait...whether or not you keep type: 'module', I don't encounter the error on my machine. Simply removing the i18next prevents the error. So…try running rm -rf node_modules, then pnpm store prune and again pnpm i.

Also, according to @aiktb's theory, the i18n-utils.async.ts in your project dynamically imports the loader, which is at least a point of concern.

Additionally, your project uses hooks to modify quite a few JS files and manifests, which could potentially be causing environmental differences. 🤔

[1natsu172]

@amal Sorry, I was misread your message. If you keep i18next and set type: "module", it will output chunks in ESM format. Without type: "module", it defaults to CJS format, resolving as static objects, and thus, the error doesn't occur.

bundled with type: "module"(ESM)

bundled without type: "module"(CJS)

Dynamic import isn't support in the background script, it might be better to use synchronous implementations instead.

[amal]

@1natsu172, thank you. Yes, I plan to use only the synchronous implementation. i18n-utils.async.ts is generated automatically, but I don't use it.

[aklinker1]

Yeah, so this is one of the reasons I don't recommend using a i18n library over the builtin APIs... You end up either having to either fetch JSON files asynchronously or include all your translations in each individual entrypoint bundle :/

You do get some benefits, like being able to switch languages, but other than that... 🤷 For larger, more complex apps, it probably make sense to use a library.

I swear one day I'll finish #758...

[aklinker1]

So just to clearify, the problem was dynamic imports in a background marked as type: "module", right?

Solutions:

1. Don't use dynamic imports
2. Don't use type: "module"

If we need to keep this open, feel free to reopen!

[1natsu172]

Right. I've checked that using dynamic imports in the background(with type: "module") causes the same issue also in my project.

This is a trade-off.

• Can't avoid dynamic imports => avoid using type: "module" in the background
• Want to use type: "module" in the background => avoid using dynamic imports