Three rules cleaned in parallel passes — 187 fewer warnings, 0 TS
errors, 0 behaviour change beyond one incidental auth bugfix
flagged below.
storybook/no-redundant-story-name (23 → 0) — 14 stories files
Storybook v7+ infers the story name from the variable name, so
`name: 'Default'` next to `export const Default: Story = …` is
pure noise. Removed only when the name was redundant ;
preserved when the label was a French translation
('Par défaut', 'Chargement', 'Avec erreur', etc.) since those
are intentional.
react-refresh/only-export-components (25 → 0) — 21 files
Each warning marks a file that exports a React component AND a
hook / context / constant / barrel re-export. Suppressed
per-line with the suppression-with-justification pattern :
// eslint-disable-next-line react-refresh/only-export-components -- <kind>; refactor would split a tightly-coupled API
The justification matters — every comment names the specific
thing being co-located (hook / context / CVA constant / lazy
registry / route config / test util / backward-compat barrel).
Splitting these would create 21 new files for a HMR-only DX
win that's already a non-issue in practice.
@typescript-eslint/no-non-null-assertion (139 → 0) — 43 files
Distribution of fixes :
~85 cases : refactored to explicit guard
`if (!x) throw new Error('invariant: …')`
or hoisted into local with narrowing.
~36 cases : helper extraction (one tooltip test had 16
`wrapper!` patterns reduced to a single
`getWrapper()` helper).
~18 cases : suppressed with specific reason :
static literal arrays where index is provably
in bounds, mock fixtures with structural
guarantees, filter-then-map patterns where the
filter excludes the null branch.
One incidental find : services/api/auth.ts threw on missing
tokens but didn't guard `user` ; added the missing check while
refactoring the `user!` to a guard.
baseline post-commit : 921 warnings, 0 errors, 0 TS errors.
The remaining buckets are no-restricted-syntax (757, design-system
guardrail), no-explicit-any (115), exhaustive-deps (49).
CI --max-warnings will be lowered to 921 in the follow-up commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two-step cleanup of the no-unused-vars warning bucket :
1. Widened the rule's ignore patterns in eslint.config.js so the
`_`-prefix convention works uniformly across all four contexts
(function args, local vars, caught errors, destructured arrays).
The argsIgnorePattern was already `^_` ; added varsIgnorePattern,
caughtErrorsIgnorePattern, destructuredArrayIgnorePattern with
the same `^_` regex. Knocked 17 warnings out instantly because the
codebase had already adopted `_xxx` for unused locals and was
waiting on this config change.
2. Fixed the remaining 117 cases across 99 files by pattern :
* 26 catch-binding cases : `catch (e) {…}` → `catch {…}` (TS 4.0+
optional binding, ES2019). Cleaner than `catch (_e)` for the
dozen "swallow and toast" error handlers that don't read the
error.
* 58 unused imports removed (incl. one literal `electron`
contextBridge import that crept in from a phantom port-attempt).
* 28 destructure / assignment cases : prefixed with `_` where the
name documents the contract (test fixtures, hook return tuples
where one slot isn't used yet) ; deleted outright when the
assignment had no side effect and no documentary value.
* 3 function param cases : prefixed with `_`.
* 2 self-recursive `requestAnimationFrame` blocks that were dead
code (an interval-based alternative did the work) : deleted.
`tsc --noEmit` reports 0 errors after the changes. ESLint total
dropped from 1240 to 1108. Updated the baseline in
.github/workflows/ci.yml in the next commit.
Pattern decisions logged inline so future maintainers know that
`_`-prefix isn't slop — it's the documented, lint-aware way to mark
"intentionally unused" without having to remove the name.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Ajouter fallback pour Swagger UI si doc.json ne fonctionne pas
- Améliorer message d'erreur avec bouton pour ouvrir Swagger UI directement
- Les fonctionnalités API Keys et Usage Stats sont maintenant complètes et fonctionnelles
- Tous les onglets de DeveloperPage sont maintenant implémentés
- Remove obsolete error logging in api/auth.ts that expected tokens in localStorage
- Fix tokenRefresh.ts periodic refresh to not check tokens (httpOnly cookies not accessible)
- Mark Actions 5.1.1.6-5.1.1.9 as complete in TODO list
Actions 5.1.1.7-5.1.1.9 were already completed in previous actions:
- 5.1.1.7: TokenStorage already returns null (httpOnly cookies not readable)
- 5.1.1.8: tokenRefresh already works with cookies
- 5.1.1.9: All token access goes through TokenStorage
No localStorage.getItem/setItem calls for tokens remain (only removeItem for cleanup)
Backend changes (Action 5.1.1.1):
- Set access_token cookie in Login, Register, and Refresh handlers
- Cookie uses same configuration as refresh_token (httpOnly, Secure, SameSite)
- Expiry matches AccessTokenTTL (5 minutes)
- Update logout handler to clear access_token cookie
Backend middleware (Action 5.1.1.1):
- Update auth middleware to read access token from cookie first
- Fallback to Authorization header for backward compatibility
- Update OptionalAuth with same cookie-first logic
Frontend changes (Actions 5.1.1.2 & 5.1.1.3):
- Remove localStorage token storage from TokenStorage service
- TokenStorage now returns null for getAccessToken/getRefreshToken (httpOnly cookies not accessible)
- Remove Authorization header logic from API client
- Remove token expiration checks (can't check httpOnly cookies from JS)
- Update AuthContext to remove localStorage usage
- Update tokenRefresh to work without reading tokens from JS
- Simplify refresh logic: periodic refresh every 4 minutes (no expiration checks)
Security improvements:
- Access tokens no longer exposed to XSS attacks (httpOnly cookies)
- Tokens automatically sent with requests via withCredentials: true
- Backend reads tokens from cookies, not Authorization headers
- All users will need to re-login after deployment (breaking change)
Breaking change: All users must re-login after deployment
- Added PROACTIVE_REFRESH_INTERVAL_MS constant (4 minutes)
- Reduced PROACTIVE_REFRESH_BUFFER_MS to 1 minute (tokens expire in 5 min)
- Added proactiveRefreshInterval variable to track periodic refresh
- Created startPeriodicRefresh() function that sets up interval to refresh every 4 minutes
- Updated scheduleProactiveRefresh() to call startPeriodicRefresh()
- Updated cancelProactiveRefresh() to also clear the interval
- Periodic refresh checks token validity before refreshing
- Stops periodic refresh if token is expired or missing
- No TypeScript errors
- Works with existing token refresh infrastructure
- Action 5.1.1.5 complete
