pnpm Warnings Explained
Last Updated: 2025-10-26
This guide explains common pnpm warnings you'll see during pnpm install and whether you should worry about them.
1. Lockfile Version Mismatch ⚠️
Warning Message
WARN Ignoring not compatible lockfile at /workspace/pnpm-lock.yaml
What It Means
- Your
pnpm-lock.yamlwas generated with a different major version of pnpm - Example: Lockfile from pnpm 9.x, but you're using pnpm 10.x
- Lockfile formats change between major versions
Is This Bad?
⚠️ Somewhat concerning - Can cause:
- Inconsistent dependency resolution across team
- Different versions installed than expected
- CI/CD failures if versions don't match
How It's Fixed
Our post-create.sh script now automatically handles this:
# Check lockfile version
LOCKFILE_VERSION=$(grep "lockfileVersion:" pnpm-lock.yaml | cut -d "'" -f 2 | cut -d '.' -f 1)
PNPM_MAJOR_VERSION=$(pnpm --version | cut -d '.' -f 1)
# Regenerate if mismatch
if [ "$LOCKFILE_VERSION" != "$PNPM_MAJOR_VERSION" ]; then
rm pnpm-lock.yaml
pnpm install # Creates new lockfile
fi
What You Should Do
- ✅ Nothing - The script handles it automatically
- ✅ Commit the regenerated lockfile
- ✅ Ensure all team members use the same pnpm version (see
package.json→packageManager)
2. Deprecated ESLint Version ⚠️
Warning Message
WARN deprecated eslint@8.57.1: This version is no longer supported.
Please see https://eslint.org/version-support for other options.
What It Means
- ESLint 8.x reached end-of-life (October 2024)
- ESLint 9.x is the current supported version
- Security updates and bug fixes stopped for 8.x
Is This Bad?
ℹ️ Low priority - ESLint 8.x still works, just unsupported
Why We Haven't Updated
- ESLint 9 has breaking changes to config format
- Flat config required (no more
.eslintrc) - Many plugins still catching up to ESLint 9
- Not urgent during MVP.0 development
When to Update
After MVP.0 - During tech debt sprint:
# Update ESLint to 9.x
pnpm update eslint@^9.0.0
# Update TypeScript ESLint plugins
pnpm update @typescript-eslint/eslint-plugin@^8.0.0
pnpm update @typescript-eslint/parser@^8.0.0
# Migrate config to flat format
# See: https://eslint.org/docs/latest/use/configure/migration-guide
What You Should Do
- ✅ Ignore for now - ESLint 8.x works fine
- 📅 Add to tech debt backlog: "Upgrade ESLint to 9.x"
- ⚠️ Monitor security advisories (unlikely for linting tool)
3. Deprecated Subdependencies ⚠️
Warning Message
WARN 5 deprecated subdependencies found:
@humanwhocodes/config-array@0.13.0
@humanwhocodes/object-schema@2.0.3
glob@7.2.3
inflight@1.0.6
rimraf@3.0.2
What It Means
- These are transitive dependencies (dependencies of your dependencies)
- You don't directly control them
- They're deprecated by their maintainers
Is This Bad?
ℹ️ Very low priority - Not your problem to fix
Why They're Deprecated
@humanwhocodes/*: Part of ESLint 8.x (will go away with ESLint 9 upgrade)glob,inflight,rimraf: Old versions still used by legacy packages
What You Should Do
- ✅ Ignore completely - These are transitive deps
- ✅ They'll be updated when direct dependencies update
- ✅ Run
pnpm auditto check for actual security issues
4. Ignored Build Scripts 🔒
Warning Message
╭ Warning ─────────────────────────────────────────────────────────────────────╮
│ │
│ Ignored build scripts: esbuild. │
│ Run "pnpm approve-builds" to pick which dependencies should be allowed │
│ to run scripts. │
│ │
╰──────────────────────────────────────────────────────────────────────────────╯
What It Means
- pnpm 9+ security feature to prevent supply chain attacks
- Packages with build scripts now require explicit approval
- Protects against malicious code execution during
npm install
Is This Bad?
✅ Good thing! - This is a security improvement
Does it break anything?
- ❌ No - esbuild ships prebuilt binaries
- Falls back to prebuilt version automatically
- Only matters if you need to compile from source
Why We Haven't Approved
- Not necessary - packages work with prebuilt binaries
- Keeps security posture stricter
- Will approve when we need to build from source
How to Approve (If Needed)
Option 1: Interactive approval (recommended)
pnpm approve-builds
# Shows list, you select which to approve
Option 2: Approve specific package
pnpm config set scripts-allow-list esbuild
Option 3: Auto-approve in CI/CD
# In .npmrc (not recommended for local dev)
unsafe-perm=true
What You Should Do
- ✅ Ignore the warning - Everything works
- ✅ Only approve if a package explicitly fails
- ✅ Document which packages you approve and why
5. Outdated Package Versions ℹ️
Warning Message
dependencies:
+ @linear/sdk 31.0.0 (62.0.0 is available)
devDependencies:
+ @types/node 20.19.23 (24.9.1 is available)
+ @typescript-eslint/eslint-plugin 6.21.0 (8.46.2 is available)
+ vitest 1.6.1 (4.0.3 is available)
What It Means
- Informational: newer versions exist
- Does NOT mean you're using vulnerable versions
- Just tells you about available updates
Is This Bad?
ℹ️ Informational only - Not a problem
Why Packages Show as Outdated
Your package.json uses caret ranges (^):
^31.0.0= "any 31.x.x version"- pnpm installs latest within that range
- But shows you about breaking updates (62.0.0)
Understanding Version Ranges
| Range | Meaning | Example |
|---|---|---|
^31.0.0 | Compatible (patch/minor) | 31.0.0 → 31.9.9 ✅, 32.0.0 ❌ |
~31.0.0 | Patch only | 31.0.0 → 31.0.9 ✅, 31.1.0 ❌ |
31.0.0 | Exact version | Only 31.0.0 ✅ |
* or latest | Any version (dangerous!) | Always latest ⚠️ |
How to Update
Check what's outdated:
pnpm outdated
Update within semver range (safe):
# Updates to latest compatible versions
pnpm update
# Example: ^31.0.0 → 31.9.9 (if available)
Update to latest (breaking changes):
# Updates package.json to latest versions
pnpm update --latest
# Example: ^31.0.0 → ^62.0.0
# ⚠️ May require code changes!
Update specific package:
# Safe update
pnpm update @linear/sdk
# Breaking update
pnpm update @linear/sdk --latest
What You Should Do
- ✅ Ignore during development - Focus on features
- ✅ Review updates monthly or quarterly
- ✅ Check changelogs before major updates
- ✅ Test thoroughly after updates
Summary: Priority Matrix
| Warning | Priority | Action | When |
|---|---|---|---|
| Lockfile mismatch | 🟡 Medium | Auto-fixed by script | Automatic |
| Deprecated ESLint | 🟢 Low | Upgrade to ESLint 9 | After MVP.0 |
| Deprecated subdeps | 🟢 Very Low | Ignore | N/A |
| Ignored build scripts | 🟢 Low | Ignore (works fine) | Only if broken |
| Outdated packages | 🟢 Low | Review quarterly | Maintenance sprint |
Quick Reference Commands
# Check lockfile version
head -1 pnpm-lock.yaml
# Check pnpm version
pnpm --version
# Check outdated packages
pnpm outdated
# Update within semver range (safe)
pnpm update
# Update to latest (breaking)
pnpm update --latest
# Check for security vulnerabilities
pnpm audit
# Fix auto-fixable vulnerabilities
pnpm audit --fix
# Approve build scripts
pnpm approve-builds
# Regenerate lockfile
rm pnpm-lock.yaml && pnpm install
CI/CD Considerations
Recommended Approach
Development (local):
pnpm install # Uses lockfile, updates if needed
CI/CD (production):
pnpm install --frozen-lockfile # Fails if lockfile doesn't match
Why?
- Local: Flexibility to update dependencies
- CI/CD: Reproducibility is critical
- Catches lockfile drift before it reaches production
Example GitHub Action
- name: Install dependencies
run: pnpm install --frozen-lockfile
- name: Verify lockfile is up to date
run: |
pnpm install
git diff --exit-code pnpm-lock.yaml
Related Documentation
- pnpm Configuration:
.npmrc - Package Manager Version:
package.json→packageManager - DevContainer Setup:
.devcontainer/post-create.sh - ESLint Config:
.eslintrc.json(TODO: migrate to flat config)
Questions?
"Should I use --force?"
- ❌ NO -
--forcebypasses ALL safety checks - ✅ Use the intelligent lockfile checking in
post-create.sh
"Why doesn't the script approve build scripts automatically?"
- 🔒 Security principle: explicit over implicit
- Most packages work without build script execution
- Only approve when you trust the package
"Can I disable these warnings?"
- ⚠️ Not recommended - warnings provide useful information
- If needed:
pnpm install --loglevel error(hides warnings)
"How do I check if dependencies have security issues?"
pnpm audit
pnpm audit --fix # Auto-fix when possible
Last Updated: 2025-10-26 pnpm Version: 10.19.0 Lockfile Version: 10.0 (will be regenerated from 9.0)