@peerigon/configs 14.7.0 → 14.9.0

package/CHANGELOG.md

@@ -1,3 +1,15 @@
+# [14.9.0](https://github.com/peerigon/configs/compare/v14.8.0...v14.9.0) (2026-03-18)
+
+### Features
+
+- **ai:** Improve testing styleguide ([cc07dfd](https://github.com/peerigon/configs/commit/cc07dfd46e24f747ad06b3fc2f79e923872f6c94))
+
+# [14.8.0](https://github.com/peerigon/configs/compare/v14.7.0...v14.8.0) (2026-03-16)
+
+### Features
+
+- **ai:** Apply best practices from "A Philosophy of Software Design" ([ad5f17d](https://github.com/peerigon/configs/commit/ad5f17dfc6534196fb65813682a2a429f7eb0495))
+
 # [14.7.0](https://github.com/peerigon/configs/compare/v14.6.0...v14.7.0) (2026-03-16)
 
 ### Features

package/ai/coding-styleguide-js-ts.mdc

@@ -100,7 +100,9 @@ globs: **/*.js, **/*.ts, **/*.mjs, **/*.cjs, **/*.mts, **/*.cts
 
 ## Comments
 
-- Use JSDoc comments and its tags where appropriate
+- Use comments to explain why, invariants, constraints, and non-obvious trade-offs
+- Do not write comments that only restate what the code already makes obvious
+- Add short contract comments only for complex or high-impact exports. Focus on purpose, guarantees, and important caveats.
 
 ## Testing
 

package/ai/coding-styleguide-react.mdc

@@ -9,6 +9,7 @@ globs: **/*.tsx, **/*.jsx
 - Inline component props next to the component prop argument
 - Derive state where possible
 - Avoid unnecessary `useState` and `useEffect`
-- `useEffect` **must** contain an async function call (unless it's a synchronous browser api like `localStorage`)
+- Use `useEffect` only when synchronizing with external systems (for example browser APIs, subscriptions, timers, network interactions)
+- Keep effects small, deterministic, and cleanup-safe
 - Avoid `useMemo` and `useCallback` unless its absolutely necessary
 - Create a story for each React component if Storybook is used

package/ai/coding-styleguide-testing.mdc

@@ -7,10 +7,12 @@ globs: **/*.test.js, **/*.test.ts, **/*.test.tsx
 
 ## General principle
 
-**Important**: Write as less tests as possible while covering all relevant scenarios. Focus on testing the behavior of the code rather than implementation details.
+**Important**: Aim for the smallest high-value test set that protects behavior, interface contracts, invariants, and regression-prone paths. Focus on testing behavior rather than implementation details.
 
 ## Structure & Organization
 
+- Order of tests: Match the order of tests to the order of symbols in the source file
+- One describe per export: Provide a describe block for each exported symbol (function, class, constant)
 - Hierarchical grouping: Use nested describe() blocks - outer for function/class, inner for scenarios
 - Logical categorization: Group by behavior, input type, or state (e.g., "with valid input", "error handling")
 - Each it() should test a single behavior
@@ -27,6 +29,7 @@ globs: **/*.test.js, **/*.test.ts, **/*.test.tsx
 
 - Type annotations: Include explicit types in test variables to verify inference
 - Compile-time checks: Some tests exist just to verify type compatibility
+- Type tests for generics: Add type tests for generic functions, classes, etc. Use the test runner's type testing tool when available (e.g. with Vitest: `expectTypeOf`)
 
 ## Best Practices
 

package/ai/rules.mdc

@@ -14,6 +14,12 @@ alwaysApply: true
 - Prefer explicit over implicit
 - Keep code close together that belongs together
 
+## Complexity and module design
+
+- Treat complexity as the primary enemy. Prefer designs that reduce mental load, special cases, and cross-module coupling.
+- Prefer deep modules with shallow interfaces: expose minimal API surface and hide implementation details by default.
+- Avoid pass-through abstractions that add layers but do not hide meaningful complexity.
+
 ## JavaScript & TypeScript
 
 See [Coding Styleguide JavaScript & TypeScript](./coding-styleguide-js-ts.mdc)
@@ -37,7 +43,7 @@ See [Coding Styleguide Shell Scripts](./coding-styleguide-sh.mdc)
 - Write unit tests for simple, pure functions
 - Unit test files are colocated with source files (\*.test.ts)
 - Write integration or e2e tests for more complex functions/classes/components
-- Run the linter and type checker only once after the implementation is complete and the tests are passing
+- Prefer staged validation for non-trivial tasks: run focused checks after meaningful changes, then run broader lint/type/test checks before handoff. For trivial tasks, a single final validation is acceptable.
 - Adjust documentation both in comments and markdown files once you're done
 
 ## Consumer-repo uncertainty protocol

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@peerigon/configs",
-  "version": "14.7.0",
+  "version": "14.9.0",
   "description": "Configs for ESLint, Prettier, TypeScript & friends",
   "keywords": [
     "eslint",