Vite 3.0.0-alpha.12 cannot work in CJS-only environments

[fwouts]

Describe the bug

In environments where ESM isn't supported, such as VS Code (see issue), Vite 3 cannot be loaded.

This is likely because the CJS version of Vite 3 is just a proxy that itself loads ESM modules: #8178. See Anthony's explanation: https://twitter.com/antfu7/status/1538173828492595201.

This will prevent VS Code extensions such as Preview.js from migrating to Vite 3.

Reproduction

https://github.com/fwouts/vite3-vscode-test

System Info

  System:
    OS: macOS 12.3.1
    CPU: (8) arm64 Apple M1
    Memory: 68.30 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.15.0 - ~/.nvm/versions/node/v16.15.0/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 8.9.0 - ~/.config/yarn/global/node_modules/.bin/npm
  Browsers:
    Chrome: 102.0.5005.115
    Firefox: 101.0.1
    Safari: 15.4
  npmPackages:
    vite: ^3.0.0-alpha.12 => 3.0.0-alpha.12

Used Package Manager

yarn

Logs

TypeError: Invalid host defined options
	at Object.module.exports.<computed> [as createServer] (/Users/fwouts/.vscode/extensions/fwouts.vite3-vscode-test-0.0.1/node_modules/vite/index.cjs:22:36)
	at /Users/fwouts/.vscode/extensions/fwouts.vite3-vscode-test-0.0.1/extension.js:27:10
	at o._executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:83:62521)
	at o.$executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:83:63225)
	at s._doInvokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:86:13828)
	at s._invokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:86:13512)
	at s._receiveRequest (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:86:12173)
	at s._receiveOneMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:86:10843)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:86:8949
	at g.invoke (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:145)
	at b.deliver (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:2265)
	at v.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:1843)
	at a.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:19025)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:102:34863
	at g.invoke (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:145)
	at b.deliver (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:2265)
	at v.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:1843)
	at a.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:19025)
	at r._receiveMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:23606)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:21140
	at g.invoke (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:145)
	at b.deliver (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:2265)
	at v.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:1843)
	at v.acceptChunk (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:15856)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:14986
	at Socket.R (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:102:13798)
	at Socket.emit (node:events:390:28)
	at addChunk (node:internal/streams/readable:315:12)
	at readableAddChunk (node:internal/streams/readable:289:9)
	at Socket.Readable.push (node:internal/streams/readable:228:10)
	at Pipe.onStreamRead (node:internal/stream_base_commons:199:23)

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.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• 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.

[bluwy]

Perhaps we may want to publish a CJS-variant only package of Vite to support this? Or a community maintained version specifically for VSCode 🤔

[fwouts]

Perhaps we may want to publish a CJS-variant only package of Vite to support this? Or a community maintained version specifically for VSCode 🤔

The problem I see with that approach is that a VS Code extension may still transitively depend on the "normal" version of Vite via one of its dependencies, so I'm not sure that can work (that's the case for my extension).

[patak-cat]

@fwouts do you know the position of the VS Code team regarding this issue?

I don't think publishing a separate CJS version will work. I don't know what are our options here, we need VS Code extensions to work with Vite v3.

@antfu any ideas?

[antfu]

Does Preview.js bundle a Vite into the extension, or it will use the one from users' local Vite? If it bundles, maybe you could use a bundler to directly transpile the ESM entry for VS Code to consume as CJS?

[fwouts]

@fwouts do you know the position of the VS Code team regarding this issue?

I'm not aware of any official plans aside from what's in microsoft/vscode#130367

Does Preview.js bundle a Vite into the extension, or it will use the one from users' local Vite? If it bundles, maybe you could use a bundler to directly transpile the ESM entry for VS Code to consume as CJS?

Preview.js runs an npm install on first startup in its own install directory, so that the user gets the right package for their platform (e.g. esbuild-linux-64). Here's the package.json and package-lock.json for the current release if you're curious: https://github.com/fwouts/previewjs/tree/main/loader/src/release

I've tried bundling before (with Vite 2) but ran into a few issues with some dependencies. I will try that again with Vite 3 when I find the time :)

Appreciate the help here by the way! I would totally understand if you decide to push forward with the current approach—it really is a VS Code issue at its core.

[fwouts]

Quick update: I tried bundling again with esbuild. Unfortunately it looks like at least some code depends on Vite being an NPM module in its own right, such as

vite/packages/vite/src/node/constants.ts

Line 54 in 49c0896

export const VITE_PACKAGE_DIR = resolve(

so it crashes on startup.

[patak-cat]

@fwouts given your comment here https://twitter.com/fwouts/status/1538699965740232704?s=20&t=qIxqqVnJHh_IXhdy5tt5yg, you are not blocked by this issue, no?

[fwouts]

@fwouts given your comment here https://twitter.com/fwouts/status/1538699965740232704?s=20&t=qIxqqVnJHh_IXhdy5tt5yg, you are not blocked by this issue, no?

You're right, I wouldn't be blocked entirely.

I'd likely choose to stay on V2 as late as possible as this change would be a big refactor that impacts performance of the extension negatively (there would be a fair bit of cross-process communication with this alternative model). I guess that's extra motivation to try fixing VS Code's loader myself 🙂

[patak-cat]

The best would be to fix VS Code's loader, and I imagine the pressure will raise for them during the next months. So maybe we should move forward with the current approach for v3. And we are going to continue to backport important fixes to v2, please flag them if you see something that we should take into account.
If a better solution is found, we can also change the dist model in v3.1

[ldiqual]

This is affecting us as we use ESM on frontends, CommonJS on backends, and a dev script that spins up vite instances via createServer in a CommonJS context. Is there a current workaround for using the dev server in commonjs?

[bluwy]

You can create the dev server with commonjs, just that using import() on an ESM file should work too, which the supported node versions should. Are you using a different environment other than node?