pnpm warnings

[vjpr]

I often run an app that errors due to missing peer dep. Some missing peer deps are okay and others require attention.

I want to write a plugin for Webpack that will check for missing peers when an error occurs.

Working in a large monorepo, running a full install and waiting for it to report warnings is quite slow. So I want this information cached from the last install.

I'd like a command that will display all the warnings from the last install. Note that I often run an install just for a single directory for performance purposes.

Peer errors only seem to be reported on a pnpm add x, not when running pnpm i.

Workaround

Wrap pnpm and use the json reporter to then write all the peer dep warnings to a file on disk.

An issue is that I want to use --reporter=ndjson and direct it to a file, but I also want normal log messages. Maybe we need a custom reporter.

Research

Explore using import {getPeerDependencyIssues} from '@pnpm/core' and see it's fast enough. Maybe still fall back to cache.

Would also need a way to know if cache is invalidated. I can't remember if we ended up implementing this, I think I made an earlier issue about whether pnpm can quickly know if it needs to run an install if any package.json has changed.

[vjpr]

@zkochan Do you know a way to easily use import {getPeerDependencyIssues} from '@pnpm/core'?

I am having trouble figuring out the opts needed for it to work. I looked at the tests and tried using a slightly modified testDefaults, but it wasn't able to find any workspace packages when resolving.

  const opts = await testDefaults()
  console.log(opts)
  const issues: PeerDependencyIssuesByProjects = await getPeerDependencyIssues(
    pkgs,
    {
      ...opts,
      lockfileDir: workspaceRoot,
      storeDir: '/Users/Vaughan/Library/pnpm/store/v3',
    },
  )

[zkochan]

It will be slow. It needs to do full resolution to get the peer dep issues. Better to cache the warnings from previous installation.

[vjpr]

Cool - that's exactly what I've done. Just reading the peerDependencyIssuesByProjects from the ndjson log.

[axelboc]

I'd love to see a command like this being implemented!

I typically upgrade dependencies in my monorepo with pnpm -r outdated followed by pnpm -r update --latest <pkg>..., and this sometimes surfaces peer dependency warnings, which require tweaking the "pnpm" config in the root package.json of my monorepo. This is always a trial-and-error process — I often want to know if the changes I make resolve the peer deps warnings, but running pnpm install just prints the "Already up to date" message.

Running the original pnpm -r update command is counter-intuitive and seems unreliable at printing the exact same peer deps warnings again. I often resort to stashing the version changes in my package.json files, running pnpm install, popping the stashed changes and running pnpm install again. Highly inefficient.

So a command like pnpm warnings (or pnpm peers, pnpm check, pnpm validate whatever) that re-runs the full resolution (and only that, unlike pnpm install --force) would be really helpful. This could also be a new option of pnpm install, like --resolution-only or --force-resolution. 🤷

[zkochan]

I guess pnpm install --resolution-only should work. Here's a PR: #6411

[axelboc]

Awesome, thank you!! 😍

[lorenzodallavecchia]

Hi @zkochan. I tried the new --resolution-only flag, but I don't think it fits my use case.

Suppose I have some existing peer dependency issues already reported by a previous pnpm install command.
If I don't change package.json and just run pnpm install --resolution-only I can see the peer issues.
But if package.json is changed, pnpm install --resoulution-only will not perform the installation, just the resolution.

The best for me would be a single command that:

• if the lock file is up to date, prints any lingering resolution error (i.e., peer issues),
• if the lock file is outdated, perform resolution + installation and prints any new errors.

If I understand correctly, the problem is that the resolution step is expensive.
What about if we save the issues with the last resolution in the lock file itself? This would enable cheap "replay" of errors/warnings even when not performing any resolution. After all, we can think of resolution issues as a kind of output from the resolution algorithm, on par with the package tree.