-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Support Vite #15427
Comments
Check out #12577 |
Yes, it's a personal goal of mine to support Vite. In fact you can already run Vite in Deno, although the invocation is somewhat long:
There's a caveat though - HMR is still not supported (ie. We also hope to further improve experience and current proposal that is in the works will allow to invoke it as:
|
Heyho, |
@LukaHarambasic I don't see how any special treatment has been given to Vite. Deno has a compatibility layer with Node that enables the use of non packages with Deno, nothing additional to improving that layer has been done in order to support Vite |
Vite just uses some of the still missing APIs from the node compat module, most of it isn't a change to the runtime. |
@josh-hemphill If we are talking about Node compat, the esbuild binary is already downloaded into |
Inching closer on Vite support, finally able to use HMR: Screen.Recording.2022-08-10.at.08.21.16.mov |
We've landed all necessary APIs to support Vite and we are able to run various Vite commands with success. There are a few missing pieces to make the experience top notch and we'll address them in the next weeks. For those who want to try it out for themselves, here's what you need to do (using Vue template):
import { defineConfig } from 'npm:vite'
import vue from 'npm:@vitejs/plugin-vue'
import "npm:vue@3.2.37/compiler-sfc" // <--- this step won't be needed in the future either
// https://vitejs.dev/config/
export default defineConfig({
plugins: [vue()]
})
Feedback much appreciated! |
FYI, I tried your recommendation above and it seemed to work well for Vue. I then tried the same with svelte. Alas, that did not seem to work (it never resolved the localhost endpoint). No errors in the terminal. Here's the repro repo: https://github.com/pillowsoft/my-svelte-deno-app Just wanted to give you feedback as requested. Looking forward to npm free vite builds!!!! I think I did things correctly and there are no errors when running. I can dig into it more if you like. I'm also guessing there will be a new build of the vscode extension to handle the "npm:****" resolution errors? P.S. |
Thanks, much appreciated. I'll try to debug that later tonight.
Yes, we're working on adding support for npm specifiers in the LSP
I think the brew build might not be available yet. |
Feedback for Deno v1.25 - seems like Vite dev mode does not run on Windows yet. I followed the steps in the previous comment, but the Vite dev server does not start. There is the following error message in console:
The root cause is this line of code: process.once('SIGTERM', exitProcess); Which seems to come from here: https://github.com/vitejs/vite/blob/757a92f1c7c4fa961ed963edd245df77382dfde6/packages/vite/src/node/server/index.ts#L446 After removing the line manually the dev server seems to be running, although the app is stuck on loading state and there is only a blank screen in the browser. Some good news though - vite build seems to work! |
Took a stab at it and I believe the problem is with "no dependencies found by scanner", however I'm not able to pinpoint the problem right now. I will resume debugging and fixes after the weekend. |
I might be doing something completely wrong but I wasn't able to run it. That's an error I am getting (both for 3.x and 2.x Vite versions):
I wonder if I am missing something here? |
@CyberAP that typo was fixed a few hours ago in denoland/std#2569. On the next release it should be resolved. |
I'm trying to fix compatibility between VitePress and deno, currently I'm getting this error: Error: [ERR_PACKAGE_PATH_NOT_EXPORTED] Package subpath './dist/vue.runtime.esm-bundler.js' is not defined by "exports" in /home/osboxes/.cache/deno/npm/registry.npmjs.org/vue/3.2.37/package.json imported from /home/osboxes/.cache/deno/npm/registry.npmjs.org/vitepress/1.0.0-alpha.12/dist/node/serve-0ffe109f.js But, vue's package.json already has this wildcard export: |
Yes, covered in #15605, expect a fix next week in v1.25.1 |
@brc-dd would you opening a separate issue for this problem with a reproduction? I would love to include it as a test |
@bartlomieju Add this in import { defineConfig } from 'npm:vite'
import vue from 'npm:@vitejs/plugin-vue'
import 'npm:vue@3.2.37/compiler-sfc'
import { createRequire } from 'https://deno.land/std@0.153.0/node/module.ts'
const require = createRequire(import.meta.url)
const vueRuntimePath = 'vue/dist/vue.runtime.esm-bundler.js'
export default defineConfig({
plugins: [vue()],
resolve: {
alias: [
{
find: /^vue$/,
replacement: require.resolve(vueRuntimePath)
}
]
}
}) |
Also true for import "npm:react@18.2.0"
import "npm:react-dom@18.2.0" |
@bartlomieju can you explain what the benefit of running Vite on deno is? Does Vite end up using the same resolution methods as Deno? Can we use VS code to edit both the front and backend code both with the deno language service and have everything work the same? |
I'm not sure there's any particular benefit for using Deno over Node to run Vite. It is a quite complex project, which was a great testing ground for our Node compatibility which helped us uncover many bugs. But for Deno users being able to run Vite opens a whole frontend ecosystem and makes it more accessible.
Currently not, but now that you can run Vite in Deno I see no reason why it wouldn't do so in the future.
Yes, although Deno's LSP is still missing support for |
Deno v1.25.4 makes it much easier to run Vite in Deno, here's an example repo that you can give a try: https://github.com/bartlomieju/vite-deno-example Keep in mind that for now we focused our efforts on the Vue template, so expect some bugs in other templates, but we're getting there! Feedback and bug reports are much appreciated so keep them coming. Huge thanks to @dsherret for all the work that made it possible. |
Hey @bartlomieju Great work so far! Have been watching this closely. I cloned the example repo and ran PS C:\Users\rekke\Documents\vite-deno-example> deno task dev
Warning deno task is unstable and may drastically change in the future
Task dev deno run -A --unstable --node-modules-dir npm:vite
error: A required privilege is not held by the client. (os error 1314), symlink 'C:\Users\rekke\Documents\vite-deno-example\node_modules\.deno\esbuild-freebsd-arm64@0.15.8\node_modules\esbuild-freebsd-arm64' -> 'C:\Users\rekke\Documents\vite-deno-example\node_modules\.deno\esbuild@0.15.8\node_modules\esbuild-freebsd-arm64' Was that a me thing or an almost there thing? |
I believe your user account needs additional privileges at the operating system level to create symlinks on Windows. |
Ah, perfect. thank you will look into it. |
|
I have 5 systems I've been doing Deno development/testing on. After upgrading Deno to 1.32.4, two of the systems (one Mac OS, one Windows 11) suddenly started getting timeouts using WebSockets (which my app depends on heavily). My code has been working reliably for almost 2 years, through numerous Deno upgrades, without a hiccup. After downgrading back to 1.32.2 (the last version I had been using, since I skipped 1.32.3), both previously failing systems started working again. I just ran into this problem today, so I haven't had any time to look at what's happening with the WebSocket code yet, but when I googled the problem, I immediately ran across this thread, so I thought I'd mention that there does seem to be some kind of a breaking change to WebSocket related code in 1.32.4. I plan on looking into my code as soon as I have time, but since I haven't changed any socket related code in over a year, I'm hoping that the issue can be addressed on the Deno side soon. I'll post any additional details as I find them. The symptom is just a timeout error on the browser side, and no other exceptions thrown on either side as far as I can tell. |
@bartlomieju Above issue in |
Same issue when trying to use Vite+VanillaJS.
Error doesn't appear initially, but on first load via the browser it 'crashes'. However no errors appear until you stop the process in the terminal. |
@bartlomieju this means websockets are broken on deno, right? |
The WebSocket issue will be fixed before the next release. We completely switched the HTTP server implementation which will be more robust than the previous server. Sorry for inconvenience folks. |
The WebSocket issue will be fixed by #18865 and will be included in Deno v1.33. |
@bartlomieju I receive this error on Deno |
@Peyman-Borhani It's working with deno |
While I'm working with Vite, sometimes I randomly get this error message
|
@fernandolguevara could you provide any pointers how you triggered that panic? CC @mmastrac please take a look |
@fernandolguevara Would you mind running your project with |
|
@fernandolguevara thanks for the stack trace, that was very helpful. Working on the bug in #19154 - closing this issue for now in favour of #19058 that will track the follow-up. |
Fixes for various `Attemped to access invalid request` bugs (#19058, #15427, #17213). We did not wait for both a drop event and a completion event before removing items from the slab table. This ensures that we do so. In addition, the slab methods are refactored out into `slab.rs` for maintainability.
Fixes for various `Attemped to access invalid request` bugs (#19058, #15427, #17213). We did not wait for both a drop event and a completion event before removing items from the slab table. This ensures that we do so. In addition, the slab methods are refactored out into `slab.rs` for maintainability.
When running I noticed that Bun for now has a --bun flag specifically to make sure that Vite isn't using node under the hood, but I don't know what is the case for deno. |
As far as I know Vite will run fully in Deno. |
Using the Astro CLI (when running starlight, in particular) seems to break under deno, since import.meta is undefined when trying to access import.meta.env here. Is there something specific the starlight team needs to take into account? Or perhaps this might be a deno bug? |
I don't think it always does, I'm getting import errors, same as with bun (without Like this:
Indicating that it is not using deno, because deno knows how to import from jsr. Update It might be that vinxi, that is now popular way to run vite's dev server doesn't support deno 😢 |
Vite is a bundler, no matter if you run in with node, deno or bun, if vite doesn't understand how to resolve imports it won't work. Here es the deno vite resolver for jsr imports https://github.com/denoland/deno-vite-plugin |
Problem is that vite doesn't support JSR imports, it just appears as same kind of error as bun without |
Does the deno resolver doesn't work for you? https://github.com/denoland/deno-vite-plugin |
I tried with the deno vite plugin with a Vinxi project shared with @Ciantic and It did not worked, there is an issue to track tho |
Is supporting Vite on Deno's radar?
Although many Node.js libraries already work with Deno, Vite is a whole different beast and probably needs changes on Deno's side.
Note that it's not only about supporting Vite, but also its entire ecosystem (SvelteKit, vite-plugin-ssr, etc.).
FYI Bun is working on supporting Vite: oven-sh/bun#250 (comment).
The text was updated successfully, but these errors were encountered: