@vaultcompass/vault-guard-core 1.4.2 → 1.4.3

package/dist/scanners/pre-commit-hook.d.ts

@@ -7,8 +7,25 @@ export interface InstallHookOptions {
 export declare class PreCommitHook {
     /**
      * Resolve the directory where Git expects the \`pre-commit\` executable.
-     * Honors \`core.hooksPath\` (local then global). Relative paths are resolved
-     * against the **.git** directory, per Git documentation.
+     * Honors \`core.hooksPath\` (local then global).
+     *
+     * A RELATIVE \`core.hooksPath\` resolves against the WORKING-TREE ROOT,
+     * not against the .git directory. This resolved against the .git
+     * directory until a review caught it: husky 9 sets exactly this shape
+     * (core.hooksPath=.husky/_), so a repository using husky 9 had its hook
+     * written to a path git never reads, reported as installed, and never
+     * ran. Verified by driving a real commit rather than by re-reading the
+     * documentation that was misread the first time: with
+     * core.hooksPath=.husky/_ and an executable hook planted at BOTH
+     * .husky/_/pre-commit and .git/.husky/_/pre-commit, a commit runs the
+     * former. pre-commit-hook.test.ts pins it the same way.
+     *
+     * An ABSOLUTE \`core.hooksPath\` is used exactly as given, and no
+     * \`core.hooksPath\` at all still resolves against the git directory
+     * (never the working-tree root) -- both of those are unaffected by the
+     * bug above and must stay that way: a linked worktree or a submodule
+     * has its own git directory that is not its working-tree root, and that
+     * is precisely where an unset \`core.hooksPath\` needs to keep pointing.
      */
     getEffectiveHooksDir(cwd: string): {
         hooksDir: string;
@@ -47,4 +64,11 @@ export declare class PreCommitHook {
     private installPreCommitFramework;
     private uninstallPreCommitFramework;
     private resolveGitDir;
+    /**
+     * The working-tree root, or null when it cannot be determined. Asked of
+     * git rather than assumed to be \`cwd\`, so a relative \`core.hooksPath\`
+     * resolves correctly when \`install\`/\`getEffectiveHooksDir\` is called
+     * from a subdirectory of the repository.
+     */
+    private resolveWorktreeRoot;
 }

package/dist/scanners/pre-commit-hook.js

@@ -106,8 +106,25 @@ repos:
 class PreCommitHook {
     /**
      * Resolve the directory where Git expects the \`pre-commit\` executable.
-     * Honors \`core.hooksPath\` (local then global). Relative paths are resolved
-     * against the **.git** directory, per Git documentation.
+     * Honors \`core.hooksPath\` (local then global).
+     *
+     * A RELATIVE \`core.hooksPath\` resolves against the WORKING-TREE ROOT,
+     * not against the .git directory. This resolved against the .git
+     * directory until a review caught it: husky 9 sets exactly this shape
+     * (core.hooksPath=.husky/_), so a repository using husky 9 had its hook
+     * written to a path git never reads, reported as installed, and never
+     * ran. Verified by driving a real commit rather than by re-reading the
+     * documentation that was misread the first time: with
+     * core.hooksPath=.husky/_ and an executable hook planted at BOTH
+     * .husky/_/pre-commit and .git/.husky/_/pre-commit, a commit runs the
+     * former. pre-commit-hook.test.ts pins it the same way.
+     *
+     * An ABSOLUTE \`core.hooksPath\` is used exactly as given, and no
+     * \`core.hooksPath\` at all still resolves against the git directory
+     * (never the working-tree root) -- both of those are unaffected by the
+     * bug above and must stay that way: a linked worktree or a submodule
+     * has its own git directory that is not its working-tree root, and that
+     * is precisely where an unset \`core.hooksPath\` needs to keep pointing.
      */
     getEffectiveHooksDir(cwd) {
         const gitDirAbs = this.resolveGitDir(cwd);
@@ -128,10 +145,11 @@ class PreCommitHook {
         if (!hooksPath) {
             return { hooksDir: path_1.default.join(gitDirAbs, 'hooks'), viaHooksPath: false };
         }
-        const hooksDir = path_1.default.isAbsolute(hooksPath)
-            ? hooksPath
-            : path_1.default.join(gitDirAbs, hooksPath);
-        return { hooksDir, viaHooksPath: true };
+        if (path_1.default.isAbsolute(hooksPath)) {
+            return { hooksDir: hooksPath, viaHooksPath: true };
+        }
+        const worktreeRoot = this.resolveWorktreeRoot(cwd) ?? cwd;
+        return { hooksDir: path_1.default.join(worktreeRoot, hooksPath), viaHooksPath: true };
     }
     /**
      * Absolute path to the \`pre-commit\` hook file for the given manager.
@@ -480,5 +498,24 @@ class PreCommitHook {
             return null;
         }
     }
+    /**
+     * The working-tree root, or null when it cannot be determined. Asked of
+     * git rather than assumed to be \`cwd\`, so a relative \`core.hooksPath\`
+     * resolves correctly when \`install\`/\`getEffectiveHooksDir\` is called
+     * from a subdirectory of the repository.
+     */
+    resolveWorktreeRoot(cwd) {
+        try {
+            const rel = (0, child_process_1.execSync)('git rev-parse --show-toplevel', {
+                cwd,
+                encoding: 'utf-8',
+                stdio: ['ignore', 'pipe', 'pipe'],
+            }).trim();
+            return path_1.default.resolve(cwd, rel);
+        }
+        catch {
+            return null;
+        }
+    }
 }
 exports.PreCommitHook = PreCommitHook;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vaultcompass/vault-guard-core",
-  "version": "1.4.2",
+  "version": "1.4.3",
   "description": "Secret-scanning engine: vendor-anchored patterns, entropy gating, baselines, SARIF/JSON, hook helpers.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",