ci: compile linked bigquery-storage in pnpm-lockfile-check

[ohmayr]

Context & Problem

The "Link In-Repo Workspace Packages" step that #9569 added to pnpm-lockfile-check links matching in-repo packages after the frozen install, then restores the committed lockfile, so turbo doesn't compile them. The step compiles gaxios and teeny-request itself. The Arrow PRs for @google-cloud/bigquery (#9596–#9605) add a devDependency on @google-cloud/bigquery-storage, which handwritten/bigquery-storage satisfies, so the step links it to source without a build/ directory and requiring it fails with MODULE_NOT_FOUND in every unit and Bun job.

Summary of Changes

• .github/actions/pnpm-lockfile-check/action.yaml: compile handwritten/bigquery-storage in the link step, alongside gaxios and teeny-request.

Verification

Ran the step's commands locally after pnpm install --frozen-lockfile --ignore-scripts:

• On feat(bigquery): add createQueryArrowStream for inline jobs.query results #9596 (a7565174ed): @google-cloud/bigquery unit tests go from 13 failing to 547 passing.
• On feat(bigquery): support maxResults in createQueryArrowStream #9605 (a256f90f24), the top of the stack: 576 passing.

[gemini-code-assist]

Code Review

This pull request replaces hardcoded package compilation in the lockfile check action with a dynamic script that resolves and compiles all in-repo linked workspace packages, including deep links. It introduces a Node.js helper script to list these directories by parsing workspace projects and scanning node_modules symlinks, accompanied by comprehensive unit tests. Review feedback recommends improving the robustness of the script by adding error handling and directory checks when reading the .pnpm store, and validating the JSON structure parsed from standard input to prevent runtime crashes.

[gemini-code-assist]

Using fs.existsSync alone does not guarantee that the path is a directory. If .pnpm exists but is a file or cannot be read, fs.readdirSync will throw an unhandled exception. Verifying that it is a directory using fs.statSync().isDirectory() and wrapping the operation in a try...catch block makes the file system operations more robust.

  let storeEntries = [];
  try {
    if (fs.statSync(store).isDirectory()) {
      storeEntries = fs.readdirSync(store);
    }
  } catch {
    // Ignore if .pnpm directory does not exist or cannot be read.
  }
  for (const name of storeEntries) {
    // `.pnpm/node_modules` hoists every package for pnpm's own resolution;
    // nothing in the repository loads from it.
    if (name !== 'node_modules') {
      nodeModulesDirs.push(path.join(store, name, 'node_modules'));
    }
  }

[gemini-code-assist]

When parsing JSON from external processes or APIs, it is important to validate that the input is not empty and that the parsed object has the expected structure (e.g., an array of objects with a path property) to prevent runtime crashes. This adheres to the general rule of validating JSON API responses before accessing their keys.

  process.stdin.on('end', () => {
    let projectDirs = [];
    try {
      if (input.trim()) {
        const parsed = JSON.parse(input);
        if (Array.isArray(parsed)) {
          projectDirs = parsed
            .filter(project => project && typeof project === 'object' && typeof project.path === 'string')
            .map(project => project.path);
        }
      }
    } catch (err) {
      console.error('Failed to parse workspace projects JSON:', err);
      process.exit(1);
    }
    for (const dir of linkedWorkspaceDirs(process.cwd(), projectDirs)) {
      console.log(dir);
    }
  });

References

1. When parsing and iterating over JSON API responses, validate that the root structure is of the expected type (e.g., a list) and that individual elements are mappings before accessing their keys to prevent runtime crashes on unexpected or error responses.