fix: move hashing function to PlatformTools - #12648

Description

src/util/StringUtils.ts now imports PlatformTools at module load, so any consumer importing
common helpers (e.g., camelCase, shorten) will also load PlatformTools and its top-level
dependencies (@sqltools/formatter, sql-highlight, crypto, etc.) in Node. This increases
startup/module-load overhead and couples lightweight string helpers to Node-only tooling.

Code

src/util/StringUtils.ts[1]

+import { PlatformTools } from "../platform/PlatformTools"

Evidence

StringUtils now depends on PlatformTools at import time, and PlatformTools has several heavy
top-level imports. Core modules like DefaultNamingStrategy and DriverUtils import StringUtils,
so this dependency expansion affects common Node code paths.

src/util/StringUtils.ts[1-1]
src/util/StringUtils.ts[115-123]
src/platform/PlatformTools.ts[1-8]
src/naming-strategy/DefaultNamingStrategy.ts[1-3]
src/driver/DriverUtils.ts[1-4]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`StringUtils` has a new top-level import of `PlatformTools`, which forces loading `PlatformTools` (and its heavy imports) even when callers only use non-hash string helpers.

## Issue Context
The PR’s goal is to avoid Metro failing on `node:crypto`; that can still be achieved without a module-level dependency from `StringUtils` to `PlatformTools`.

## Fix Focus Areas
- src/util/StringUtils.ts[1-1]
- src/util/StringUtils.ts[115-123]

Suggested approach: remove the top-level `import { PlatformTools } ...` and require/import `PlatformTools` *inside* `hash()` (or extract SHA-1 into a tiny module with browser mapping), so non-hash users don’t pay the `PlatformTools` load cost.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR removes PlatformTools.readPackageVersion and StringUtils.abbreviate, which will break
downstream code that imports them (including via deep-import paths that the package export patterns
allow). The PR title/description only describes hashing changes, so this compatibility break is
likely unintended.

Code

src/platform/PlatformTools.ts[L29-43]

-    /**
-     * Reads the version string from package.json of the given package.
-     * This operation is only supported in node.
-     *
-     * @param name
-     */
-    static readPackageVersion(name: string): string {
-        try {
-            return require(`${name}/package.json`).version
-        } catch (err) {
-            throw new TypeError(
-                `Failed to read package.json for "${name}": ${err.message}`,
-                { cause: err },
-            )
+        if (typeof globalThis !== "undefined") {
+            return globalThis
        }
+        return global

Evidence

The current PlatformTools and StringUtils files no longer contain these exports, and
package.json export patterns indicate consumers can deep-import internal modules where these
helpers previously lived.

src/platform/PlatformTools.ts[17-40]
src/util/StringUtils.ts[43-55]
package.json[19-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Two previously exported helpers were removed (`PlatformTools.readPackageVersion`, `StringUtils.abbreviate`). If any downstream code imports these, it will fail to compile or run.

## Issue Context
`package.json` exports includes a wildcard pattern, so deep imports are possible; even if these helpers are “internal”, they can be in real-world use.

## Fix Focus Areas
- src/platform/PlatformTools.ts[23-43]
- src/util/StringUtils.ts[47-66]
- package.json[19-45]

Suggested approach: re-add these functions (optionally marked deprecated) or provide a backwards-compatible shim that forwards/throws with a clear message, and document the change if removal is intentional.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools