Surface esp32 framework.advanced.flash_chip on the framework form

[bdraco]

What does this implement/fix?

esphome 2026.10.0 adds framework.advanced.flash_chip on esp32. Upstream marks the whole advanced group yaml only, so the sync hides every child unless it is on the curated _ESP32_ADVANCED_VISIBLE list; without this change the field would land hidden on the next catalog sync and a YAML that sets flash_chip: generic shows nothing in the framework form.

This adds flash_chip to the allowlist with generic as the probe value. generic validates on every variant, so the derived variant gate is None and the select shows on all variants; esphome keeps owning the mxic_opi and flash_mode: opi pairing. The field only appears once the catalog syncs against a 2026.10.0 schema (the latest published schema is still 2026.9.0, so the committed catalog is unchanged here). Verified against esphome dev in a scratch venv: the visibility tests pass unguarded and the gate derives to None. No browser check was possible yet, the served catalog predates the field.

Related issue or feature (if applicable):

• N/A

Types of changes

• Bugfix (non-breaking change which fixes an issue) — bugfix
• New feature (non-breaking change which adds functionality) — new-feature
• Enhancement to an existing feature — enhancement
• Breaking change (fix or feature that would cause existing functionality to not work as expected) — breaking-change
• Refactor (no behaviour change) — refactor
• Documentation only — docs
• Maintenance / chore — maintenance
• CI / workflow change — ci
• Dependencies bump — dependencies

Frontend coordination

• No frontend change needed
• Companion frontend PR: esphome/device-builder-frontend#

Checklist

• The code change is tested and works locally.
• Pre-commit hooks pass (ruff, codespell, yaml/json/python checks).
• Tests have been added or updated under tests/ where applicable.
• components.index.json / definitions/components/*.json have not been hand-edited (regenerate via script/sync_components.py if a sync is needed).
• Architecture-level changes are reflected in docs/ARCHITECTURE.md and/or docs/API.md.

[bdraco]

@esphbot review

[codspeed]

Merging this PR will not alter performance

✅ 28 untouched benchmarks
⏩ 1 skipped benchmark¹

---

_{Comparing surface-esp32-flash-chip (de794fb) with main (12aacbb)}

Footnotes

1. 1 benchmark was skipped, so the baseline result was used instead. If it was deleted from the codebase, click here and archive it to remove it from the performance reports. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.75%. Comparing base (12aacbb) to head (de794fb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2870   +/-   ##
=======================================
  Coverage   99.75%   99.75%           
=======================================
  Files         296      296           
  Lines       25677    25677           
=======================================
  Hits        25615    25615           
  Misses         62       62           

Flag	Coverage Δ
py3.12	99.72% <ø> (ø)
py3.14	99.60% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[esphbot]

PR Review — Surface esp32 framework.advanced.flash_chip on the framework form

Small, correct allowlist addition with version-aware tests. Ready to merge.

What works well:

• The new entry reuses the existing _surface_esp32_advanced_fields / _esp32_variant_gate path. generic goes in as the probe value, and the gate derives to None without any hand-kept variant list.
• The tests are split two ways:
  • Installed esphome: _INSTALLED_HAS_FLASH_CHIP skips the unit tests on older installs.
  • Committed catalog: _CATALOG_HAS_FLASH_CHIP asserts the field is present or absent based on the catalog's esphome_schema_version.
• So CI passes against today's 2026.9.0 catalog, and the tests will enforce the field once a 2026.10 sync lands.
• The sync can't mismatch versions: assert_installed_esphome(version, ...) in sync_components.py makes sure the gate is derived from the same esphome that produced the schema bundle.

Non-blocking:

• Only generic is probed, so non-generic options (e.g. mxic_opi) appear on every variant. The PR says esphome deliberately owns that pairing.

---

---

Checklist

• No hardcoded secrets
• Tests cover new behavior (unit + catalog, version-guarded)
• Catalog JSON not hand-edited
• Variant gating matches field validity

---

Automated review by Kōan (Claude) HEAD=de794fb 1 min 9s

[esphbot]

Tip

No blocking issues found — ready to merge.

[Copilot]

Copilot review overview

🟢 Approval recommended

The focused catalog change is correct, backward-compatible, and adequately tested.

Review effort: Balanced
Findings: None

What changed in this PR

Surfaces ESP32 framework.advanced.flash_chip in the generated framework form once supported by ESPHome.

Changes:

• Adds flash_chip to the curated ESP32 advanced-field allowlist.
• Adds version-aware visibility, option, and variant-gating tests.

File	Description
script/​sync_components.py	Enables flash_chip using the universally valid generic probe.
tests/​test_sync_components_esp32_visibility.py	Verifies generated and synthetic field visibility across schema versions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.