Developers working on Node projects have likely encountered errors related to package resolution at some point in their careers. It's so common that removing the
node_modules directory and reinstalling all of the project dependencies is one of the first things folks attempt in an effort to resolve these.
From my experience, these errors tend to be a result of one of the following:
- Misconfiguration of the project (
vite buildsettings, etc.);
- ESM/CommonJS dependencies clashing within a project and its build settings;
- Projects were built by the authors with the expectation that a specific package manager would be used to install and maintain the project dependencies.
Today I want to focus on that last point - the expectations of which package manager would be used in the project.
For the most part
pnpm tend to work similarly but there are some differences.
As an example,
pnpm doesn't install directory dependencies by default like
npm does. If you're used to using
npm and expecting that those dependencies are installed by default, you'll likely be puzzled as to why the project isn't working out-of-the-box if
pnpm install was used instead.
Guidance as to which package manager to use from the authors of the project tends to be communicated subtly. Commands in an
install script in the
package.json, the presence of a certain type of lockfile, or using a particular package manager in commands to be copy-and-pasted in a project's
README.md are a few examples.
Rather than rely on chance that other developers will notice these hints and use the right package manager in our projects, let's be explicit about what we expect!
packageManager property in the
package.json can be used to explicitly tell developers working on the project which one they are expected to use.
By setting this in our projects, we can save developers valuable time when they're first getting started, or are looking to just get it running.
This is still an experimental property within Node but is worth paying attention to if errors related to the use of different package managers is something you and your teams run into more often than you'd like.