@blueking/bkui-knowledge 0.0.1-beta.1 → 0.0.1-beta.10

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/define-model-update-event.md

@@ -0,0 +1,79 @@
+---
+title: defineModel Fires Update Event with Undefined
+impact: MEDIUM
+impactDescription: fixes runtime errors from unexpected undefined in model updates
+type: capability
+tags: defineModel, v-model, update-event, undefined, vue-3.5
+---
+
+# defineModel Fires Update Event with Undefined
+
+**Impact: MEDIUM** - fixes runtime errors from unexpected undefined in model updates
+
+> **Version Note (2025):** This issue may be resolved in Vue 3.5+. Testing with Vue 3.5.26 could not reproduce the double emission with `undefined`. If you're on Vue 3.5+, verify the issue exists in your specific scenario before applying workarounds.
+
+Components using `defineModel` may fire the `@update:model-value` event with `undefined` in certain edge cases. TypeScript types don't always reflect this behavior, potentially causing runtime errors when the parent expects a non-nullable value.
+
+## Symptoms
+
+- Parent component receives `undefined` unexpectedly
+- Runtime error: "Cannot read property of undefined"
+- Type mismatch between expected `T` and received `T | undefined`
+- Issue appears when clearing/resetting the model value
+
+## Root Cause
+
+`defineModel` returns `Ref<T | undefined>` by default, even when `T` is non-nullable. The update event can fire with `undefined` when:
+- Component unmounts
+- Model is explicitly cleared
+- Internal state resets
+
+## Fix
+
+**Option 1: Use required option (Vue 3.5+)**
+```typescript
+// Returns Ref<Item> instead of Ref<Item | undefined>
+const model = defineModel<Item>({ required: true })
+```
+
+**Option 2: Type parent handler to accept undefined**
+```vue
+<template>
+  <MyComponent
+    v-model="item"
+    @update:model-value="handleUpdate"
+  />
+</template>
+
+<script setup lang="ts">
+// Handle both value and undefined
+const handleUpdate = (value: Item | undefined) => {
+  if (value !== undefined) {
+    item.value = value
+  }
+}
+</script>
+```
+
+**Option 3: Use default value in defineModel**
+```typescript
+const model = defineModel<string>({ default: '' })
+```
+
+## Type Declaration Pattern
+
+```typescript
+// In child component
+interface Props {
+  modelValue: Item
+}
+const model = defineModel<Item>({ required: true })
+
+// Emits will be typed as (value: Item) not (value: Item | undefined)
+```
+
+## Reference
+
+- [vuejs/core#12817](https://github.com/vuejs/core/issues/12817)
+- [vuejs/core#10103](https://github.com/vuejs/core/issues/10103)
+- [defineModel docs](https://vuejs.org/api/sfc-script-setup.html#definemodel)

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/duplicate-plugin-detection.md

@@ -0,0 +1,102 @@
+---
+title: Duplicate Vue Plugin Detection
+impact: MEDIUM
+impactDescription: fixes cryptic build errors from Vue plugin registered twice
+type: capability
+tags: vite, plugin, vue, duplicate, config, inline
+---
+
+# Duplicate Vue Plugin Detection
+
+**Impact: MEDIUM** - fixes cryptic build errors from Vue plugin registered twice
+
+When using Vite's JavaScript API, if the Vue plugin is loaded in `vite.config.js` and specified again in `inlineConfig`, it gets registered twice, causing cryptic build errors.
+
+## Symptoms
+
+- Build produces unexpected output or fails silently
+- "Cannot read property of undefined" during build
+- Different build behavior between CLI and JavaScript API
+- Vue components render incorrectly after build
+
+## Root Cause
+
+Vite doesn't deduplicate plugins by name when merging configs. The Vue plugin's internal state gets corrupted when registered twice.
+
+## Fix
+
+**Option 1: Use configFile: false with inline plugins**
+```typescript
+import { build } from 'vite'
+import vue from '@vitejs/plugin-vue'
+
+await build({
+  configFile: false,  // Don't load vite.config.js
+  plugins: [vue()],
+  // ... rest of config
+})
+```
+
+**Option 2: Don't specify plugins in inlineConfig**
+```typescript
+// vite.config.js already has vue plugin
+import { build } from 'vite'
+
+await build({
+  // Don't add vue plugin here - it's in vite.config.js
+  root: './src',
+  build: { outDir: '../dist' }
+})
+```
+
+**Option 3: Filter out Vue plugin before merging**
+```typescript
+import { build, loadConfigFromFile } from 'vite'
+import vue from '@vitejs/plugin-vue'
+
+const { config } = await loadConfigFromFile({ command: 'build', mode: 'production' })
+
+// Remove existing Vue plugin
+const filteredPlugins = config.plugins?.filter(
+  p => !p || (Array.isArray(p) ? false : p.name !== 'vite:vue')
+) || []
+
+await build({
+  ...config,
+  plugins: [...filteredPlugins, vue({ /* your options */ })]
+})
+```
+
+## Detection Script
+
+Add this to debug plugin registration:
+```typescript
+// vite.config.ts
+export default defineConfig({
+  plugins: [
+    vue(),
+    {
+      name: 'debug-plugins',
+      configResolved(config) {
+        const vuePlugins = config.plugins.filter(p => p.name?.includes('vue'))
+        if (vuePlugins.length > 1) {
+          console.warn('WARNING: Multiple Vue plugins detected:', vuePlugins.map(p => p.name))
+        }
+      }
+    }
+  ]
+})
+```
+
+## Common Scenarios
+
+| Scenario | Solution |
+|----------|----------|
+| Using `vite.createServer()` | Use `configFile: false` |
+| Build script with custom config | Don't duplicate plugins |
+| Monorepo with shared config | Check for plugin inheritance |
+
+## Reference
+
+- [Vite Issue #5335](https://github.com/vitejs/vite/issues/5335)
+- [Vite JavaScript API](https://vite.dev/guide/api-javascript.html)

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/fallthrough-attributes.md

@@ -0,0 +1,63 @@
+---
+title: Enable Fallthrough Attributes Type Checking
+impact: HIGH
+impactDescription: enables type-safe fallthrough attributes in component libraries
+type: capability
+tags: fallthroughAttributes, vueCompilerOptions, component-library, wrapper-components
+---
+
+# Enable Fallthrough Attributes Type Checking
+
+**Impact: MEDIUM** - enables type-aware attribute forwarding in component libraries
+
+When building component libraries with wrapper components, enable `fallthroughAttributes` to get IDE autocomplete for attributes that will be forwarded to child elements.
+
+## What It Does
+
+Wrapper components that pass attributes to child elements can benefit from type-aware completion:
+
+```vue
+<!-- MyButton.vue - wrapper around native button -->
+<template>
+  <button v-bind="$attrs"><slot /></button>
+</template>
+```
+
+## Solution
+
+Enable `fallthroughAttributes` in your tsconfig:
+
+```json
+// tsconfig.json or tsconfig.app.json
+{
+  "vueCompilerOptions": {
+    "fallthroughAttributes": true
+  }
+}
+```
+
+## How It Works
+
+When `fallthroughAttributes: true`:
+- Vue Language Server analyzes which element receives `$attrs`
+- IDE autocomplete suggests valid attributes for the target element
+- Helps developers discover available attributes
+
+> **Note:** This primarily enables IDE autocomplete for valid fallthrough attributes. It does NOT reject invalid attributes as type errors - arbitrary attributes are still allowed.
+
+## Related Options
+
+Combine with `strictTemplates` for comprehensive checking:
+
+```json
+{
+  "vueCompilerOptions": {
+    "strictTemplates": true,
+    "fallthroughAttributes": true
+  }
+}
+```
+
+## Reference
+
+- [Vue Language Tools Wiki - Vue Compiler Options](https://github.com/vuejs/language-tools/wiki/Vue-Compiler-Options)

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/hmr-vue-ssr.md

@@ -0,0 +1,124 @@
+---
+title: HMR Debugging for Vue SSR
+impact: MEDIUM
+impactDescription: fixes Hot Module Replacement breaking in Vue SSR applications
+type: efficiency
+tags: vite, hmr, ssr, vue, hot-reload, server-side-rendering
+---
+
+# HMR Debugging for Vue SSR
+
+**Impact: MEDIUM** - fixes Hot Module Replacement breaking in Vue SSR applications
+
+Hot Module Replacement breaks when modifying Vue component `<script setup>` sections in SSR applications. Changes cause errors instead of smooth updates, requiring full page reloads.
+
+## Symptoms
+
+- HMR works for `<template>` changes but breaks for `<script setup>`
+- "Cannot read property of undefined" after saving
+- Full page reload required after script changes
+- HMR works in dev:client but not dev:ssr
+
+## Root Cause
+
+SSR mode has a different transformation pipeline. The Vue plugin's HMR boundary detection doesn't handle SSR modules the same way as client modules.
+
+## Fix
+
+**Step 1: Ensure correct SSR plugin configuration**
+```typescript
+// vite.config.ts
+import { defineConfig } from 'vite'
+import vue from '@vitejs/plugin-vue'
+
+export default defineConfig({
+  plugins: [vue()],
+  ssr: {
+    // Don't externalize these for HMR to work
+    noExternal: ['vue', '@vue/runtime-core', '@vue/runtime-dom']
+  }
+})
+```
+
+**Step 2: Configure dev server for SSR HMR**
+```typescript
+// server.ts
+import { createServer } from 'vite'
+
+const vite = await createServer({
+  server: { middlewareMode: true },
+  appType: 'custom'
+})
+
+// Use vite.ssrLoadModule for server-side imports
+const { render } = await vite.ssrLoadModule('/src/entry-server.ts')
+
+// Handle HMR
+vite.watcher.on('change', async (file) => {
+  if (file.endsWith('.vue')) {
+    // Invalidate the module
+    const mod = vite.moduleGraph.getModuleById(file)
+    if (mod) {
+      vite.moduleGraph.invalidateModule(mod)
+    }
+  }
+})
+```
+
+**Step 3: Add HMR acceptance in entry-server**
+```typescript
+// entry-server.ts
+import { createApp } from './main'
+
+export async function render(url: string) {
+  const app = createApp()
+  // ... render logic
+}
+
+// Accept HMR updates
+if (import.meta.hot) {
+  import.meta.hot.accept()
+}
+```
+
+## Framework-Specific Solutions
+
+### Nuxt 3
+HMR should work out of the box. If not:
+```bash
+rm -rf .nuxt node_modules/.vite
+npm install
+npm run dev
+```
+
+### Vite SSR Template
+Ensure you're using the latest `@vitejs/plugin-vue`:
+```bash
+npm install @vitejs/plugin-vue@latest
+```
+
+## Debugging
+
+Enable verbose HMR logging:
+```typescript
+// vite.config.ts
+export default defineConfig({
+  server: {
+    hmr: {
+      overlay: true
+    }
+  },
+  logLevel: 'info'  // Shows HMR updates
+})
+```
+
+## Known Limitations
+
+- HMR for `<script>` (not `<script setup>`) may require full reload
+- SSR components with external dependencies may not hot-reload
+- State is not preserved for SSR components (expected behavior)
+
+## Reference
+
+- [vite-plugin-vue#525](https://github.com/vitejs/vite-plugin-vue/issues/525)
+- [Vite SSR Guide](https://vite.dev/guide/ssr.html)

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/module-resolution-bundler.md

@@ -0,0 +1,81 @@
+---
+title: moduleResolution Bundler Migration Issues
+impact: HIGH
+impactDescription: fixes "Cannot find module" errors after @vue/tsconfig upgrade
+type: capability
+tags: moduleResolution, bundler, tsconfig, vue-tsconfig, node, esm
+---
+
+# moduleResolution Bundler Migration Issues
+
+**Impact: HIGH** - fixes "Cannot find module" errors after @vue/tsconfig upgrade
+
+Recent versions of `@vue/tsconfig` changed `moduleResolution` from `"node"` to `"bundler"`. This can break existing projects with errors like "Cannot find module 'vue'" or issues with `resolveJsonModule`.
+
+## Symptoms
+
+- `Cannot find module 'vue'` or other packages
+- `Option '--resolveJsonModule' cannot be specified without 'node' module resolution`
+- Errors appear after updating `@vue/tsconfig`
+- Some third-party packages no longer resolve
+
+## Root Cause
+
+`moduleResolution: "bundler"` requires:
+1. TypeScript 5.0+
+2. Packages to have proper `exports` field in package.json
+3. Different resolution rules than Node.js classic resolution
+
+## Fix
+
+**Option 1: Ensure TypeScript 5.0+ everywhere**
+```bash
+npm install -D typescript@^5.0.0
+```
+
+In monorepos, ALL packages must use TypeScript 5.0+.
+
+**Option 2: Add compatibility workaround**
+```json
+{
+  "compilerOptions": {
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "resolvePackageJsonExports": false
+  }
+}
+```
+
+Setting `resolvePackageJsonExports: false` restores compatibility with packages that don't have proper exports.
+
+**Option 3: Revert to Node resolution**
+```json
+{
+  "compilerOptions": {
+    "moduleResolution": "node"
+  }
+}
+```
+
+## Which Packages Break?
+
+Packages break if they:
+- Lack `exports` field in package.json
+- Have incorrect `exports` configuration
+- Rely on Node.js-specific resolution behavior
+
+## Diagnosis
+
+```bash
+# Check which resolution is being used
+cat tsconfig.json | grep moduleResolution
+
+# Test if a specific module resolves
+npx tsc --traceResolution 2>&1 | grep "module-name"
+```
+
+## Reference
+
+- [vuejs/tsconfig#8](https://github.com/vuejs/tsconfig/issues/8)
+- [TypeScript moduleResolution docs](https://www.typescriptlang.org/tsconfig#moduleResolution)
+- [Vite discussion#14001](https://github.com/vitejs/vite/discussions/14001)

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/pinia-store-mocking.md

@@ -0,0 +1,159 @@
+---
+title: Mocking Pinia Stores with Vitest
+impact: HIGH
+impactDescription: properly mocks Pinia stores in component tests
+type: efficiency
+tags: pinia, vitest, testing, mock, createTestingPinia, store
+---
+
+# Mocking Pinia Stores with Vitest
+
+**Impact: HIGH** - properly mocks Pinia stores in component tests
+
+Developers struggle to properly mock Pinia stores: `createTestingPinia` requires explicit `createSpy` configuration, and "injection Symbol(pinia) not found" errors occur without proper setup.
+
+> **Important (@pinia/testing 1.0+):** The `createSpy` option is **REQUIRED**, not optional. Omitting it throws an error: "You must configure the `createSpy` option."
+
+## Symptoms
+
+- "injection Symbol(pinia) not found" error
+- "You must configure the `createSpy` option" error
+- Actions not properly mocked
+- Store state not reset between tests
+
+## Fix
+
+**Pattern 1: Basic setup with createTestingPinia**
+```typescript
+import { mount } from '@vue/test-utils'
+import { createTestingPinia } from '@pinia/testing'
+import { vi } from 'vitest'
+import MyComponent from './MyComponent.vue'
+import { useCounterStore } from '@/stores/counter'
+
+test('component uses store', async () => {
+  const wrapper = mount(MyComponent, {
+    global: {
+      plugins: [
+        createTestingPinia({
+          createSpy: vi.fn,  // REQUIRED in @pinia/testing 1.0+
+          initialState: {
+            counter: { count: 10 }  // Set initial state
+          }
+        })
+      ]
+    }
+  })
+
+  // Get the store instance AFTER mounting
+  const store = useCounterStore()
+
+  // Actions are automatically stubbed
+  await wrapper.find('button').trigger('click')
+  expect(store.increment).toHaveBeenCalled()
+})
+```
+
+**Pattern 2: Customize action behavior**
+```typescript
+test('component handles async action', async () => {
+  const wrapper = mount(MyComponent, {
+    global: {
+      plugins: [
+        createTestingPinia({
+          createSpy: vi.fn,
+          stubActions: false  // Don't stub, use real actions
+        })
+      ]
+    }
+  })
+
+  const store = useCounterStore()
+
+  // Override specific action
+  store.fetchData = vi.fn().mockResolvedValue({ items: [] })
+
+  await wrapper.find('.load-button').trigger('click')
+  expect(store.fetchData).toHaveBeenCalled()
+})
+```
+
+**Pattern 3: Testing store directly**
+```typescript
+import { setActivePinia, createPinia } from 'pinia'
+import { useCounterStore } from '@/stores/counter'
+
+describe('Counter Store', () => {
+  beforeEach(() => {
+    setActivePinia(createPinia())
+  })
+
+  test('increments count', () => {
+    const store = useCounterStore()
+    expect(store.count).toBe(0)
+
+    store.increment()
+    expect(store.count).toBe(1)
+  })
+})
+```
+
+## Setup Store with Vitest
+
+```typescript
+// stores/counter.ts - Setup store syntax
+export const useCounterStore = defineStore('counter', () => {
+  const count = ref(0)
+  const doubleCount = computed(() => count.value * 2)
+
+  function increment() {
+    count.value++
+  }
+
+  return { count, doubleCount, increment }
+})
+
+// Test file
+test('setup store works', async () => {
+  const pinia = createTestingPinia({
+    createSpy: vi.fn,
+    initialState: {
+      counter: { count: 5 }
+    }
+  })
+
+  const wrapper = mount(MyComponent, {
+    global: { plugins: [pinia] }
+  })
+
+  const store = useCounterStore()
+  expect(store.count).toBe(5)
+  expect(store.doubleCount).toBe(10)
+})
+```
+
+## Reset Between Tests
+
+```typescript
+describe('Store Tests', () => {
+  let pinia: Pinia
+
+  beforeEach(() => {
+    pinia = createTestingPinia({
+      createSpy: vi.fn
+    })
+  })
+
+  afterEach(() => {
+    vi.clearAllMocks()
+  })
+
+  test('test 1', () => { /* ... */ })
+  test('test 2', () => { /* ... */ })
+})
+```
+
+## Reference
+
+- [Pinia Testing Guide](https://pinia.vuejs.org/cookbook/testing.html)
+- [Pinia Discussion #2092](https://github.com/vuejs/pinia/discussions/2092)

package/knowledge/skills/external/vue-skills/skills/vue-best-practices/rules/script-setup-jsdoc.md

@@ -0,0 +1,85 @@
+---
+title: JSDoc Documentation for Script Setup Components
+impact: MEDIUM
+impactDescription: enables proper documentation for composition API components
+type: capability
+tags: jsdoc, script-setup, documentation, composition-api, component
+---
+
+# JSDoc Documentation for Script Setup Components
+
+**Impact: MEDIUM** - enables proper documentation for composition API components
+
+`<script setup>` doesn't have an obvious place to attach JSDoc comments for the component itself. Use a dual-script pattern.
+
+## Problem
+
+**Incorrect:**
+```vue
+<script setup lang="ts">
+/**
+ * This comment doesn't appear in IDE hover or docs
+ * @component
+ */
+import { ref } from 'vue'
+
+const count = ref(0)
+</script>
+```
+
+JSDoc comments inside `<script setup>` don't attach to the component export because there's no explicit export statement.
+
+## Solution
+
+Use both `<script>` and `<script setup>` blocks:
+
+**Correct:**
+```vue
+<script lang="ts">
+/**
+ * A counter component that displays and increments a value.
+ *
+ * @example
+ * ```vue
+ * <Counter :initial="5" @update="handleUpdate" />
+ * ```
+ *
+ * @component
+ */
+export default {}
+</script>
+
+<script setup lang="ts">
+import { ref } from 'vue'
+
+const props = defineProps<{
+  /** Starting value for the counter */
+  initial?: number
+}>()
+
+const emit = defineEmits<{
+  /** Emitted when counter value changes */
+  update: [value: number]
+}>()
+
+const count = ref(props.initial ?? 0)
+</script>
+```
+
+## How It Works
+
+- The regular `<script>` block's default export is merged with `<script setup>`
+- JSDoc on `export default {}` attaches to the component
+- Props and emits JSDoc in `<script setup>` still work normally
+
+## What Gets Documented
+
+| Location | Shows In |
+|----------|----------|
+| `export default {}` JSDoc | Component import hover |
+| `defineProps` JSDoc | Prop hover in templates |
+| `defineEmits` JSDoc | Event handler hover |
+
+## Reference
+
+- [Vue Language Tools Discussion #5932](https://github.com/vuejs/language-tools/discussions/5932)