Pinia

Getters become values, state flips between mutable and read-only depending on where you stand, and ThisType decides who sees what.

The target is a type-level version of Pinia's defineStore. No implementation needed, just types. The function takes a single object with four properties: id (a string), state (a function returning the store's state), getters (computed-style methods) and actions (methods that can mutate state). Getters are defined as functions but consumed as plain values, and inside a getter the state is read-only:

const store = defineStore({
  // ...other required fields
  getters: {
    getSomething() {
      return 'xxx'
    }
  }
})
 
store.getSomething    // ok
store.getSomething()  // error

Actions stay callable functions. Their parameter and return types must survive intact so call sites are fully type-checked. Inside an action, this can read and mutate state and call other actions. Getters are visible there too, still read-only:

const store = defineStore({
  // ...other required fields
  actions: {
    doSideEffect() {
      this.xxx = 'xxx'
      return 'ok'
    }
  }
})
 
const returnValue = store.doSideEffect()

const store = defineStore({
// ...other required fields
getters: {
getSomething() {
return 'xxx'
}
}
})

[object Object]

[object Object]

const store = defineStore({
// ...other required fields
actions: {
doSideEffect() {
this.xxx = 'xxx'
return 'ok'
}
}
})

[object Object]

Detailed Explanation

The full solution:

type GetterValues<TGetters> = {
  readonly [K in keyof TGetters]: TGetters[K] extends () => infer Result
    ? Result
    : never
}
 
declare function defineStore<TState, TGetters, TActions>(store: {
  id: string
  state: () => TState
  getters: TGetters & ThisType<Readonly<TState> & GetterValues<TGetters>>
  actions: TActions &
    ThisType<TState & GetterValues<TGetters> & TActions>
}): TState & GetterValues<TGetters> & TActions

The challenge comes down to one question asked three times: what is visible, and what is mutable, through this or the store in a given context.

Inferring the three shapes

defineStore<TState, TGetters, TActions> gets all three type arguments inferred from the object literal you pass in: TState from the return type of state, and TGetters/TActions from the literal shapes of those objects. For the test store:

// TState   = { num: number; str: string }
// TGetters = { stringifiedNum: () => string; parsedNum: () => number }
// TActions = { init: () => void; increment: (step?: number) => void; ... }

GetterValues: functions in, values out

Getters are written as functions but read as values. store.stringifiedNum is a string, and store.stringifiedNum() must be an error. GetterValues does the conversion with a mapped type:

type Example = GetterValues<{ stringifiedNum: () => string }>
// evaluates to: { readonly stringifiedNum: string }

For each key, TGetters[K] extends () => infer Result extracts the function's return type. Two details matter here:

• The readonly modifier on the mapped type is not decoration. It is what makes this.parsedNum = 0 inside an action a compile error, which satisfies that @ts-expect-error in the tests. Getters are derived values; nobody gets to assign to them.
• Because the calling code sees stringifiedNum: string instead of a function, store.stringifiedNum() fails on its own: you can't call a string.

ThisType: a different this per context

ThisType<T> is an empty marker interface with special compiler support: when an object literal is contextually typed by X & ThisType<T>, every method in that literal gets this: T automatically. (This requires the noImplicitThis compiler option, which is on under strict; without it, ThisType has no effect.) The solution uses it twice, with deliberately different Ts.

Getters get ThisType<Readonly<TState> & GetterValues<TGetters>>:

• Readonly<TState> lets a getter read this.num but makes this.num += 1 an error. The tests explicitly check that state is immutable from a getter's perspective.
• GetterValues<TGetters> lets getters compose: parsedNum reads this.stringifiedNum as an already-unwrapped string.
• Actions are not included. That is what this challenge's tests require, and it enforces the discipline of getters as pure derivations. (Real Pinia is more permissive here: inside a getter, this is the whole store, actions included.)

Actions get ThisType<TState & GetterValues<TGetters> & TActions>:

• Plain TState, without Readonly: mutation like this.num += step is the whole point of an action.
• GetterValues<TGetters>: readable, but the mapped readonly still blocks assignment.
• TActions itself: actions can call each other, as init() does with this.reset() and this.increment().

The return type: the public store

The store you hand back is the same intersection the actions see:

[object Object]

State properties come through as-is (store.num is number), getters as unwrapped read-only values, and actions as untouched functions. Keeping TActions untouched is what preserves signatures exactly: increment(step = 1) is inferred as (step?: number) => void, so store.increment() and store.increment(2) both work while store.init(0), a call with an argument to a zero-parameter action, fails.

Edge cases the tests cover

• store.nopeStateProp / store.nopeGetter: the store is an exact intersection, not any or an index signature, so unknown properties are errors.
• const r = store.reset() with Equal<typeof r, true>: because TActions flows through inference untouched, even the literal return type true survives to the call site.
• store.setNum('3') fails while store.setNum(3) works: parameter types are preserved, not erased to any.
• this.num += 1 errors in a getter but this.num += step compiles in an action: same property, two different ThisType views.

If you solved Simple Vue, this is the same trick with sharper edges. The mechanics of ThisType are not the hard part; deciding which capabilities each context gets to see is.