0.26.1 stops importing some packages

[vladcosorg]

Describe the bug

0.25.8 works well

import { read } from 'fs-jetpack'
Turns out to be empty when doing import destructuring.
import fs from 'fs-jetpack'
Works fine.

[FAILED] __vite_ssr_import_2__.read is not a function
[FAILED] __vite_ssr_import_2__.read is not a function
[FAILED] __vite_ssr_import_2__.read is not a function

TypeError: read is not a function

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-gv9cw4

System Info

System:
    OS: macOS 13.0
    CPU: (10) arm64 Apple M1 Pro
    Memory: 333.16 MB / 16.00 GB
    Shell: 3.5.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 16.17.0 - ~/Library/Caches/fnm_multishells/25612_1671194505564/bin/node
    Yarn: 1.22.19 - ~/Library/Caches/fnm_multishells/25612_1671194505564/bin/yarn
    npm: 8.19.3 - ~/Work/linktink/node_modules/.bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 106.0.5
    Safari: 16.1
    Safari Technology Preview: 16.4
  npmPackages:
    vitest: 0.25.8 => 0.26.1

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[vladcosorg]

interopDefault: true, from #2531 fixes it, but I've assumed it was fixed in 0.26.0

[sergioalmela]

Same with mkdirp: sync is not a function

[sheremet-va]

This is expected behaviour since 0.26.0. fs-jetpack doesn't support named exports in Node environment. (you can see this by importing import * as fs from fs-jetpack - there are no named exports). If you have a Node bundler that fixes this, you can enable test.deps.interopDefault: true yourself, as described in PR: #2512 (probably should be also mentioned in release notes how to bypass that). The error you will see when using named export in Node:

file:///home/projects/vitest-dev-vitest-mjaqu6/node.mjs:1
import { read } from 'fs-jetpack';
         ^^^^
SyntaxError: Named export 'read' not found. The requested module 'fs-jetpack' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'fs-jetpack';
const { read } = pkg;

    at _instantiate (https://vitestdevvitestmjaqu6-vlyf.w-corp.staticblitz.com/blitz.6ebe18b1e1db1833797e3e4eb6ff802c375ee61b.js:6:986476)
    at <anonymous> (<anonymous>)

We can probably improve the default handling, if you have any suggestions. The decisions was made to drop auto interop in Node because this code will not actually work with native node.

[EvHaus]

I'm having similar issues with @reduxjs/toolkit and next-auth packages. The following imports fail:

import {createAsyncThunk} from '@reduxjs/toolkit';

// and

import CredentialsProvider from 'next-auth/providers/credentials';

Vitest fails with:

TypeError: default is not a function
 ❯ pages/api/auth/[...nextauth].page.ts:74:3
     72|  },
     73|  providers: [
     74|   CredentialsProvider({
       |   ^
     75|    credentials: {
     76|     email: {
 ❯ utils/api/middleware/authentication.ts:1:31
 ❯ utils/api/middleware/index.ts:3:31

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

 FAIL  pages/api/report/[reportId]/build/GET.test.ts [ pages/api/report/[reportId]/build/GET.test.ts ]
 FAIL  pages/api/report/[reportId]/build/index.test.ts [ pages/api/report/[reportId]/build/index.test.ts ]
TypeError: createAsyncThunk is not a function
 ❯ Module.createAPIAction [as default] utils/redux/createAPIAction.ts:17:9
     15|  modifyResponse?: (response: Record<string, unknown>, payload: Input) …
     16| ) => {
     17|  return createAsyncThunk<Return, Input, {
       |         ^
     18|   dispatch: DispatchType,
     19|   rejectedMeta: ErrorReturnType,
 ❯ store/componentsActions.ts:41:23

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[2/75]⎯

I checked and both of those packages have the appropriate exports (from what I can tell). Rolling back to vitest 0.25.8 makes the problem go away.

I'm not sure what interopDefault is. I can't find any docs for it. Is that a vite setting?

[sheremet-va]

I'm not sure what interopDefault is. I can't find any docs for it. Is that a vite setting?

https://vitest.dev/config/#deps-interopdefault

Importing from @reduxjs/toolkit gives me this error:

import { createAsyncThunk } from '@reduxjs/toolkit';
         ^^^^^^^^^^^^^^^^
SyntaxError: Named export 'createAsyncThunk' not found. The requested module '@reduxjs/toolkit' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '@reduxjs/toolkit';
const { createAsyncThunk } = pkg;

    at _instantiate (https://vitestdevvitestmjaqu6-vlyf.w-corp.staticblitz.com/blitz.6ebe18b1e1db1833797e3e4eb6ff802c375ee61b.js:6:986476)
    at <anonymous> (<anonymous>)

In source code you can see exactly why this doesn't work:

All the code is on module.exports, which is default in Node ESM. Node doesn't allow using named exports with these. And 0.26.0 release makes Vitest more consistent:

if your environment is node, Vitest will not resolve invalid named exports (exports that are on "default" property will not magically appear as named exports)

next-auth has nested default:

---

Again, this changed is mentioned in release: https://github.com/vitest-dev/vitest/releases/tag/v0.26.0

If you are using non-node environment, Vitest assumes your bundler will fix this ESM issues. If you need to use node environment for some reason, and a have a bundler that fixes ESM issues for you, you can enable deps.interopDefault yourself. If you are using jsdom/happy-dom/edge, it's enabled by default.

[capaj]

I was having this issue with lodash and this import:

import { get } from 'lodash'

adding deps: { interopDefault: true, },

fixed it. Isn't it high time that lodash exports ESM modules @jdalton ?

[sheremet-va]

I was having this issue with lodash and this import:

import { get } from 'lodash'

adding `deps: {

  interopDefault: true,

},`

fixed it. Isn't it high time that lodash exports ESM modules @jdalton ?

I think there is lodash-es module for this?

[capaj]

yes, lodash-es fixes it and there is no need for interopDefault: true

[paescuj]

A bit confusing though that according to the docs interopDefault defaults to true but that doesn't seem to be the case.

In fact, configDefaults doesn't contain deps at all...

[sheremet-va]

A bit confusing though that according to the docs interopDefault defaults to true but that doesn't seem to be the case.

This is error in docs, it will be fixed.

In fact, configDefaults doesn't contain deps at all...

It cannot be on configDefaults, because default is dynamic and depends on environment.