chore: update packages

[designcode]

Note

Low Risk
Low risk since it only affects local developer tooling, but it may change how reliably the commit-msg hook runs across environments by removing the Husky shell wrapper.

Overview
The commit-msg Husky hook is simplified to a single npx --no-install commitlint --edit "$1" command, removing the shebang and husky.sh bootstrap sourcing.

This changes hook execution behavior to rely on running commitlint directly rather than via Husky’s shell wrapper.

^{Written by Cursor Bugbot for commit 5b39daf. This will update automatically on new commits. Configure here.}

[greptile-apps]

Greptile Summary

This PR performs routine dependency upgrades across the monorepo, including bumping husky from v8 to v9, commitlint from v18 to v20, TypeScript from v5.0 to v5.9, AWS SDK packages, and internal @tigrisdata/storage cross-package references. It also migrates the .husky/commit-msg hook to the v9 format and adds chore commits as patch release triggers in the shared semantic-release config.

Key issues found:

• package.json prepare script is broken for husky v9: The script still calls husky install, which was removed in husky v9 (the correct command is now just husky). This will cause npm install to fail on any fresh checkout.
• release.config.base.cjs missing catch-all for chore negation: Adding { scope, type: 'chore', release: 'patch' } is not paired with the corresponding { scope: \!(${scope})`, type: 'chore', release: false }exclusion rule. The existing rules coverfeat, fix, perf, and refactorwith negation catch-alls, butchoreis left unguarded, potentially allowingchore` commits from other package scopes to trigger unintended patch releases.

Confidence Score: 2/5

• Not safe to merge as-is — the prepare script will break npm install on fresh checkouts due to the husky v8→v9 migration being incomplete.
• The husky v9 upgrade correctly updates .husky/commit-msg, but leaves "prepare": "husky install" in package.json which is an invalid command in v9. This is a functional regression that will immediately break CI and developer onboarding. The release config change also has a gap in catch-all rules. Both issues should be fixed before merging.
• package.json (broken prepare script) and release.config.base.cjs (missing chore negation catch-all rule).

Important Files Changed

Filename	Overview
package.json	Dev dependency upgrades (husky v8→v9, commitlint v18→v20, TypeScript v5.0→v5.9, etc.) but the prepare script still calls husky install which is not valid in husky v9 — this will break npm install on fresh checkouts.
.husky/commit-msg	Correctly migrated to husky v9 format by removing the v8 shell boilerplate (#!/usr/bin/env sh and the husky.sh source line).
release.config.base.cjs	Added chore as a patch release trigger, but is missing the corresponding negation catch-all rule { scope: !(scope), type: 'chore', release: false } that would prevent chore commits from other packages from potentially triggering unintended releases.
packages/storage/package.json	Routine patch bumps for AWS SDK dependencies (@aws-sdk/client-s3, @aws-sdk/lib-storage, @aws-sdk/s3-request-presigner) from ^3.994.0 to ^3.1006.0 and @smithy/signature-v4 from ^5.3.8 to ^5.3.11.
packages/keyv-tigris/package.json	Bumped internal @tigrisdata/storage peer dependency from ^2.13.0 to ^2.15.3.
packages/react/package.json	Bumped internal @tigrisdata/storage dependency from ^2.13.0 to ^2.15.3.
package-lock.json	Auto-generated lockfile regenerated to reflect all dependency version bumps; no manual changes expected.

Comments Outside Diff (2)

1. package.json, line 29 (link)

   husky install incompatible with husky v9

   The prepare script still calls husky install, which was removed in husky v9. Husky v9 changed the initialization command from husky install to just husky. Running npm install on a fresh checkout will fail during the prepare lifecycle hook.

2. release.config.base.cjs, line 22-30 (link)

   Missing catch-all rule for chore commits from other scopes

   A { scope, type: 'chore', release: 'patch' } rule was added so that scoped chore commits trigger a patch release. However, there is no corresponding negation rule to prevent chore commits from other scopes falling through to semantic-release's default resolution. The existing catch-all rules cover feat, fix, perf, and refactor, but not chore. If a chore(react) commit is analyzed in the context of the storage package, the absence of a catch-all could allow it to trigger an unintended release depending on the default @semantic-release/commit-analyzer preset.

   Consider adding a matching exclusion rule alongside the others:

_{Last reviewed commit: ccd4f71}

[github-actions]

🎉 This PR is included in version 2.15.4 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 1.3.1 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 1.1.2 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 1.2.2 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