@types/chrome needs to be installed manually when using pnpm

[2wheeh]

Describe the bug

when using npm, TS infers browser namespace successfully:

but when using pnpm, it fails without installing @types/chrome manually:

we may need to improve docs or fix: this might be related to how pnpm handles devDependencies differently from npm.

Reproduction

just start fresh projects with pnpm following installation docs.

pnpm dlx wxt@latest init

Steps to reproduce

after installing, put your cursor on browser.runtime.* to see the inferred types.
for example, browser.runtime.id in entrypoints/background.ts.

System Info

System:
    OS: macOS 15.0.1
    CPU: (11) arm64 Apple M3 Pro
    Memory: 2.53 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.18.0 - ~/.nvm/versions/node/v20.18.0/bin/node
    npm: 10.8.2 - ~/.nvm/versions/node/v20.18.0/bin/npm
    pnpm: 9.9.0 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 130.0.6723.70
    Safari: 18.0.1
  npmPackages:
    wxt: ^0.19.11 => 0.19.13

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.

[1natsu172]

Is the extensionApi in config set to 'chrome'? Also try restarting ts-server on your editor. ref: https://wxt.dev/guide/essentials/extension-apis.html#disabling-the-polyfill

Although you are still experiencing differences in behavior due to the package manager?

[2wheeh]

@1natsu172

Is the extensionApi in config set to 'chrome'? Also try restarting ts-server on your editor.

yes, it is set to 'chrome' as configured after scaffolding the project via pnpm dlx wxt@latest init currently.

Although you are still experiencing differences in behavior due to the package manager?

yes, there seems to be an issue where browser.runtime fails to load properly.

without @types/chrome on the app devDependency

with @types/chrome on the app devDependency

plus, even in npm (or with @types/chrome in pnpm), the type inference fails for the snippet below from the docs while it works correctly with chrome namespace:

if this isn't a bug I may be missing something important here - would you have any suggestions?

[2wheeh]

as per #784 (comment), it seems to need to install @types/chrome when using pnpm.

when browser is a value it infers well but still when it is a type, it shows TS error.

[1natsu172]

@2wheeh Alright, there are two problems. I understood it too.

First, for some reason in the pnpm environment, the internal dependency @types/chrome can't be resolved and the typeof chrome is failing. The workaround to this problem is to include @types/chrome in the devDeps on the app side, as you already understood.

Here's the code inside.

wxt/packages/wxt/src/browser/chrome.ts

Line 12 in 68183b6

runtime: WxtRuntime & Omit<(typeof chrome)['runtime'], 'getURL'>;

---

The second thing is that the interface as a type cannot be inferred from the browser as you say. This one is not a package-manager dependent problem. I think it's an implementation glitch in WXT.

The workaround over here is below, and either approach should be used.

import { Runtime } from "wxt/browser";

// This types from webextension-polyfill
function handler1(params: Runtime.MessageSender) {}

// This types from @types/chrome(need install `@types/chrome`)
function handler2(params: chrome.runtime.MessageSender) {}

[2wheeh]

@1natsu172 thank you for the very clear summary 👍🏻

[aklinker1]

Alright, so @types/chrome can't be resolved because when it's a subdependency, it's located at node_modules/.pnpm/@types/chrome. However, the triple-slash reference WXT adds (/// <reference types="@types/chrome" />) only looks for node_modules/@types/chrome, it doesn't look inside .pnpm directory, so it doesn't add the types correctly.

So the solution is to use import.resolve to find the true file path of @types/chrome, and use that in the reference instead of just "@types/chrome" here:

wxt/packages/wxt/src/core/generate-wxt-dir.ts

Line 42 in 54baf21

entries.push({ module: '@types/chrome' });

[aklinker1]

I'll try and get to this soon, but if someone else wants to give it a go, see my previous comment.

[1natsu172]

Another issue is more complex, so I have split it into a separate issue. #1213

[2wheeh]

So the solution is to use import.resolve to find the true file path of @types/chrome, and use that in the reference instead of just "@types/chrome" here:

So getMainDeclarationEntry needs to be updated to resolve correct module path.

 if ('module' in ref) {
      return lines.push(`/// <reference types="${ref.module}" />`);
 }

but the thing is it seems not possible to use import.meta.* here...

ERROR Cannot use 'import.meta' outside a module :/

something around jiti or c12 might be related?

[aklinker1]

@2wheeh If you base off 0.20.0-breaking-changes, I've already merged the fix this issue. If you open a PR into that branch, it will go out in the next major version.

But we already have a method for finding the path to a NPM package in a CJS/ESM environment without import.meta:

wxt/packages/wxt/src/core/resolve-config.ts

Lines 423 to 438 in 241c907

	async function resolveWxtModuleDir() {
	// TODO: Use this once we're fully running in ESM, see https://github.com/wxt-dev/wxt/issues/277
	// const url = import.meta.resolve('wxt', import.meta.url);
	// resolve() returns the "wxt/dist/index.mjs" file, not the package's root
	// directory, which we want to return from this function.
	// return path.resolve(fileURLToPath(url), '../..');
	const requireResolve =
	globalThis.require?.resolve ??
	(await import('node:module')).default.createRequire(import.meta.url)
	.resolve;
	// resolve() returns the "wxt/dist/index.mjs" file, not the package's root
	// directory, which we want to return from this function.
	return path.resolve(requireResolve('wxt'), '../..');
	}

Forgot to link this. You could refactor this function to work with any NPM package. Then we could get this fix out before 0.20