google-gemini/gemini-cli

Missing validation for critical configuration files could lead to broken bundles

Open

#16114 opened on Jan 8, 2026

View on GitHub
 (13 comments) (0 reactions) (1 assignee)TypeScript (103,992 stars) (13,657 forks)batch import
area/platformhelp wantedkind/bugpriority/p2status/bot-triagedtype/feature

Description

What happened?

The build and lint configuration files lack automated validation, creating risks:

Actual Behavior:

No tests verify that native modules (node-pty, keytar) are excluded from bundling

No validation of WASM resolution logic

No verification of ESLint security rule enforcement

No automated checks for license header compliance

What did you expect to happen?

Critical configuration files should have unit tests to prevent:

Broken CLI distribution from bundled native modules

Security rule violations slipping through

Compliance issues in production code

Impact:

High: CLI could fail on user machines if native modules are bundled

Medium: Security boundaries could be inadvertently removed

Medium: License violations could go undetected

Client information

Examine the test suite

Note absence of tests for esbuild.config.js and eslint.config.js

Modify either file incorrectly (e.g., remove node-pty from externals)

Observe that tests don't catch the regression

Proposed Solution

Add unit tests for these configuration files to validate:

  • WASM resolution handles both bare specifiers and local paths correctly
  • Native modules (node-pty, keytar) remain external to prevent bundling
  • ESLint security rules are properly configured and enforced
  • License header compliance is automatically validated

Acceptance Criteria

  • Tests exist for esbuild configuration validation
  • Tests exist for ESLint rule configuration
  • Native module externalization is verified
  • Security boundaries (node:os restrictions) are test-covered

Contributor guide

Tech stack
typescriptnodejs
Domain
build systemtestingtooling
Issue type
test
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
basic esbuild knowledgeESLint config experienceunit testing basics
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60
Research direction
The issue asks to add unit tests for esbuild.config.js and eslint.config.js. Start by examining the existing test suite to understand the testing framework and patterns. Then review the configuration files to understand the critical parts (native module externalization, WASM resolution, ESLint security rules, license headers). The acceptance criteria provide specific areas to cover. Comments on the issue may contain additional guidance or discussions about test approach.