Skip to main content

New Node Package Manager: pnpm

· 2 min read
Skpr Platform Team
Skpr Platform Team
Platform Engineering

Overview​

In light of the recent Shai-Hulud worm attack, we believe it’s important to offer our customers a more secure alternative to the npm package manager.

Why move away from npm?​

By design, npm executes arbitrary scripts across all dependencies—including transitive ones (the dependencies of your dependencies). This creates a risky environment where malicious code can execute unnoticed.

Enter pnpm​

First released in 2016, pnpm has matured into a battle-tested package manager trusted by teams of all sizes. It combines speed, efficiency, and strict dependency management, making it especially well-suited for organisations managing multiple projects and large monorepos.

Key benefits of pnpm include:

  • Fast – Up to 2x faster than other package managers (see benchmark).
  • Efficient – Uses content-addressable storage; all projects share a single source of truth.
  • Strict – Enforces dependency boundaries from package.json.
  • Deterministic – Ensures reproducible installs with pnpm-lock.yaml.
  • Flexible – Doubles as a Node.js version manager via pnpm env use.
  • Cross-platform – Runs seamlessly on Windows, Linux, and macOS.
  • Battle-tested – In production use since 2016.

(Adapted from the official project README.md)

Why this matters now​

For the context of this changelog, the most important feature is script execution control. Unlike npm, pnpm does not automatically run install scripts from dependencies. Instead, it notifies development teams, giving them the choice to explicitly allow or deny execution.

This default safeguard significantly reduces the attack surface for supply-chain exploits like the Shai-Hulud worm.

╭ Warning ─────────────────────────────────────────────────────────────────────╮
│                                                                              │
│   Ignored build scripts: @tailwindcss/oxide, esbuild.                        │
│   Run "pnpm approve-builds" to pick which dependencies should be allowed     │
│   to run scripts.                                                            │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

With this in mind, we strongly recommend development teams evaluate pnpm for their development workflows as a replacement for npm.

Available in all base images​

pnpm is now available in all our Node base images.

See here for the full list of images.

NPM Script Execution Disabled

· 2 min read
Skpr Platform Team
Skpr Platform Team
Platform Engineering

Overview​

We have disabled NPM scripts in our Skpr container base images as a security measure in response to the Shai-Hulud worm attack.

For more information on the attack see this blog post from Socket.

Changes Applied​

We have added the following environment variables to our Node images.

  • YARN_ENABLE_SCRIPTS=false
  • NPM_CONFIG_IGNORE_SCRIPTS=true

To ensure local development environments are not compromised, we also recommend teams add the following to their .npmrc file:

ignore-scripts=true

Checking Blocked Scripts​

You can identify which scripts are now blocked with:

npm query ":attr(scripts, [postinstall])" | jq 'map(.name)'

Example output:

[
  "esbuild" 👈️ Flagging a dependency that has a postinstall script
]

To see what a blocked script would have executed:

npm view esbuild scripts.postinstall

Example output:

node install.js

You can then manually run the script by pointing to the full path:

node ./node_modules/esbuild/install.js

Include these manual execution steps in your build process where required.

Further Recommendations​

We encourage teams to evaluate alternative Node package managers that have built-in ignore-scripts workflows. For example, pnpm blocks scripts by default and provides a subcommand for approving projects when needed.