Switch to Typescript

[jpmckinney]

Follow up to #238

Prompts were:

• How big a changeset would adding TypeScript support be?
• If I switch to Pinia and change mixins to components in advance, how does that change the analysis?

Details

Revised Analysis: Pinia + Composables First

What you'd be doing in the pre-work

Pinia migration (store.js → Pinia stores):

• 488 lines of Vuex → likely 2-3 Pinia stores (~300 lines total)
• Eliminates mutations entirely (Pinia has direct state mutation)
• Replaces string-based commit/dispatch with direct function calls
• Pinia has first-class TS inference - types "just work"

Mixins → Composables (6 mixin files, ~200 lines total):

• stateMixins (22 lines) → useDatasetState()
• sortMixins (13 lines) → useSort()
• fieldCheckMixins (117 lines) → useFieldCheckSort()
• Others similar in size

The mixins are simple - mostly computed properties wrapping store getters and utility methods. Converting to composables is straightforward.

How this changes the TypeScript scope

┌───────────────────────┬──────────────────────────────────────┬─────────────────────────────────────────┐
│         Task          │           Without Pre-work           │        With Pinia + Composables         │
├───────────────────────┼──────────────────────────────────────┼─────────────────────────────────────────┤
│ Store typing          │ High effort (Vuex typing is verbose) │ Nearly free (Pinia auto-infers)         │
├───────────────────────┼──────────────────────────────────────┼─────────────────────────────────────────┤
│ Mixin typing          │ Awkward (this context issues)        │ Simple (composables are just functions) │
├───────────────────────┼──────────────────────────────────────┼─────────────────────────────────────────┤
│ Component refactoring │ Large (need to remove mixin usage)   │ Already done                            │
├───────────────────────┼──────────────────────────────────────┼─────────────────────────────────────────┤
│ tsconfig/build setup  │ Same                                 │ Same                                    │
├───────────────────────┼──────────────────────────────────────┼─────────────────────────────────────────┤
│ Props/emits typing    │ Same                                 │ Same                                    │
├───────────────────────┼──────────────────────────────────────┼─────────────────────────────────────────┤
│ API response types    │ Same                                 │ Same                                    │
└───────────────────────┴──────────────────────────────────────┴─────────────────────────────────────────┘

Bottom line

Doing Pinia + composables first means the TypeScript migration shrinks to:

1. Add tsconfig.json and configure Vite
2. Define interfaces for API responses (~5-6 types)
3. Add defineProps/defineEmits types to 43 components
4. Rename .js → .ts and .vue script blocks to <script setup lang="ts">

The hardest parts (store typing, mixin complexity) essentially disappear because Pinia and composables are TypeScript-native patterns. You'd be converting to TypeScript-friendly architecture
anyway - might as well do it in JavaScript first where you can test incrementally without fighting the type checker.