slidevjs/slidev · error · Error

Package "${pkg}" not found in "${importer}"

Error message

Package "${pkg}" not found in "${importer}"

What it means

Thrown by the `slidev:monaco-types-loader` Vite plugin while serving Monaco Editor type definitions for code blocks. When a slide's fenced code block imports a package, Slidev generates a virtual `/@slidev-monaco-types/resolve?pkg=<name>&importer=<dir>` request; the plugin uses vitefu's `findDepPkgJsonPath(pkg, importer)` to locate that package's package.json from the importer directory. If the dependency cannot be resolved from node_modules, it throws so Monaco doesn't ship broken/incomplete type info.

Source

Thrown at packages/slidev/node/vite/monacoTypes.ts:32

    resolveId(id) {
      if (id.startsWith('/@slidev-monaco-types/'))
        return id
      return null
    },

    async load(id) {
      if (!id.startsWith('/@slidev-monaco-types/'))
        return null

      const url = new URL(id, 'http://localhost')
      if (url.pathname === '/@slidev-monaco-types/resolve') {
        const query = new URLSearchParams(url.search)
        const pkg = query.get('pkg')!
        const importer = query.get('importer') ?? userRoot

        const pkgJsonPath = await findDepPkgJsonPath(pkg, importer)
        if (!pkgJsonPath)
          throw new Error(`Package "${pkg}" not found in "${importer}"`)
        const root = slash(dirname(pkgJsonPath))

        const pkgJson = JSON.parse(await fs.readFile(pkgJsonPath, 'utf-8'))
        let deps = Object.keys(pkgJson.dependencies ?? {})
        deps = deps.filter(pkg => !utils.isMonacoTypesIgnored(pkg))

        return [
          `import "/@slidev-monaco-types/load?${new URLSearchParams({ root, name: pkgJson.name })}"`,
          ...deps.map(dep => `import "/@slidev-monaco-types/resolve?${new URLSearchParams({ pkg: dep, importer: root })}"`),
        ].join('\n')
      }

      if (url.pathname === '/@slidev-monaco-types/load') {
        const query = new URLSearchParams(url.search)
        const root = query.get('root')!
        const name = query.get('name')!
        const files = await fg(
          [

View on GitHub (pinned to 0d798ace58)

Solutions

  1. Install the missing package in the deck's userRoot: `npm i <pkg>` (or pnpm/yarn equivalent), then restart the dev server.
  2. If the import is illustrative only and you don't want the real dependency, add the package name to Slidev's monaco-types ignore list so the loader skips it (the code already filters via `utils.isMonacoTypesIgnored`).
  3. In a monorepo, ensure the dependency is resolvable from the Slidev `userRoot` directory (install at that workspace, not only at the repo root) so vitefu's upward walk finds it.
  4. Double-check the spelling/ casing of the package in the code block and that it matches the installed package name exactly.

Example fix

// before: code block imports a package that isn't installed
```ts
import { z } from 'zod'
```
// after: install it so Monaco can resolve types
//   pnpm add zod
// or mark it ignored in slidev config if it is example-only:
// slidev.config.ts -> monacoTypesIgnored: ['zod']
Defensive patterns

Strategy: validation

Validate before calling

// Before relying on a package for Monaco types, verify it resolves from the
// deck's userRoot using the same resolver the plugin uses:
import { findDepPkgJsonPath } from 'vitefu'
async function canResolvePkg(pkg: string, importer: string): Promise<boolean> {
  return Boolean(await findDepPkgJsonPath(pkg, importer))
}
// if false, install the package or add it to monacoTypesIgnored.

Type guard

function isInstalledPackage(pkg: string, importer: string): Promise<boolean> {
  return findDepPkgJsonPath(pkg, importer).then(Boolean)
}

Prevention

When it happens

Trigger: A slide contains a code block importing a package (e.g. `import x from 'some-pkg'`); Monaco requests its types; the loader walks node_modules from the `importer` (defaults to `userRoot`) and `findDepPkgJsonPath` returns null. Common when the package is genuinely absent, is a bundled/inline type stub with no installed package.json, or when a monorepo hoisting layout puts the dep outside the resolver's search path.

Common situations: Authoring example code in slides that imports libraries never added to the deck project; using a monorepo workspace where the dependency is hoisted to a root that vitefu won't traverse from the slide's userRoot; importing a package whose package.json sits behind a symlink vitefu won't follow; TypeScript path-mapped aliases that have no physical node_modules entry.

Related errors


AI-assisted analysis of slidevjs/slidev@0d798ace58 (2026-08-12). Data as JSON: /api/errors/fd91494743190f4e. Report an issue: GitHub.