Commit a lockfile to protect against supply chain attacks

[amotarao]

Package

repository root

Description

This repository does not commit a lockfile. The recent axios supply chain compromise (axios/axios#10604) highlighted a concrete risk: contributors running npm install to set up their local environment may have inadvertently installed a malicious version of a dependency, since web-api depends on axios: "^1.13.5" which includes the compromised 1.14.1.

Committing a package-lock.json would pin all transitive dependencies to known-good versions, making this kind of attack much harder to go undetected.

Alternatives Considered

No response

[vegeris]

Hi there,

Thank you for the suggestion! We're not planning on committing a lockfile as this project is intended to be a dependency of other projects. We may pin axios to a specific version however, and will be re-evaluating our dependency-update cadence!

[zimeg]

👋 This package-lock.json file would for development and something we can avoid publishing with packages?

I understand that can be an addition alongside changes of the update cadence 🎁 I'm curious in revisiting this and will add a security label too. I understand the axios compromise to be severe.

[zimeg]

🐣 Re: The cadence of updates - I'm not sure this would guard against bad packages from being installed with an unpinned version:

node-slack-sdk/packages/web-api/package.json

Line 56 in 700a636

"axios": "^1.13.5",

And I'd hesitate use a pinned version here since this can make package resolution difficult in application code. New patches would require us to make an immediate release to remain compatible with other packages on the latest. 🔏

[zimeg]

🔬 FWIW I take a lot of inspiration from the withastro packages that use a similar package setup and a root lockfile but not specific package ones:

• 🔑 https://github.com/withastro/astro/blob/main/pnpm-lock.yaml
• 👾 https://github.com/withastro/astro/tree/main/packages/astro

[amotarao]

Thanks for the discussion! I'd like to clarify a few points.

package-lock.json is ignored when consumers install this package as a dependency. npm only respects the lockfile of the root project, not of packages installed as dependencies. So there's no need to worry about explicitly ignoring it at publish time.

I also want to clarify the scope of this proposal. The concern here is specifically about the security risk for contributors setting up their local development environment — i.e., someone running npm install to start working on node-slack-sdk itself could have inadvertently installed a compromised version of a transitive dependency. Committing a lockfile does not affect the security of end users who install node-slack-sdk as a dependency — those are two separate concerns.

For the end-user side of things, pinning the axios version range in package.json would be the right approach. As seen in #1525, many users have raised concerns about axios, so that's worth addressing independently.

Beyond security, there's another benefit worth mentioning: committing a lockfile ensures that all contributors are working with the exact same dependency versions, which helps avoid subtle environment-specific issues during development.

Finally, since this repository uses npm workspaces, the approach mentioned by @zimeg — keeping a single lockfile at the root (like withastro does) — would work well here and seems like a reasonable path forward.

[amotarao]

@vegeris I just posted a follow-up on why this shouldn't be closed yet. Would love to get your feedback on it.