You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore: migrate to Biome for lint and format via Ultracite, remove ESLint Prettier and Stylelint, trim overrides and lockfile, reformat app and server code, update VS Code Cursor hooks and AGENTS
2.**Meaningful naming** - Use descriptive names for functions, variables, and types
119
-
3.**Architecture decisions** - Component structure, data flow, and API design
120
-
4.**Edge cases** - Handle boundary conditions and error states
121
-
5.**User experience** - Accessibility, performance, and usability considerations
122
-
6.**Documentation** - Add comments for complex logic, but prefer self-documenting code
123
-
124
-
---
125
-
126
-
Most formatting and common issues are automatically fixed by ESLint + Prettier + Stylelint. Run `bun x ultracite fix` before committing to ensure compliance.
127
-
128
-
# Ultracite Code Standards
129
-
130
-
This project uses **Ultracite**, a zero-config preset that enforces strict code quality standards through automated formatting and linting.
131
-
132
-
## Quick Reference
133
-
134
-
-**Format code**: `bun x ultracite fix`
135
-
-**Check for issues**: `bun x ultracite check`
136
-
-**Diagnose setup**: `bun x ultracite doctor`
137
-
138
-
ESLint + Prettier + Stylelint (the underlying engine) provides robust linting and formatting. Most issues are automatically fixable.
139
-
140
-
---
141
-
142
-
## Core Principles
143
-
144
-
Write code that is **accessible, performant, type-safe, and maintainable**. Focus on clarity and explicit intent over brevity.
145
-
146
-
### Type Safety & Explicitness
147
-
148
-
- Use explicit types for function parameters and return values when they enhance clarity
149
-
- Prefer `unknown` over `any` when the type is genuinely unknown
150
-
- Use const assertions (`as const`) for immutable values and literal types
151
-
- Leverage TypeScript's type narrowing instead of type assertions
152
-
- Use meaningful variable names instead of magic numbers - extract constants with descriptive names
153
-
154
-
### Modern JavaScript/TypeScript
155
-
156
-
- Use arrow functions for callbacks and short functions
157
-
- Prefer `for...of` loops over `.forEach()` and indexed `for` loops
158
-
- Use optional chaining (`?.`) and nullish coalescing (`??`) for safer property access
159
-
- Prefer template literals over string concatenation
160
-
- Use destructuring for object and array assignments
161
-
- Use `const` by default, `let` only when reassignment is needed, never `var`
162
-
163
-
### Async & Promises
164
-
165
-
- Always `await` promises in async functions - don't forget to use the return value
166
-
- Use `async/await` syntax instead of promise chains for better readability
167
-
- Handle errors appropriately in async code with try-catch blocks
168
-
- Don't use async functions as Promise executors
169
-
170
-
### React & JSX
171
-
172
-
- Use function components over class components
173
-
- Call hooks at the top level only, never conditionally
174
-
- Specify all dependencies in hook dependency arrays correctly
175
-
- Use the `key` prop for elements in iterables (prefer unique IDs over array indices)
176
-
- Nest children between opening and closing tags instead of passing as props
177
-
- Don't define components inside other components
178
-
- Use semantic HTML and ARIA attributes for accessibility:
179
-
- Provide meaningful alt text for images
180
-
- Use proper heading hierarchy
181
-
- Add labels for form inputs
182
-
- Include keyboard event handlers alongside mouse events
183
-
- Use semantic elements (`<button>`, `<nav>`, etc.) instead of divs with roles
184
-
185
-
### Error Handling & Debugging
186
-
187
-
- Remove `console.log`, `debugger`, and `alert` statements from production code
188
-
- Throw `Error` objects with descriptive messages, not strings or other values
189
-
- Use `try-catch` blocks meaningfully - don't catch errors just to rethrow them
190
-
- Prefer early returns over nested conditionals for error cases
191
-
192
-
### Code Organization
193
-
194
-
- Keep functions focused and under reasonable cognitive complexity limits
195
-
- Extract complex conditions into well-named boolean variables
196
-
- Use early returns to reduce nesting
197
-
- Prefer simple conditionals over nested ternary operators
198
-
- Group related code together and separate concerns
199
-
200
-
### Security
201
-
202
-
- Add `rel="noopener"` when using `target="_blank"` on links
1.**Business logic correctness** - Biome can't validate your algorithms
245
115
2.**Meaningful naming** - Use descriptive names for functions, variables, and types
246
116
3.**Architecture decisions** - Component structure, data flow, and API design
247
117
4.**Edge cases** - Handle boundary conditions and error states
@@ -250,4 +120,4 @@ ESLint + Prettier + Stylelint's linter will catch most issues automatically. Foc
250
120
251
121
---
252
122
253
-
Most formatting and common issues are automatically fixed by ESLint + Prettier + Stylelint. Run `bun x ultracite fix` before committing to ensure compliance.
123
+
Most formatting and common issues are automatically fixed by Biome. Run `bun x ultracite fix` before committing to ensure compliance.
0 commit comments