claude publish fix

Author: ecraig12345

packages/beachball/src/packageManager/packageManager.ts

@@ -4,6 +4,40 @@ import path from 'path';
 export type PackageManagerResult = execa.ExecaReturnValue & { success: boolean };
 export type PackageManagerOptions = execa.Options & { cwd: string };
 
+/**
+ * Filter PATH for running npm commands, removing entries that contain shell-script node wrappers.
+ * Package managers inject temp directories into PATH with node shims — yarn classic uses `yarn--*`
+ * dirs, yarn berry uses `xfs-*` dirs. These shims are POSIX shell scripts, and POSIX sh drops env
+ * vars whose names contain characters like / and :, which npm auth token env vars do contain.
+ * See: https://github.com/yarnpkg/yarn/issues/6685
+ *
+ * Workaround for an issue on certain platforms/shells(?) if the parent command was run VIA yarn:
+ * The auth environment variable (e.g. `npm_config_//someRegistry/:_authToken`) was not being
+ * passed through to the child process. This might be because:
+ * - Special characters such as / and : aren't valid in env var names for certain shells/platforms
+ * - On every `yarn run ...` command, yarn makes temp directories like /<temp>/yarn--1776822418161-0.7992675923334178
+ *   with aliases for `node` and `yarn`. On Linux (and Mac), the `node` alias looks something like:
+ *     #!/bin/sh
+ *     exec "/path/to/node" "$@"
+ *   (see https://github.com/yarnpkg/yarn/issues/6685 for context)
+ * - Best guess: invalid environment variable names are dropped by this extra `exec` step??
+ *   (This consistently reproed on Ubuntu+bash, but not Mac+zsh or bash. The clue was that the
+ *   tests passed even on Linux when run via debugTests.js, but failed when run via yarn test.)
+ *
+ * Removing yarn temp directories from the PATH seems to consistently fix this issue.
+ * yarn classic (v1) uses `yarn--*` directories; yarn berry (v4) uses `xfs-*` directories.
+ * Use `checkNpmAuthEnvPassthrough` after this filter to detect unknown variants of this issue.
+ */
+export function filterNpmPath(pathEnv: string): string {
+  return pathEnv
+    .split(path.delimiter)
+    .filter(p => {
+      const base = path.basename(p);
+      return !base.startsWith('yarn--') && !base.startsWith('xfs-');
+    })
+    .join(path.delimiter);
+}
+
 /**
  * Run a package manager command. Returns the error result instead of throwing on failure.
  * @param manager The package manager to use
@@ -18,28 +52,7 @@ export async function packageManager(
 ): Promise<PackageManagerResult> {
   let pathEnv = options.env?.PATH || process.env.PATH;
   if (manager === 'npm' && pathEnv) {
-    // Workaround for an issue on certain platforms/shells(?) if the parent command was run VIA yarn:
-    // The auth environment variable (e.g. `npm_config_//someRegistry/:_authToken`) was not being
-    // passed through to the child process. This might be because:
-    // - Special characters such as / and : aren't valid in env var names for certain shells/platforms
-    // - On every `yarn run ...` command, yarn makes temp directories like /<temp>/yarn--1776822418161-0.7992675923334178
-    //   with aliases for `node` and `yarn`. On Linux (and Mac), the `node` alias looks something like:
-    //     #!/bin/sh
-    //     exec "/path/to/node" "$@"
-    //   (see https://github.com/yarnpkg/yarn/issues/6685 for context)
-    // - Best guess: invalid environment variable names are dropped by this extra `exec` step??
-    //   (This consistently reproed on Ubuntu+bash, but not Mac+zsh or bash. The clue was that the
-    //   tests passed even on Linux when run via debugTests.js, but failed when run via yarn test.)
-    //
-    // Removing yarn temp directories from the PATH seems to consistently fix this issue.
-    // yarn classic (v1) uses `yarn--*` directories; yarn berry (v4) uses `xfs-*` directories.
-    pathEnv = pathEnv
-      .split(path.delimiter)
-      .filter(p => {
-        const base = path.basename(p);
-        return !base.startsWith('yarn--') && !base.startsWith('xfs-');
-      })
-      .join(path.delimiter);
+    pathEnv = filterNpmPath(pathEnv);
   }
 
   try {

packages/beachball/src/packageManager/packagePublish.ts

@@ -1,9 +1,32 @@
 import type { PackageInfo } from '../types/PackageInfo';
 import path from 'path';
+import execa from 'execa';
 import { npm, type NpmResult } from './npm';
 import type { BeachballOptions } from '../types/BeachballOptions';
 import { getNpmAuthEnv, getNpmPublishArgs } from './npmArgs';
 import type { NpmOptions } from '../types/NpmOptions';
+import { filterNpmPath } from './packageManager';
+
+/**
+ * Check whether env vars with special characters in their names (like npm auth token env vars,
+ * which contain // and :) will be passed through to npm subprocesses. Runs a test using the same
+ * PATH filtering applied to actual npm commands, so a failure here means the fix in
+ * `filterNpmPath` doesn't cover this platform/environment variant.
+ */
+async function checkNpmAuthEnvPassthrough(authEnvKey: string): Promise<boolean> {
+  const sentinel = 'beachball-auth-sentinel';
+  const filteredPath = process.env.PATH ? filterNpmPath(process.env.PATH) : undefined;
+  try {
+    const result = await execa(
+      'node',
+      ['-e', `process.stdout.write(process.env[${JSON.stringify(authEnvKey)}] || '')`],
+      { env: { [authEnvKey]: sentinel, ...(filteredPath && { PATH: filteredPath }) }, extendEnv: true }
+    );
+    return result.stdout === sentinel;
+  } catch {
+    return false;
+  }
+}
 
 /**
  * Attempt to publish the package with retries. Returns the result of the final npm publish call
@@ -24,6 +47,18 @@ export async function packagePublish(
   console.log(`  publish command: ${publishArgs.join(' ')}`);
   console.log(`  (cwd: ${packageRoot}${authEnv ? `, auth env var: ${Object.keys(authEnv)[0]}=****` : ''})\n`);
 
+  if (authEnv) {
+    const [authEnvKey] = Object.keys(authEnv);
+    if (!(await checkNpmAuthEnvPassthrough(authEnvKey))) {
+      console.error(
+        `Auth token env var "${authEnvKey}" is not being passed to npm subprocesses. ` +
+          `This is typically caused by a shell script node wrapper in your PATH (e.g. injected by a ` +
+          `package manager). Check that your PATH resolves "node" to a native binary, not a shell script.`
+      );
+      return { success: false } as NpmResult;
+    }
+  }
+
   let result: NpmResult;
 
   // Unclear whether `options.retries` should be interpreted as "X attempts" or "initial attempt + X retries"...