Are you getting the error TS2307: Cannot find module ‘@pnp/sp/presets/all’ or its corresponding type declarations while building a SharePoint Framework (SPFx) web part?

This error usually occurs when your SPFx project does not have the required PnPjs package installed, the installed PnPjs version does not match your import syntax, or dependencies were not restored correctly after downloading, cloning, or moving a project.

In this tutorial, you will learn why the error occurs, how to fix it, and how to use the correct PnPjs import approach for both legacy and modern SPFx projects.

Error Message

You may see one of the following errors when running the SPFx project:

Error - [tsc] src\webparts\example\components\Example.ts(10,25): error TS2307:
Cannot find module '@pnp/sp/presets/all' or its corresponding type declarations.

Or, in Visual Studio Code:

Cannot find module '@pnp/sp/presets/all'.ts(2307)

Here is a screenshot for your reference of how the error looks:

The error can appear while running one of these commands:

gulp serve

gulp build

gulp bundle --ship

Why This Error Occurs

The import path @pnp/sp/presets/all belongs to an older PnPjs coding pattern. Your project will fail to compile if TypeScript cannot locate that package and path inside the local node_modules folder.

Common causes include:

• The @pnp/sp package is not installed in the SPFx solution.
• You downloaded or cloned an SPFx project without the node_modules folder.
• The package was not saved correctly in package.json.
• Your code uses PnPjs v2 syntax, but npm installed PnPjs v3 or a newer version.
• The SPFx version, Node.js version, TypeScript compiler, and PnPjs version are incompatible.
• The VS Code TypeScript server or SPFx build cache is using stale dependency information.Important: Do not blindly install the latest PnPjs package when working with an older SPFx project. First check whether the project uses legacy PnPjs syntax or the modern PnPjs syntax.

Check Your Existing Import

Open the TypeScript file that displays the TS2307 error. It may be a web part file, service file, or React component.

If you see code like the following, your project uses the older PnPjs v2 pattern:

import { sp, Web, IWeb } from "@pnp/sp/presets/all";

import "@pnp/sp/lists";
import "@pnp/sp/items";

The sp global object and the presets/all import are associated with older PnPjs implementations.

This error can come in the code, like in the screenshot below:

In this case, you have two practical options:

1. Install a compatible PnPjs v2 version and keep the existing code.
2. Upgrade the code to modern PnPjs syntax using spfi() and SPFx().

For a quick fix in an existing production or legacy project, option 1 is usually safest.

Check out Get Data Between Two Dates from a SharePoint List Using SPFx

Quick Fix for Legacy SharePoint Framework Projects

If your SPFx project already uses this import:

import { sp } from "@pnp/sp/presets/all";

Install PnPjs v2 from the root folder of your SPFx project.

npm install @pnp/sp@2 --save

If your solution uses other PnPjs packages, install compatible v2 versions for them as well.

npm install @pnp/common@2 @pnp/logging@2 @pnp/odata@2 @pnp/sp@2 --save

After the installation finishes, run the SPFx project again:

gulp serve

If the local workbench starts without the TS2307 error, the issue is resolved.

Verify PnPjs Installation

You can verify the installed PnPjs version by running this command from the SPFx project root:

npm list @pnp/sp

A legacy project using @pnp/sp/presets/all should normally show a v2 package, similar to this:

@pnp/[email protected]

You can also check the package version directly in the package.json file.

{
  "dependencies": {
    "@pnp/sp": "^2.15.0"
  }
}

If @pnp/sp is missing from the dependencies section, install it again:

npm install @pnp/sp@2 --save

Read Bind SharePoint List Items to a Dropdown in an SPFx Web Part

Fix for Modern PnPjs and SPFx Projects

Modern PnPjs uses a factory-based approach. Instead of importing a global sp object from @pnp/sp/presets/all, create an SPFI instance and configure it with the SPFx context.

Install the required PnPjs packages:

npm install @pnp/sp @pnp/logging --save

Then add the required imports in your SPFx web part file.

import { spfi, SPFx, SPFI } from "@pnp/sp";
import "@pnp/sp/webs";
import "@pnp/sp/lists";
import "@pnp/sp/items";

Create an SPFI variable in your web part class:

private _sp: SPFI;

Initialize it in the onInit() method:

public async onInit(): Promise<void> {
  await super.onInit();

  this._sp = spfi().using(SPFx(this.context));
}

You can now use this._sp to work with SharePoint lists and items.

public async getListItems(): Promise<void> {
  const items = await this._sp.web.lists
    .getByTitle("Projects")
    .items
    .select("Id", "Title")
    .top(10)();

  console.log(items);
}

This approach is recommended for current SPFx solutions because it makes the PnPjs configuration explicit and avoids using the legacy global sp object.

Complete Modern PnPjs Example in SPFx

The following example retrieves items from a SharePoint list named Projects.

