Skip to content

mockNuxtImport doesn't work for nested composables #1395

@bbotto-pdga

Description

@bbotto-pdga

Environment

Nuxt project info: (copied to clipboard)                                                                                                                                                                                                                                 nuxi 2:52:12 PM

------------------------------
- Operating System: Linux
- Node Version:     v22.13.1
- Nuxt Version:     4.0.3
- CLI Version:      3.27.0
- Nitro Version:    2.12.4
- Package Manager:  [email protected]
- Builder:          -
- User Config:      app, compatibilityDate, devtools, modules, devServer, imports, runtimeConfig, vite, routeRules
- Runtime Modules:  @nuxt/[email protected], @nuxt/test-utils/[email protected]
- Build Modules:    -
------------------------------

👉 Report an issue: https://github.com/nuxt/nuxt/issues/new?template=bug-report.yml
👉 Suggest an improvement: https://github.com/nuxt/nuxt/discussions/new
👉 Read documentation: https://nuxt.com

Reproduction

https://stackblitz.com/edit/github-lzbjpwsv

Describe the bug

mockNuxtImport doesn't seem to work with composables in a nested directory when following the documentation's recommendation to re-export nested composables (https://nuxt.com/docs/4.x/guide/directory-structure/app/composables#how-files-are-scanned).

  • In the reproduction code, there are two composables in composables/nested/: useParent and useChild.
  • useParent calls useChild.
  • These composables are re-exported by composables/index.ts, as recommended by the aforementioned documentation.
  • The test suite for useParent (composables/nested/useParent.nuxt.spec.ts) mocks useChild using mockNuxtImport; however, useParent calls the original useChild instead of the mock.

It's possible that this is a duplicate of #708. Apologies if so.

Switching to nested directory scanning via Nuxt config (nuxt.config.ts -> imports-> dirs) fixes the issue, but goes against the recommendations in the docs.

Additional context

Note that the repro. uses Nuxt 3, but the issue is still present in Nuxt 4.

Logs

❯ npm run test

> test
> vitest

(node:357) ExperimentalWarning: WASI is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

 DEV  v3.2.4 /home/projects/mklilmrmvl.github

stdout | composables/nested/useParent.nuxt.spec.ts > checks that the child is called
useParent called. Calling useChild().
useChild called.

 ❯  nuxt  composables/nested/useParent.nuxt.spec.ts (1 test | 1 failed) 8ms
   × checks that the child is called 7ms
     → expected +0 to be 1 // Object.is equality

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL   nuxt  composables/nested/useParent.nuxt.spec.ts > checks that the child is called
AssertionError: expected +0 to be 1 // Object.is equality

- Expected
+ Received

- 1
+ 0

 ❯ eval composables/nested/useParent.nuxt.spec.ts:13:3
     11|   useParent();
     12| 
     13|   expect(mockUseChild.mock.calls.length).toBe(1);
       |   ^
     14| });
     15| 
 ❯ ../../../blitz.96435430.js:31:27890
 ❯ new Promise ../../../blitz.96435430.js:31:27849

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯


 Test Files  1 failed (1)
      Tests  1 failed (1)
   Start at  15:05:16
   Duration  3.74s (transform 475ms, setup 449ms, collect 419ms, tests 8ms, environment 804ms, prepare 645ms)

 FAIL  Tests failed. Watching for file changes...
       press h to show help, press q to quit


The test outputs "useChild called."  That shouldn't happen.  Instead, the mock should be called.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions