test: add validation tests for esbuild and eslint config files

[mrpmohiburrahman]

Summary

Add unit tests for esbuild.config.js and eslint.config.js to catch
regressions in critical build and lint configurations that could lead to
broken CLI bundles or security rule violations.

Details

The build and lint configuration files had no automated validation. This PR
introduces two test suites:

esbuild.config.test.ts validates:

• Native modules (node-pty, keytar) remain excluded from bundling
  (these contain platform-specific compiled code that would crash if bundled)
• WASM plugin resolution handles both package imports (e.g., tiktoken)
  and relative file paths (e.g., ./local.wasm) correctly
• Base config targets Node/ESM with correct settings
• CLI and A2A server build configs inherit shared settings (platform,
  format, externals) to stay consistent

eslint-config.test.ts validates:

• node:os restrictions are enforced (e.g., homedir, tmpdir must use
  core helpers, not node:os directly, to keep sandboxing intact)
• Exceptions to the above restrictions are correctly scoped to test files
  and paths.ts, which legitimately need direct node:os access
• License header compliance is configured (every source file must include
  the Apache-2.0 header)
• Self-import prevention rules exist for all workspace packages (e.g.,
  @google/gemini-cli-core cannot import from itself, which would cause
  circular dependency issues)
• The import/enforce-node-protocol-usage rule is active (requires using
  node:fs instead of fs for built-in modules)
• Production-only safety rules (no-debugger, no-console) are enabled

To make the esbuild config testable, shared logic was extracted into
esbuild.helpers.js.

Note

The current test suite covers the most critical ESLint rules (security
restrictions, license headers, self-import prevention, node protocol
enforcement, and production-only safety rules). Additional rules from
eslint.config.js (e.g., TypeScript-specific overrides, import
restrictions between packages) can be added in follow-up PRs if desired.
Feedback on which rules to prioritize is welcome.

Related Issues

Fixes #16114

How to Validate

1. Run the esbuild config tests:

   npx vitest run scripts/tests/esbuild.config.test.ts

2. Run the eslint config tests:

   npx vitest run scripts/tests/eslint-config.test.ts

3. Verify all tests pass with no failures.
4. Optionally, break a config (e.g., remove node-pty from externals in
   esbuild.helpers.js) and confirm the tests catch the regression.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello @mrpmohiburrahman, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the project's reliability by introducing automated validation for its critical build and linting configurations. By adding dedicated unit tests for both esbuild and ESLint setups, it ensures that future changes or updates to these configurations do not inadvertently introduce regressions that could lead to broken CLI bundles, security vulnerabilities, or non-compliant code. The refactoring of the esbuild configuration was a necessary step to enable this testing, improving the overall structure and testability of the build process.

Highlights

• New Unit Tests for esbuild Configuration: Added a dedicated test suite (esbuild.config.test.ts) to validate critical aspects of the esbuild configuration, ensuring native modules (like node-pty, keytar) remain external, WASM plugin resolution works correctly for both package and relative paths, and base configurations are consistently applied to CLI and A2A server builds.
• New Unit Tests for ESLint Configuration: Introduced a comprehensive test suite (eslint-config.test.ts) to verify key ESLint rules, including node:os import restrictions (with appropriate exceptions for test files and specific helpers), Apache-2.0 license header enforcement, prevention of self-imports within workspace packages, mandatory node: protocol usage for built-in modules, and activation of production-only safety rules like no-debugger and no-console.
• esbuild Configuration Refactoring: Refactored the main esbuild.config.js file by extracting shared logic and configuration functions into a new esbuild.helpers.js file. This change modularizes the build configuration, making it more maintainable and enabling effective unit testing.

Changelog

• esbuild.config.js
  • Refactored to import and utilize helper functions for creating CLI and A2A server configurations.
  • Removed inline definitions for createWasmPlugins, external, baseConfig, commonAliases, cliConfig, and a2aServerConfig.
• esbuild.helpers.js
  • Added new file to centralize esbuild configuration logic.
  • Exported external modules list, baseConfig object, and commonAliases object.
  • Exported createWasmPlugins function for WASM plugin setup.
  • Exported createCliConfig and createA2aServerConfig functions to generate specific build configurations.
• scripts/tests/esbuild.config.test.ts
  • Added new file containing unit tests for the esbuild configuration.
  • Included tests for external module exclusions (e.g., node-pty, keytar).
  • Verified base configuration properties like platform, format, bundling, and loader settings.
  • Validated common aliases and their correct application.
  • Tested CLI and A2A server build configurations for entry points, output files, version definitions, banner content, and WASM plugin usage.
  • Ensured correct WASM plugin resolution for bare specifiers, relative paths, and absolute paths.
• scripts/tests/eslint-config.test.ts
  • Added new file containing unit tests for the ESLint configuration.
  • Verified no-restricted-imports rules for node:os to block homedir and tmpdir.
  • Confirmed exceptions for no-restricted-imports in test files, paths.ts, and scripts.
  • Validated headers/header-format rule for Apache-2.0 license enforcement and year patterns.
  • Ensured self-import prevention rules are active for workspace packages (@google/gemini-cli-core, @google/gemini-cli, @google/gemini-cli-sdk).
  • Checked import/enforce-node-protocol-usage rule to require node: prefix.
  • Confirmed production-only safety rules like no-unsafe-type-assertion and no-unsafe-assignment are enforced.
  • Verified the overall structure of the ESLint configuration and global ignores for build artifacts.

Activity

• The pull request was created to add validation tests for esbuild and eslint configuration files.
• The author refactored esbuild.config.js into esbuild.helpers.js to facilitate testing.
• New test files scripts/tests/esbuild.config.test.ts and scripts/tests/eslint-config.test.ts were added.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request introduces unit tests for esbuild.config.js and eslint.config.js, which is a significant improvement for maintaining the quality and stability of the project's build and linting configurations. The changes involve refactoring the esbuild configuration into a helper file (esbuild.helpers.js) to facilitate testing, and then adding comprehensive test suites for both esbuild and eslint configurations. This ensures critical aspects like native module exclusion, WASM plugin resolution, node:os import restrictions, license header enforcement, and self-import prevention are validated automatically. The new tests cover important security and build integrity aspects, which is a high-value addition to the codebase. Feedback includes a necessary copyright year update and a critical issue regarding asynchronous operations in an esbuild banner that could lead to build failures.

[mrpmohiburrahman]

Let me know what I should do, so that this pr get accepted.

[nidhishgajjar]

Orb Code Review (powered by GLM-4.7 on Orb Cloud)

Summary

This PR adds unit tests for esbuild.config.js and eslint.config.js to prevent regressions in critical build and lint configurations. However, like PR #20261, it bundles this focused improvement with massive cleanup: 1,867 files changed with over 1 million deletions, removing entire subsystems (ACP, gemma, performance tests, skills, etc.).

Architecture

Stated Goal (test file additions):

scripts/tests/esbuild.config.test.ts validates:

• Native modules (node-pty, keytar) remain excluded from bundling
• Base configuration uses ESM format and correct target platform
• CLI and A2A server build configurations are correctly structured
• Common aliases (punycode) are correctly set
• WASM plugins are included
• CJS compatibility shims are present

scripts/tests/eslint-config.test.ts validates:

• ESLint configuration structure
• Security rules are properly enabled
• Parser options are correct
• Plugin configuration is valid

These are excellent additions - build and lint configurations had no automated validation before, which is a significant gap in test coverage.

Bundled Cleanup (massive scope, unstated in PR description):

The PR also removes the same subsystems as PR #20261:

