Not sure what's tripping up Vitest's resolution, but it looks like slate is not properly externalized and that's causing double modules (direct import slate is processed by Vitest while indirect import of slate from @udecode/slate is loaded directly on Node). You see something like this when running with DEBUG:

$ DEBUG=vite-node:* npm test
...
  vite-node:client:native /home/hiroshi/Downloads/vitest-dev-vitest-dkrj52/node_modules/@udecode/slate/dist/index.mjs +16ms
  vite-node:server:request /home/hiroshi/Downloads/vitest-dev-vitest-dkrj52/node_modules/slate/dist/index.js +26ms
  vite-node:client:execute /home/hiroshi/Downloads/vitest-dev-vitest-dkrj52/node_modules/slate/dist/index.js +164ms
....

Potential workaround is to use test.server.deps.external: ["slate"] to avoid Vitest processing slate like this:
https://stackblitz.com/edit/vitest-dev-vitest-quwptx?file=vite.config.ts

export default defineConfig({
  test: {
    server: {
      deps: {
        external: ['slate']
      }
    }
  },
})

@hi-ogawa Thanks for the this! Do you know if there's a way we can fix this problem in the slate package?

Thanks for the this! Do you know if there's a way we can fix this problem in the slate package?

I think this could be a bug of Vitest. There's some heuristics to decide for vite-node to whether process an external package or not and probably slate is hitting some edge cases here. Let me check a bit:

Could it be because Slate using the extension .es.js for its module export? I don't see that extension listed anywhere in Vitest's code.

https://github.com/ianstormtaylor/slate/blob/main/packages/slate/package.json#L7-L11

It looks like ESM_SYNTAX_RE is false-detecting a code inside comments.

$ node
> const ESM_SYNTAX_RE = /(?:[\s;]|^)(?:import[\s\w*,{}]*from|import\s*["'*{]|export\b\s*(?:[*{]|default|class|type|function|const|var|let|async function)|import\.meta\b)/m;
undefined
> code = `// import { thisIsComment } from "test"`
'// import { thisIsComment } from "test"'
> ESM_SYNTAX_RE.test(code)
true

This is already fixed on mlly unjs/mlly#196, so we can probably copy the same thing to vite-node.

It looks like mlly's regex /\/\*.+?\*\/|\/\/.*(?=[nr])/g in unjs/mlly#196 doesn't strip multi line jsdoc comment, which is used by slate https://github.com/ianstormtaylor/slate/blob/85a1e1d3f3b9c47144a5a3b299989a088b45f5b4/packages/slate/src/interfaces/scrubber.ts#L18

Not sure whether we should go with regex or maybe we can use legitimate tokenizer like https://github.com/guybedford/es-module-lexer or https://github.com/antfu/strip-literal

I think \/\*.*?\*\/gs should work to target multi-line comments. The ? in .*? makes it lazy so it doesn't match multiple comments at once, and the s flag at the end tells . to match newline characters.

Oh, but it fails completely on this case

https://github.com/unjs/mlly/pull/155/files#diff-17d68be1f96cd54b8a5473b77ebcc090f7dcdf6537f426046c9d10526ef9352eR148-R150

Yeah, dotall flag s should help this case, but I wasn't entirely sure how much we can trust regex in general. I asked chatgpt and also checked stackoverflow https://stackoverflow.com/questions/5989315/regex-for-match-replacing-javascript-comments-both-multiline-and-inline and they are all slightly different and I was confused.

Using es-module-lexer would be fool-proof, but perf impact is the concern.

I think regex is probably good enough for the purpose of detecting whether or not the code contains imports. Even if we accidentally strip out some code that looks like a comment but isn't, there's a good chance that the remaining code will still tell us whether we're using ESM or not.

If the goal was to get a definite list of imports, using a lexer would be a much better solution, but I'm not sure it's necessary here.

Thanks @hi-ogawa, this has been very helpful