Bump tar from 7.5.19 to 7.5.22 in /bwell-react-native

[dependabot]

Bumps tar from 7.5.19 to 7.5.22.

Commits

• 2a22bfc 7.5.22
• df1cd8d Allow transform to be falsey
• 0cd9cc3 7.5.21
• 631ae59 list: prevent unbounded recursion
• ebbb720 7.5.20
• 2f27196 fix: fully disable and dispose of unzip when aborting parser
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[claude]

Approving — this is a routine Dependabot patch bump (tar 7.5.19 → 7.5.22) touching only the lockfile. The one inline finding is a minor nit (lockfile resolved URL points to the public npm registry instead of the internal Artifactory mirror) — the integrity hash is still verified so there's no tamper risk, and it doesn't block this mechanical bump.

Extended reasoning...

Overview

Single-file change: bwell-react-native/package-lock.json bumps the tar dependency from 7.5.19 to 7.5.22 via Dependabot. No application code, config, or other dependencies are touched.

Security risks

None from the version bump itself — it's a patch release fixing upstream bugs (transform handling, recursion limit in list, abort/dispose behavior in the unzip path). The one inline nit (resolved URL pointing at registry.npmjs.org instead of the internal Artifactory mirror used by all other 1027 entries) does not introduce a tampering risk since the SHA-512 integrity hash in the lockfile is still enforced by npm on install; the practical risk is an install failure in network-restricted CI, not a supply-chain issue.

Level of scrutiny

Low. This is a mechanical, single-file, Dependabot-generated lockfile bump with no logic changes — exactly the kind of change that doesn't need human review beyond the flagged nit.

Other factors

The lockfile-registry nit is worth fixing before merge (regenerate through the Artifactory-configured npm registry) but is not a correctness or security blocker for the version bump itself, so I'm approving with the nit left as an inline comment for the author to address.

[claude]

🟡 The bumped tar@7.5.22 entry resolves from https://registry.npmjs.org instead of the internal Artifactory mirror (artifacts.bwell.com) used by all 1027 other packages in this lockfile, including the previous tar@7.5.19 entry. This bypasses the internal proxy's caching/vetting and could fail installs in network-restricted CI environments; regenerate this lockfile entry through the Artifactory-configured registry before merging.

Extended reasoning...

Every package in bwell-react-native/package-lock.json resolves through the internal Artifactory proxy at https://artifacts.bwell.com/artifactory/api/npm/virtual-npm/... — that's true for all 1027 other entries in the file, including the previous tar@7.5.19 entry and even tar's own nested yallist sub-dependency (node_modules/tar/node_modules/yallist, line 12745). This PR's Dependabot-generated bump to tar@7.5.22 is the single exception: its resolved field points directly at https://registry.npmjs.org/tar/-/tar-7.5.22.tgz.

Code path: npm ci/npm install uses the resolved URL in the lockfile verbatim to fetch the tarball — it does not re-resolve through .npmrc registry config for packages that already have a resolved field pinned in the lockfile. So an install using this exact lockfile will reach out to the public npm registry for tar, regardless of what the project's .npmrc says about routing through Artifactory.

Why nothing else catches this: Dependabot generates its lockfile diff by resolving the new version against the public npm registry rather than the project's configured Artifactory proxy, and there's no lockfile-level lint/CI check in this repo enforcing that all resolved URLs match the internal mirror pattern — so a partial regeneration like this slips through untouched.

Impact: In a network-restricted CI/build environment that only allows egress to artifacts.bwell.com (which is presumably the entire point of routing dependencies through Artifactory), npm ci would fail outright trying to fetch tar from registry.npmjs.org. In an environment where the public registry is reachable, the install still succeeds and the SHA-512 integrity hash still protects against tampering — but the internal proxy's caching, vetting, or supply-chain scanning for this one package is silently bypassed, breaking the repo's otherwise-uniform policy.

Proof: grep -c 'artifacts.bwell.com/artifactory' package-lock.json returns 1027, while grep -c 'registry.npmjs.org' package-lock.json returns exactly 1 — the tar@7.5.22 entry at line 12729. Diffing against the previous version confirms tar@7.5.19 resolved from https://artifacts.bwell.com/artifactory/api/npm/virtual-npm/tar/-/tar-7.5.19.tgz, so this PR is what introduces the sole outlier.

Fix: Regenerate this lockfile entry by running the dependency bump through the Artifactory-configured .npmrc (e.g. npm install tar@7.5.22 with the internal registry active, or have Dependabot re-run against the internal proxy) so the resolved URL matches the pattern used by every other dependency in the file.