build(deps): bump @slack/web-api to v8

[claude]

Requested by David Babenko-Sanders · Slack thread

Bumps @slack/web-api from ^6.10.0 (locked at 6.13.0) to ^8.2.0, which uses native fetch instead of axios, so axios and its transitive dependencies (agent-base, form-data, is-stream and friends) drop out of yarn.lock entirely. No code changes were needed: the WebClient is constructed with only a token and the code only calls chat.postMessage and users.profile.get, none of which are affected by the v7/v8 breaking changes; lint and tests pass, and both calls were smoke-tested against a local mock Slack API.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JNyjV4J2pgJaC2WfJpGfCb

---

Generated by Claude Code

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​slack/​web-api@​6.13.0 ⏵ 8.2.0	+1		+1	+1

View full report

[claude]

LGTM, straightforward dependency bump. Verified @ slack/web-api v6→v8 upgrade in package.json/yarn.lock: checked actual usage in action-audit.js and utils/helpers.js — WebClient is constructed with only a token and only chat.postMessage / users.profile.get are called, neither affected by the v7/v8 breaking changes. Confirmed the yarn.lock diff is internally consistent: axios/form-data/agent-base and related transitive deps are removed (v8 uses native fetch) while the new direct deps (@ slack/logger@^5, @ slack/types@^3, @ types/retry, retry, eventemitter3@^5) match @ slack/web-api@ 8.2.0's own package.json dependencies.

Extended reasoning...

Two-file diff (package.json, yarn.lock) bumping @ slack/web-api from ^6.10.0 to ^8.2.0 with no application code changes. Checked the only two Slack SDK call sites in the repo (action-audit.js, utils/helpers.js) against the v8 breaking-change surface and found no incompatibility. No security-sensitive surface is touched (no auth/crypto logic changed, just an HTTP client dependency swap from axios to native fetch). CODEOWNERS only has a generic fallback, no specific ownership concern, and the lockfile removals/additions are mechanically consistent with the new package's dependency tree.