import * as React from "react";
import * as ReactDom from "react-dom";
import { Version } from "@microsoft/sp-core-library";
import {
  type IPropertyPaneConfiguration,
  PropertyPaneTextField
} from "@microsoft/sp-property-pane";
import { BaseClientSideWebPart } from "@microsoft/sp-webpart-base";

import { spfi, SPFx, SPFI } from "@pnp/sp";
import "@pnp/sp/webs";
import "@pnp/sp/lists";
import "@pnp/sp/items";

export interface IProjectWebPartProps {
  listName: string;
}

export default class ProjectWebPart extends BaseClientSideWebPart<IProjectWebPartProps> {
  private _sp: SPFI;

  public async onInit(): Promise<void> {
    await super.onInit();

    this._sp = spfi().using(SPFx(this.context));
  }

  public render(): void {
    this.loadProjects().catch((error) => {
      console.error("Error while loading projects:", error);
    });
  }

  private async loadProjects(): Promise<void> {
    const listName = this.properties.listName || "Projects";

    const items = await this._sp.web.lists
      .getByTitle(listName)
      .items
      .select("Id", "Title", "Created")
      .orderBy("Created", false)
      .top(10)();

    this.domElement.innerHTML = `
      <div>
        <h2>Latest Projects</h2>
        <ul>
          ${items.map((item) => `<li>${item.Title}</li>`).join("")}
        </ul>
      </div>
    `;
  }

  protected get dataVersion(): Version {
    return Version.parse("1.0");
  }

  protected getPropertyPaneConfiguration(): IPropertyPaneConfiguration {
    return {
      pages: [
        {
          header: {
            description: "Project list settings"
          },
          groups: [
            {
              groupName: "Settings",
              groupFields: [
                PropertyPaneTextField("listName", {
                  label: "SharePoint list name"
                })
              ]
            }
          ]
        }
      ]
    };
  }
}

Use the Required Feature Imports

With modern PnPjs, install the base package and import only the functionality your code uses.

For example, to read SharePoint lists and list items:

import { spfi, SPFx } from "@pnp/sp";
import "@pnp/sp/webs";
import "@pnp/sp/lists";
import "@pnp/sp/items";

To work with folders and files, add these imports:

import "@pnp/sp/folders";
import "@pnp/sp/files";

To work with site users and groups, add these imports:

import "@pnp/sp/site-users/web";
import "@pnp/sp/site-groups/web";

To use search in SharePoint:

import "@pnp/sp/search";

Importing only the required modules keeps your code easier to understand and helps avoid unnecessary dependencies.

Do Not Mix PnPjs Versions

A common issue occurs when a project contains PnPjs packages from different major versions.

For example, avoid configurations like this:

{
  "dependencies": {
    "@pnp/common": "^2.15.0",
    "@pnp/logging": "^3.25.0",
    "@pnp/odata": "^2.15.0",
    "@pnp/sp": "^3.25.0"
  }
}

All PnPjs packages in a solution should use the same major version.

For a legacy PnPjs v2 project:

{
  "dependencies": {
    "@pnp/common": "^2.15.0",
    "@pnp/logging": "^2.15.0",
    "@pnp/odata": "^2.15.0",
    "@pnp/sp": "^2.15.0"
  }
}

For a modern PnPjs project, use matching modern package versions:

{
  "dependencies": {
    "@pnp/logging": "^3.25.0",
    "@pnp/sp": "^3.25.0"
  }
}

After changing package versions, delete the installed packages and lock file before reinstalling dependencies.

For Windows PowerShell:

Remove-Item -Recurse -Force node_modules
Remove-Item package-lock.json
npm install

For Command Prompt:

rmdir /s /q node_modules
del package-lock.json
npm install

For macOS or Linux:

rm -rf node_modules package-lock.json
npm install

Then run:

gulp clean
gulp build
gulp serve

Check SPFx and Node.js Compatibility

SPFx projects are tied to specific versions of Node.js, TypeScript, Gulp, and Microsoft 365 development dependencies. Installing an unsupported Node.js version can cause package installation failures, build errors, or misleading TypeScript errors.

Check the SPFx version in your project by opening package.json and locating the SharePoint dependency.

{
  "dependencies": {
    "@microsoft/sp-core-library": "1.17.4",
    "@microsoft/sp-webpart-base": "1.17.4"
  }
}

Also check your active Node.js version:

node --version

Check the npm version:

npm --version

If the project is older, use the Node.js version supported by that SPFx release. Consider using Node Version Manager for Windows, macOS, or Linux when you need to maintain several SPFx projects with different runtime requirements.

Update the Rush Stack Compiler When Needed

Some SPFx projects require a newer Rush Stack compiler to work correctly with modern PnPjs and TypeScript definitions.

Check your package.json file for a dependency similar to this:

