What this prompt does
This prompt builds a reusable Vue 3 composable library of [composable_count] composables — specifically [composable_list] — in TypeScript. For each composable it specifies a typed implementation with generics where applicable, reactive state via ref/reactive/computed, lifecycle integration (onMounted, onUnmounted) for cleanup, and SSR compatibility with isClient guards and onServerPrefetch.
The structure works because it packages the composables you keep rewriting across apps into one properly engineered library. Configurable options with sensible defaults, return-type interfaces for IDE autocomplete, unit tests with vitest and @vue/test-utils, and JSDocs with @example snippets make each composable robust and discoverable. Auto-import configuration, tree-shakeable exports, a [build_tool] bundle, npm publish config, and a playground app turn loose helpers into something a team can install and rely on.
Generic typing is what separates a useful composable from a frustrating one. Implementing each composable with generics where applicable means a useApi or useLocalStorage returns precisely typed values to the caller instead of forcing casts at every use site. Paired with VitePress documentation pages that include live demos, the library becomes self-explaining: a consumer can read the types, see an example, and try the behaviour before adopting it, which is exactly what makes a shared library worth maintaining.
When to use it
- You keep rewriting the same composables (
[composable_list]) across multiple Vue apps and want one shared library. - You need SSR-safe composables that do not break on server render.
- You want strong return-type interfaces so consumers get full IDE autocomplete.
- You need lifecycle cleanup handled so composables do not leak listeners or timers.
- You want unit tests and documentation shipped alongside each composable.
- You plan to publish to npm with tree-shaking and auto-import support.
Example output
Expect a publishable library: [composable_count] typed composables from [composable_list], each with reactive state, lifecycle cleanup, SSR guards, configurable options, and a return-type interface. It includes vitest unit tests, JSDocs with @example usage, VitePress documentation pages, auto-import config for unplugin-auto-import, tree-shakeable exports bundled with [build_tool], npm publish configuration, and a playground app for development.
Pro tips
- Start
[composable_list]with the helpers you genuinely reuse; a library of speculative composables nobody calls is wasted effort. - Always handle cleanup in onUnmounted — composables that add listeners or timers without removing them are a classic memory-leak source.
- Add the SSR guards (isClient, onServerPrefetch) from the start; retrofitting SSR safety later is far more painful.
- Invest in return-type interfaces; clean autocomplete is half the value of a composable library for the consuming team.
- Keep exports tree-shakeable so apps only bundle the composables they import, not the whole library.
- Use the playground app to dogfood each composable before publishing, catching API awkwardness while it is still cheap to change.
- Apply generics where a composable returns user-supplied data, so consumers get precise types instead of casting everywhere.
- Document each composable with a JSDoc @example so the VitePress page and IDE tooltip both show real usage at a glance.
