Reviewing files that changed from the base of the PR and between f514e3e and 4e89793.

• packages/nuxt/src/components/scan.ts (3 hunks)
• packages/nuxt/test/components-fixture/components/Named.ts (1 hunks)
• packages/nuxt/test/scan-components.test.ts (4 hunks)

packages/nuxt/test/components-fixture/components/Named.ts (1)

1-13: Looks good overall.

This new file properly demonstrates both a default and a named export using defineComponent. No issues spotted with the syntax or logic.

packages/nuxt/src/components/scan.ts (2)

84-91: Ensure consistent file naming logic.

When handling the file extension and constructing fileName, the code now consistently extracts fileExt using extname. Ensure this logic remains in sync with the newly supported .ts, .js, .tsx, and .jsx files, and that it gracefully handles edge cases (e.g., files lacking an extension).

---

168-177: Multi-export scanning looks solid.

Using resolveModuleExportNames for .ts, .js, .tsx, .jsx files is a clean approach for scanning multiple named exports. Automatically creating a component definition for each export is both convenient and user-friendly.

packages/nuxt/test/scan-components.test.ts (1)

52-55: Test coverage updates are excellent.

Including .ts in the extensions and updating the pattern ensures that TypeScript files are properly scanned. Adding two new components to the expectedComponents array verifies both the named and default exports from Named.ts.

Also applies to: 67-70, 81-86, 135-160

Reviewing files that changed from the base of the PR and between 4abf4a8 and 9a33ac6.

• packages/kit/package.json is excluded by !**/package.json
• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml, !pnpm-lock.yaml

• packages/kit/src/components.ts (3 hunks)
• packages/kit/src/index.ts (1 hunks)
• packages/kit/test/components.spec.ts (1 hunks)
• packages/nuxt/src/app/components/nuxt-error-boundary.ts (2 hunks)
• test/basic.test.ts (1 hunks)
• test/fixtures/basic/pages/error/error-boundary.vue (1 hunks)

• packages/kit/src/index.ts

• GitHub Check: codeql (javascript-typescript)
• GitHub Check: build
• GitHub Check: code

test/basic.test.ts (1)

1245-1251: Great addition of test coverage for error boundaries!

This test verifies that the NuxtErrorBoundary component correctly catches errors and renders fallback content without producing client-side errors. It's an essential test for ensuring error handling reliability, particularly during component failures at runtime.

test/fixtures/basic/pages/error/error-boundary.vue (2)

1-12: LGTM! Well-structured test fixture for error boundary testing.

This template correctly uses NuxtErrorBoundary with both the default and error slots, creating a proper test case for error handling.

---

14-24: Well-implemented broken component for testing.

The MyBrokenComponent is appropriately designed to trigger an error during the onMounted lifecycle hook, which is a realistic failure scenario for testing the error boundary functionality.

packages/nuxt/src/app/components/nuxt-error-boundary.ts (2)

3-3: Appropriate import for deferred error handling.

Adding the onNuxtReady import supports the new deferred error handling during hydration.

---

17-36: Excellent refactoring of error handling logic.

This refactoring significantly improves error handling during hydration:

1. Moving useNuxtApp() inside the client-only block is more appropriate
2. The handleError helper function effectively encapsulates error emission logic
3. Different handling paths for hydration vs non-hydration states ensures errors don't disrupt the hydration process
4. Deferring error handling until the app is ready during hydration is a more robust approach

This change makes the error boundary more reliable, especially during the critical hydration phase.

packages/kit/test/components.spec.ts (4)

1-4: Imports look good!

These foundational imports set up Vitest, Hookable, schema typing, and path utilities. They align well with project conventions.

---

6-17: Mock hooks and Nuxt instance are properly configured.

Defining mockHooks and mockNuxt ensures that tests run in isolation and correctly simulate Nuxt’s environment. This approach is both neat and maintainable.

---

19-23: Effective mocking of context references.

Mocking tryUseNuxt and useNuxt here allows for complete control over the Nuxt instance without side effects. This is a solid approach to isolating the tests from the actual Nuxt runtime.

---

25-38: Concise test logic setup.

The new test suite for addComponentExports is clear, with a properly prepared resolver and hook calls. This structure ensures readiness for subsequent test steps and fosters clarity of the tested functionality.

packages/kit/src/components.ts (4)

3-3: Importing from ‘mlly’ is correct.

Reliable resolution of export names ensures robust detection of named exports, aligning with the new scanning feature.

---

7-7: Importing resolvePath is well-chosen.

Leveraging resolvePath is a consistent approach which mirrors existing path resolution patterns within the Nuxt ecosystem.

---

45-47: addComponent remains simple and complements the new batch registration logic.

Delegating logic to normalizeComponent and addComponents ensures code reuse and maintainability.

---

78-100: normalizeComponent is consistent and uses defaults effectively.

The function ensures each component is assigned well-defined properties. The default mode detection from filename patterns is neatly handled.