Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
7 tasks done
fwouts opened this issue Jun 19, 2022 · 12 comments
Closed
7 tasks done

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

fwouts opened this issue Jun 19, 2022 · 12 comments
Labels
enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority) wontfix This will not be worked on

Comments

@fwouts
Copy link
Contributor

fwouts commented Jun 19, 2022

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

@bluwy
Copy link
Member

bluwy commented Jun 19, 2022

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
Copy link
Contributor Author

fwouts commented Jun 19, 2022

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-dev
Copy link
Member

@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
Copy link
Member

antfu commented Jun 19, 2022

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
Copy link
Contributor Author

fwouts commented Jun 19, 2022

@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
Copy link
Contributor Author

fwouts commented Jun 19, 2022

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

export const VITE_PACKAGE_DIR = resolve(
so it crashes on startup.

@patak-dev
Copy link
Member

@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
Copy link
Contributor Author

fwouts commented Jun 20, 2022

@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-dev
Copy link
Member

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

@patak-dev patak-dev added enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority) and removed pending triage labels Jun 20, 2022
@ldiqual
Copy link

ldiqual commented Jul 13, 2022

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
Copy link
Member

bluwy commented Jul 14, 2022

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?

@sapphi-red
Copy link
Member

Closing as Preview.js has achieved working with Vite v3 and I think we won't be stepping back to CJS.

@sapphi-red sapphi-red closed this as not planned Won't fix, can't repro, duplicate, stale Oct 29, 2022
@sapphi-red sapphi-red added the wontfix This will not be worked on label Oct 29, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Nov 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request p2-nice-to-have Not breaking anything but nice to have (priority) wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

6 participants