mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-03 04:31:28 +02:00
maziggy
b6027b7138
The settings panel collapsed four causes into one message -- "the picked preset's own values could not be read" -- with no indication of what to do about it. The overwhelmingly common cause has an obvious fix, and it isn't an edge case: an install pulls its sidecar as SIDECAR_TAG:-latest regardless of which Bambuddy channel it is on, so a current Bambuddy talking to a sidecar that predates POST /profiles/resolve is the normal state, not a misconfiguration. Those users would have seen an amber warning on every slice with nothing pointing at the sidecar image. resolve_profile now returns ResolvedProfile(values, reason) instead of None for everything, the route passes the reason through, and the panel picks its message from it: sidecar_outdated -> name the fix: update the sidecar image sidecar_unavailable -> the sidecar did not answer not_configured -> no sidecar is configured preset_unresolved -> the previous generic wording A request that fails outright maps to sidecar_unavailable, since a backend we cannot reach and a sidecar that will not answer are the same thing from the dialog. Every variant still ends with "anything you don't change still uses the preset" -- that reassurance is the point of the notice, and it is true whichever way the lookup failed. Tests pin the distinction rather than just the happy path: a 404 and a 500 must produce different reasons, and each panel case asserts both that its own message appears and that the "update the sidecar image" line does not leak into the others.
React + TypeScript + Vite
This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Currently, two official plugins are available:
- @vitejs/plugin-react uses Babel (or oxc when used in rolldown-vite) for Fast Refresh
- @vitejs/plugin-react-swc uses SWC for Fast Refresh
React Compiler
The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.
Expanding the ESLint configuration
If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:
export default defineConfig([
globalIgnores(['dist']),
{
files: ['**/*.{ts,tsx}'],
extends: [
// Other configs...
// Remove tseslint.configs.recommended and replace with this
tseslint.configs.recommendedTypeChecked,
// Alternatively, use this for stricter rules
tseslint.configs.strictTypeChecked,
// Optionally, add this for stylistic rules
tseslint.configs.stylisticTypeChecked,
// Other configs...
],
languageOptions: {
parserOptions: {
project: ['./tsconfig.node.json', './tsconfig.app.json'],
tsconfigRootDir: import.meta.dirname,
},
// other options...
},
},
])
You can also install eslint-plugin-react-x and eslint-plugin-react-dom for React-specific lint rules:
// eslint.config.js
import reactX from 'eslint-plugin-react-x'
import reactDom from 'eslint-plugin-react-dom'
export default defineConfig([
globalIgnores(['dist']),
{
files: ['**/*.{ts,tsx}'],
extends: [
// Other configs...
// Enable lint rules for React
reactX.configs['recommended-typescript'],
// Enable lint rules for React DOM
reactDom.configs.recommended,
],
languageOptions: {
parserOptions: {
project: ['./tsconfig.node.json', './tsconfig.app.json'],
tsconfigRootDir: import.meta.dirname,
},
// other options...
},
},
])