{
  "devDependencies": {
    "@microsoft/rush-stack-compiler-3.9": "0.4.47"
  }
}

If your SPFx version supports it, update the compiler package to version 4.2.

First remove the old package:

npm uninstall @microsoft/rush-stack-compiler-3.9

Then install the newer compiler:

npm install @microsoft/rush-stack-compiler-4.2 --save-dev

Next, update the extends value in tsconfig.json.

{
  "extends": "./node_modules/@microsoft/rush-stack-compiler-4.2/includes/tsconfig-web.json"
}

Do not change the Rush Stack compiler version unless it is compatible with your installed SPFx version. Upgrading compiler tooling in an old solution without checking compatibility can introduce additional build errors.

Clear the SPFx Build Cache

Sometimes the package is installed correctly, but the SPFx build process still shows the old TS2307 error.

Run the following commands from the root folder of the SPFx project:

gulp clean
gulp build

Then start the local workbench again:

gulp serve

If you use Visual Studio Code, restart the TypeScript service.

1. Open the Command Palette by pressing Ctrl + Shift + P.
2. Search for TypeScript: Restart TS Server.
3. Select the command.
4. Wait for Visual Studio Code to reload the TypeScript project.

You can also close and reopen Visual Studio Code after reinstalling npm packages.

Check the Package Folder

If the error continues, check whether the module actually exists in node_modules.

For a legacy PnPjs v2 project, verify that this folder is available:

node_modules/@pnp/sp/presets

You should find the required preset-related files inside the package.

For modern PnPjs projects, do not expect @pnp/sp/presets/all to be the correct import path. Update the code to use this pattern instead:

import { spfi, SPFx } from "@pnp/sp";

If node_modules/@pnp/sp does not exist, the package installation did not complete successfully.

Run this command again:

npm install @pnp/sp --save

If your legacy code still uses presets/all, install the compatible major version:

npm install @pnp/sp@2 --save

Check package.json and package-lock.json

Your package.json file is the source of truth for project dependencies. The @pnp/sp package should appear under dependencies, not only in the local node_modules directory.

A valid legacy dependency entry looks like this:

{
  "dependencies": {
    "@pnp/sp": "^2.15.0"
  }
}

A valid modern dependency entry looks like this:

{
  "dependencies": {
    "@pnp/sp": "^3.25.0"
  }
}

After modifying package.json, run:

npm install

Commit both package.json and package-lock.json to source control. This helps every developer on the project restore the same package versions.

Avoid Copying Outdated PnPjs Code

Many older SPFx tutorials use this syntax:

import { sp } from "@pnp/sp/presets/all";

sp.setup({
  spfxContext: this.context
});

This syntax can be valid in an existing PnPjs v2 project, but it should not be copied into a newer SPFx solution without checking the installed PnPjs version.

For new development, prefer the modern approach:

import { spfi, SPFx } from "@pnp/sp";

const sp = spfi().using(SPFx(this.context));

The modern approach creates an explicit PnPjs instance and configures it with the current SharePoint Framework context.

Troubleshooting Checklist

Use this checklist if you still see the error Cannot find module ‘@pnp/sp/presets/all’ in SPFx.

• Confirm that you are running commands from the SPFx solution root folder.
• Check whether @pnp/sp exists in package.json.
• Run npm list @pnp/sp to see the installed version.
• If your code uses @pnp/sp/presets/all, install @pnp/sp@2.
• If you are using PnPjs v3 or later, replace presets/all imports with spfi() and SPFx().
• Ensure all installed @pnp/* packages use the same major version.
• Delete node_modules and package-lock.json, then run npm install.
• Run gulp clean and gulp build.
• Restart Visual Studio Code or restart the TypeScript server.
• Check whether your Node.js version is supported by your SPFx version.
• Verify that the configured Rush Stack compiler is compatible with your SPFx solution.

Frequently Asked Questions

Final Thoughts

The fastest fix for TS2307: Cannot find module ‘@pnp/sp/presets/all’ in SPFx is to identify the PnPjs version expected by your code.

If the project uses the legacy sp object and presets/all import, install PnPjs v2:

npm install @pnp/sp@2 --save

If you are building or modernizing an SPFx solution, replace the legacy import with the modern spfi() and SPFx() approach. This prevents version-related import errors and gives your SharePoint Framework solution a cleaner, maintainable PnPjs setup.

Bijay Kumar

After working for more than 18 years in Microsoft technologies like SharePoint, Microsoft 365, and Power Platform (Power Apps, Power Automate, and Power BI), I thought will share my SharePoint expertise knowledge with the world. Our audiences are from the United States, Canada, the United Kingdom, Australia, New Zealand, etc. For my expertise knowledge and SharePoint tutorials, Microsoft has been awarded a Microsoft SharePoint MVP (12 times). I have also worked in companies like HP, TCS, KPIT, etc.