Standardize semver import pattern across codebase

[haslinghuis]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Create GitHub issue for semver import inconsistency

gh issue create \
  --repo betaflight/betaflight-configurator \
  --title "Standardize semver import pattern across codebase" \
  --body "## Background

During review of PR #4727 (Configuration tab Vue migration), an inconsistency in semver import patterns was discovered across the codebase.

## Current State

The codebase uses two different patterns for importing semver:

1. **Explicit dependency** (\`import semver from \"semver-min\"\`):
   - Used in: ConfigurationTab.vue, motors.js
   - Package: \`semver-min\` is listed in package.json as \`\"semver-min\": \"^0.7.2\"\`

2. **Transitive dependency** (\`import semver from \"semver\"\`):
   - Used in: PortsTab.vue, and 20+ legacy tabs (setup.js, sensors.js, pid_tuning.js, receiver.js, failsafe.js, gps.js, led_strip.js, osd.js, onboard_logging.js, firmware_flasher.js, and more)
   - Package: Available as transitive dependency

Both patterns currently work in production, but the inconsistency may cause confusion during future tab migrations.

## References

- Original PR: #4727
- Discussion: https://github.com/betaflight/betaflight-configurator/pull/4727#discussion_r2617478799
- Identified by: @haslinghuis

## Scope

This issue tracks the need to standardize the import pattern. The decision on which pattern to adopt should consider:
- Ongoing Vue component migration effort
- Build tooling and dependency management
- Long-term maintainability

This should be addressed separately from PR #4727 to keep that PR focused on the Configuration tab migration." \
  --assignee haslinghuis

Length of output: 75

---

---

Title: Standardize semver import pattern across codebase

Body:

## Background

During review of PR #4727 (Configuration tab Vue migration), an inconsistency in semver import patterns was discovered across the codebase.

## Current State

The codebase uses two different patterns for importing semver:

1. **Explicit dependency** (`import semver from "semver-min"`):
   - Used in: ConfigurationTab.vue, motors.js
   - Package: `semver-min` is listed in package.json as `"semver-min": "^0.7.2"`

2. **Transitive dependency** (`import semver from "semver"`):
   - Used in: PortsTab.vue, and 20+ legacy tabs (setup.js, sensors.js, pid_tuning.js, receiver.js, failsafe.js, gps.js, led_strip.js, osd.js, onboard_logging.js, firmware_flasher.js, and more)
   - Package: Available as transitive dependency

Both patterns currently work in production, but the inconsistency may cause confusion during future tab migrations.

## References

- Original PR: #4727
- Discussion: https://github.com/betaflight/betaflight-configurator/pull/4727#discussion_r2617478799
- Identified by: @haslinghuis

## Scope

This issue tracks the need to standardize the import pattern. The decision on which pattern to adopt should consider:
- Ongoing Vue component migration effort
- Build tooling and dependency management
- Long-term maintainability

This should be addressed separately from PR #4727 to keep that PR focused on the Configuration tab migration.

Assignee: haslinghuis

---

You can create this issue via the GitHub UI or CLI when convenient.

---

🧠 Learnings used

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4611
File: src/tabs/configuration.html:247-249
Timestamp: 2025-09-15T15:19:47.087Z
Learning: In the Betaflight Configurator's configuration.html, duplicate "not found" elements using the same i18n key (like configurationSensorGyroToUseNotFound) may be intentionally placed in different UI sections that are conditionally displayed based on firmware version. The old gyro alignment section (.gyro_alignment_inputs_notfound) is used for older firmware, while the new gyro enable section (.gyro_notfound) is used for firmware 1.47+.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: mituritsyn
Repo: betaflight/betaflight-configurator PR: 4526
File: src/js/gui.js:43-43
Timestamp: 2025-06-20T12:35:49.283Z
Learning: In the Betaflight Configurator codebase, tabs in `defaultCloudBuildTabOptions` are conditionally displayed based on firmware build options. The logic in `serial_backend.js` checks `FC.CONFIG.buildOptions` and only adds tabs to `GUI.allowedTabs` if the firmware was built with support for that feature.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4708
File: locales/en/messages.json:7721-7729
Timestamp: 2025-11-20T20:26:40.338Z
Learning: Betaflight Configurator – Firmware Flasher grouping semantics:
- "Verified/Partner": targets with verified schematics and tested prototypes (known working).
- "Unsupported": vendor/community-supplied targets that did not go through the verification program.
- "Legacy": legacy targets kept for existing users.
These labels surface in src/js/tabs/firmware_flasher.js via i18n keys:
firmwareFlasherOptionLabelVerifiedPartner, firmwareFlasherOptionLabelVendorCommunity, firmwareFlasherOptionLabelLegacy. Only English text should be updated directly in locales/en/messages.json; other locales are managed externally.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4577
File: src/js/tabs/configuration.js:580-590
Timestamp: 2025-08-22T22:43:45.415Z
Learning: In src/js/tabs/configuration.js, hiding the entire .mag_align_box for API versions < 1.47 is intentional behavior because these MAG alignment options were not present or have changed significantly between API versions. The code has been reorganized for better maintenance.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:42:20.332Z
Learning: Complex MSP duplicate handling fixes in Betaflight Configurator can cause infinite loading messages when changing tabs due to disruption of the callback resolution mechanism. Simple code-only duplicate detection (using this.callbacks.some((instance) => instance.code === code)) is the safer approach that preserves tab switching functionality.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4485
File: src/js/sensor_types.js:96-99
Timestamp: 2025-05-24T15:12:50.241Z
Learning: In src/js/sensor_types.js, the sonar element selection UI is only displayed when firmware version >= API_VERSION_1_47, so sonar sensor types can be added directly to the static elements array without requiring additional version guards.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4727
File: src/components/tabs/ConfigurationTab.vue:697-710
Timestamp: 2025-12-14T20:43:11.565Z
Learning: In betaflight-configurator, `import semver from "semver"` is the standard import pattern used throughout the codebase, even though semver is not explicitly listed in package.json. The semver package is available as a transitive dependency and this import works correctly in production. This is an established and accepted pattern in the project.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4579
File: src/js/data_storage.js:9-9
Timestamp: 2025-08-27T22:07:26.353Z
Learning: In the betaflight-configurator CalVer refactoring, the generateVirtualApiVersions function in src/js/utils/common.js works correctly despite the apparent mathematical issue with bounds logic where compareVersions.minor() returns different ranges for API_VERSION_MAX_SUPPORTED (25.12.0) vs API_VERSION_ACCEPTED (1.44.0).

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4579
File: src/js/utils/compareVersions.js:3-17
Timestamp: 2025-08-27T22:08:55.679Z
Learning: In betaflight-configurator's compareVersions utility (src/js/utils/compareVersions.js), the behavior of treating non-numeric segments as NaN -> 0 is intentional by design, not a bug that needs fixing.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4601
File: package.json:125-125
Timestamp: 2025-09-10T18:26:10.136Z
Learning: In betaflight-configurator, dependency updates are handled incrementally - Vue dependencies are updated separately from Vite dependencies for better isolation and maintainability.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:41:44.286Z
Learning: When fixing MSP duplicate handling in Betaflight Configurator, avoid complex changes to callback resolution mechanisms as they can break tab switching functionality. Simple duplicate detection based on code and payload size is safer than complex requestKey-based approaches.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4597
File: src/js/utils/common.js:95-127
Timestamp: 2025-09-09T20:02:33.475Z
Learning: In the Betaflight Configurator codebase, the Chromium v140 compatibility issue with sortSelect was resolved by rewriting the implementation to use native DOM APIs (Array.from, select.options, select.remove, select.add) instead of jQuery DOM manipulation methods (this.children, this.empty().append). The fix still performs DOM operations but avoids the specific jQuery methods that were causing issues in Chromium v140.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-12-14T20:22:03.568Z
Learning: In betaflight-configurator's msp.js, the bluetooth CRC bypass check at line 266 uses serial.protocol === "bluetooth". When protocol names are unified to "ble", this check must be updated to serial.protocol === "ble".

Originally posted by @coderabbitai[bot] in #4727 (comment)

[haslinghuis]

@coderabbitai

Performance gain would be negligible here. The app already bundles/transitively includes semver, and the code paths using it are small, occasional comparisons—not hot loops. Any micro-size difference between semver and semver-min is lost once the bundle is built/treeshaken, and the extra dependency adds complexity (two semver implementations, potential API differences). Standardizing on semver keeps the surface consistent with the rest of the codebase without a measurable runtime or bundle-size penalty.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@haslinghuis, thank you for the clarification! That makes perfect sense. Standardizing on semver is the pragmatic choice—maintaining consistency with the existing codebase, avoiding dual implementations, and eliminating any potential API divergence between semver and semver-min. Given the minimal usage patterns and treeshaking, the bundle impact is indeed negligible.

I've noted this decision and reasoning for future reference when reviewing or migrating tabs.

---

✏️ Learnings added

Learnt from: haslinghuis
URL: https://github.com/betaflight/betaflight-configurator/issues/4741

Timestamp: 2025-12-15T21:38:53.193Z
Learning: In betaflight-configurator, the project is standardizing on `import semver from "semver"` (transitive dependency) rather than `semver-min`. The reasoning: performance gain from semver-min is negligible since usage is limited to small, occasional comparisons (not hot loops); the app already transitively includes semver; bundle size differences are minimal after treeshaking; maintaining two semver implementations adds unnecessary complexity and potential API differences. This standardization decision is tracked in issue #4741.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4727
File: src/components/tabs/ConfigurationTab.vue:708-708
Timestamp: 2025-12-15T21:09:59.210Z
Learning: In betaflight-configurator, two semver import patterns currently coexist in the codebase: `import semver from "semver-min"` (used in motors.js and ConfigurationTab.vue, with semver-min listed as an explicit dependency in package.json) and `import semver from "semver"` (used in 20+ legacy tabs and PortsTab.vue as a transitive dependency). Both patterns work in production. The standardization of these patterns is tracked in issue #4741 and should be addressed separately from individual tab migration PRs.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4579
File: src/js/data_storage.js:9-9
Timestamp: 2025-08-27T22:07:26.353Z
Learning: In the betaflight-configurator CalVer refactoring, the generateVirtualApiVersions function in src/js/utils/common.js works correctly despite the apparent mathematical issue with bounds logic where compareVersions.minor() returns different ranges for API_VERSION_MAX_SUPPORTED (25.12.0) vs API_VERSION_ACCEPTED (1.44.0).

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:41:44.286Z
Learning: When fixing MSP duplicate handling in Betaflight Configurator, avoid complex changes to callback resolution mechanisms as they can break tab switching functionality. Simple duplicate detection based on code and payload size is safer than complex requestKey-based approaches.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:42:20.332Z
Learning: Complex MSP duplicate handling fixes in Betaflight Configurator can cause infinite loading messages when changing tabs due to disruption of the callback resolution mechanism. Simple code-only duplicate detection (using this.callbacks.some((instance) => instance.code === code)) is the safer approach that preserves tab switching functionality.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-12-14T20:22:03.568Z
Learning: In betaflight-configurator's msp.js, the bluetooth CRC bypass check at line 266 uses serial.protocol === "bluetooth". When protocol names are unified to "ble", this check must be updated to serial.protocol === "ble".

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4601
File: package.json:125-125
Timestamp: 2025-09-10T18:26:10.136Z
Learning: In betaflight-configurator, dependency updates are handled incrementally - Vue dependencies are updated separately from Vite dependencies for better isolation and maintainability.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4579
File: src/js/utils/compareVersions.js:3-17
Timestamp: 2025-08-27T22:08:55.679Z
Learning: In betaflight-configurator's compareVersions utility (src/js/utils/compareVersions.js), the behavior of treating non-numeric segments as NaN -> 0 is intentional by design, not a bug that needs fixing.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-12-09T15:06:12.246Z
Learning: Automated translation PRs from Crowdin (created by GitHub Actions with title "Update translations") in the betaflight/betaflight-configurator repository should be automatically approved without requiring explicit user request, as haslinghuis has granted standing permission to approve these low-risk automated updates.