fix: avoid leaking @types/node into client code

[aleclarson]

Overview

The defineWxtPlugin function is referenced by the generated .wxt/types/imports.d.ts module, which is used by client code. Therefore, we need to avoid importing from wxt/src/types.ts, as it depends on Node.js-specific packages (like vite). This inadvertently introduces Node.js globals into the extension's client environment, which is undesirable (e.g. it breaks the return type of setTimeout).

Edit 1

Updated other "offending" imports. Split out the option-related types (into option-types.ts) and the client-related types (into client-types.ts).

Manual Testing

Without this change, you should see setTimeout return a NodeJS.Timeout object.

After this change, setTimeout will return a number as expected.

Related Issue

#1459

[netlify]

✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	a6969b0
🔍 Latest deploy log	https://app.netlify.com/sites/creative-fairy-df92c4/deploys/67f5641dfb1cf8000811180b
😎 Deploy Preview	https://deploy-preview-1531--creative-fairy-df92c4.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[aleclarson]

I can retarget this to #1085 if you prefer. LMK!

[Timeraa]

I can retarget this to #1085 if you prefer. LMK!

I think that would be better as @aklinker1 should be merging 0.20.0 very soon as he rebased everything from main into it and we've been testing it

[Timeraa]

0.20.0 is released and out so make sure to rebase your changes on main!

[aleclarson]

Rebased ✅

[aklinker1]

I still see NodeJS.Timeout in the demo extension after building WXT on this branch:

Restarted my language server multiple times to be sure.

Isn't this... impossible to do? For example, you have to import import { defineConfig } from 'wxt' in the wxt.config.ts file. Doesn't that mean node types will always be referenced and included in your project?

[aleclarson]

Isn't this... impossible to do? For example, you have to import import { defineConfig } from 'wxt' in the wxt.config.ts file. Doesn't that mean node types will always be referenced and included in your project?

You can definitely avoid it. The key is to use multiple tsconfig.json files. Here's how I do it:

• /tsconfig.json used by default (e.g. *.config.ts modules and maybe some /scripts/*.ts modules)
  • any default compilerOptions I use
  • types: ["node"]
• /src/tsconfig.json used by /src/**/* modules
  • extends ../tsconfig.json
  • include: ["./"] (to prevent config/script modules from being pulled in)
  • types: [] (to prevent @types/node from being pulled in; you can add others as necessary, like vite/client)

This is off the top of my noggin, so could be missing a detail. I assume there isn't a demo with this setup already?

[aleclarson]

I would love to get this merged. Let me know what the next step is.

[aklinker1]

Sorry, been busy and it's too easy to just go down the list of recent notifications and forget about these older ones. But I'm catching up!

You are definitely right about using multiple TSConfig files. Nuxt supports projects using one tsconfig file or multiple by generating 4 different tsconfig files in the .nuxt dir:

• tsconfig.json - extend this to use a simple, single tsconfig file setup
• tsconfig.base.json - extend this to split the app/server dirs into separate TS projects. It has references to the 2 other config file below that configure their respective directories.
• tsconfig.app.json
• tsconfig.server.json

Names might be wrong, I'm typing this up by memory.

I'd like to support both approaches as well.

WXT generates the first one today, but we could generate the other 3. So I think the full solution here is, in addition to the changes already in this PR, update the generate-wxt-dir.ts file to generate the 3 other config files.

I'd recommend looking at a real nuxt project if you've never seen their setup before. A basic starter will have them:

pnpm create nuxt@latest <project-name>
pnpm nuxt prepare
ls .nuxt | grep tsconfig

The new tsconfig file generation can come in a separate PR - I need to re-review your changes here since it's been a while, but we'll get this merged soon! But it's past midnight here and I have some early meetings in the morning... So I'll re-review it tomorrow after work