• ACP (Agent Control Panel): Entire command system removed
• Gemma commands: Setup, logs, platform detection removed
• Performance tests: Complete test suite removed
• Skills: Multiple skills removed (async-pr-review, behavioral-evals, string-reviewer, etc.)
• GitHub workflows: Workflows for evals, docs-audit, memory-nightly, perf-nightly removed
• Build scripts: Multiple build and utility scripts removed
• CLI startup: Simplified startup pattern removed (same as PR fix: Add isRespondingRef for synchronous blocking and await the retry  #20261)

Issues

PR scope — critical — Mismatch between description and actual changes

The PR description states:

"Add unit tests for esbuild.config.js and eslint.config.js to catch regressions in critical build and lint configurations that could lead to broken CLI bundles or security rule violations."

However, the PR includes:

• 2 new test files (~750 lines) - the stated goal
• 1,865 other file changes - massive, unrelated cleanup (1M+ deletions)

Impact:

• Reviewers cannot validate that only config tests are being added
• The massive cleanup is not documented in the PR description
• Merge risk is much higher than the stated goal suggests
• Rollback is difficult if cleanup introduces issues

Recommendation: Split into two separate PRs:

1. PR docs: Add setup instructions for API key to README #1 (config tests only): Focus on the stated goal

   • Add scripts/tests/esbuild.config.test.ts
   • Add scripts/tests/eslint-config.test.ts
   • Any minimal changes needed to support these tests
   • This should merge quickly as a focused improvement

2. PR Improve readability issues #2 (cleanup): Feature removal and subsystem cleanup

   • Remove ACP commands
   • Remove gemma commands
   • Remove performance tests
   • Remove unused skills
   • Simplify CLI startup
   • Each subsystem removal should ideally be its own PR

scripts/tests/esbuild.config.test.ts — good — Comprehensive test coverage

The esbuild configuration tests are well-structured and comprehensive:

it('excludes node-pty to prevent bundling native addons', () => {
  expect(external).toContain('node-pty');
  expect(external).toContain('@lydell/node-pty');
});

This correctly validates that native modules are excluded from bundling, which is critical for preventing broken bundles.

it('targets node platform', () => {
  expect(baseConfig.platform).toBe('node');
});

Validates the correct build target, preventing platform-specific issues.

it('includes CJS compatibility shim in banner', () => {
  expect(cliConfig).toHaveProperty(
    ['banner', 'js'],
    `import { createRequire } from 'module'; ...`,
  );
});

Ensures CJS compatibility shims are present, which is essential for backward compatibility.

scripts/tests/eslint-config.test.ts — good — Validates security-critical config

While I couldn't see the full content (similar to the esbuild test), adding tests for ESLint configuration is critical because:

1. Security rules: ESLint rules catch potential security vulnerabilities
2. Code quality: Lint configuration affects all code in the repository
3. Regression prevention: Changes to ESLint config can inadvertently disable important rules

Note: This review assumes the ESLint test follows similar patterns to the esbuild test (validating critical properties, plugins, rules, etc.).

Cleanup scope — critical — Same issues as PR #20261

The cleanup bundled with this PR is nearly identical to PR #20261 and has the same issues:

1. No backward compatibility assessment:

   • Users relying on ACP commands will break
   • Users with local gemma setups will break
   • Developers using perf-tests will lose regression testing capability
   • No migration guide for affected users

2. No deprecation notice:

   • Features are removed without deprecation period
   • Breaking changes in a non-major version bump (likely a patch or minor version)

3. CLI startup simplification:

   • Removes auto memory configuration (same issue as PR fix: Add isRespondingRef for synchronous blocking and await the retry  #20261)
   • May cause OOM errors on systems with limited memory

4. Documentation gap:

   • No changelog entry documenting removed features
   • No explanation of why features were removed

Testing — minor — Tests for cleanup changes

If the cleanup is intentional, the PR should include:

1. Tests verifying removed features are no longer accessible:

it('should not expose ACP commands', () => {
  expect(commandRegistry.getCommand('acp')).toBeUndefined();
});

2. Migration tests: Verify that users can still accomplish the same goals through alternative means

3. Backward compatibility tests: If any APIs are changed, verify they work correctly

Duplicate work — warning — Overlaps with PR #20261

PRs #19866 (this one) and #20261 include nearly identical cleanup:

• Both remove ACP commands
• Both remove gemma commands
• Both remove performance tests
• Both simplify CLI startup
• Both remove the same skills

Questions:

1. Is this intentional (two PRs for the same cleanup)?
2. Or is there merge conflict/branch management issue?
3. Should these be consolidated into a single, well-documented cleanup PR?

PR timing — warning — Older PR not yet merged

PR #19866 was created on 2026-02-22, while PR #20261 was created on 2026-02-25. Both include nearly identical cleanup.

If #19866 is meant to be the primary cleanup PR, #20261 may have unnecessary duplication. If #20261 is the intended cleanup, #19866 may need to be rebased or closed.

Cross-file Impact

• Build reliability: Adding tests for esbuild config significantly improves reliability by catching configuration regressions early
• Code quality: ESLint config tests prevent accidental disabling of important lint rules
• Breaking changes: ACP, gemma, and perf test removals will affect users (same as PR fix: Add isRespondingRef for synchronous blocking and await the retry  #20261)
• Developer experience: Removed workflows and skills will affect contributors who depend on them

Assessment

⚠️ Request changes

The core stated goal (adding config validation tests) is excellent and addresses a significant gap in test coverage. The tests are well-structured and will prevent regressions in critical build and lint configurations.

However, like PR #20261, the PR is severely scoped incorrectly by bundling this focused improvement with massive, unrelated cleanup (1,867 files changed, 1M+ deletions).

Required changes:

1. Split the PR into two separate PRs:

   • PR docs: Add setup instructions for API key to README #1: Config tests only (esbuild.config.test.ts, eslint-config.test.ts)
   • PR Improve readability issues #2: Feature cleanup (ACP, gemma, perf tests, startup simplification)

2. Resolve duplication with PR fix: Add isRespondingRef for synchronous blocking and await the retry  #20261:

   • Determine which PR is the intended cleanup PR
   • Consolidate or close the duplicate
   • Ensure clean git history without merge conflicts

3. Add documentation for the cleanup:

   • Changelog entry documenting removed features
   • Migration guide for affected users
   • Explanation of why features were removed

4. Add tests for cleanup changes to verify:

   • Removed features are no longer accessible
   • Alternative workflows work correctly
   • No regression in core functionality

Once split into appropriate PRs:

• The config tests PR (docs: Add setup instructions for API key to README #1) should be approved quickly - it's a focused, valuable improvement
• The cleanup PR (Improve readability issues #2) should be reviewed more thoroughly, potentially split further by subsystem

This approach allows for:

• Faster iteration on config test improvements
• Safer rollout of cleanup changes
• Better review coverage for each change
• Easier rollback if issues arise

Note to maintainers: Given the nearly identical cleanup in PRs #19866 and #20261, please clarify which PR is the intended one and resolve the duplication before merging.

[DavidAPierce]

The PR is solid and only needs minor edits. However, the PR cannot be merged until the branch is correctly synchronized with main to remove the unintentional deletions of unrelated subsystems.

Recommended Improvement: Consistency in esbuild Banners

• Observation: In esbuild.helpers.js, the createCliConfig uses a standard import for its banner, while createA2aServerConfig uses an await import.
  • CLI Banner: import { createRequire } from 'module'; ...
  • A2A Banner: const require = (await import('module')).createRequire(import.meta.url); ...
• Impact: The await import introduces an unnecessary asynchronous operation at the top level of the bundle. While functional in ESM, it is less idiomatic than the
  static import used in the CLI config.
• Recommendation: Use the static import banner in both createCliConfig and createA2aServerConfig for consistency and to follow the bot's suggestion of avoiding async
  operations in the banner.

Next Steps:

1. Fix the branch sync/scope issue (rebase or restore missing files. Most likely things will go smoothly after a quick resolution to the merge conflict in esbuild.config.js).
2. Unify the esbuild banners to use static import.
3. Once the file diff is limited to the 4 relevant files, this PR will be good for final review and approval.