deno: Cannot use npm package `@vitejs/plugin-react-swc`

Reproduction: https://github.com/brillout/deno_vitejs-plugin-react-swc.

$ deno --version
deno 1.29.1 (release, x86_64-unknown-linux-gnu)
v8 10.9.194.5
typescript 4.9.4

Thanks for your wonderful work on Deno. I’d love the Vite + Deno combo (and provide a vite-plugin-ssr Deno starter).

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 17 (12 by maintainers)

Commits related to this issue

fix(ext/http): Ensure cancelled requests don't crash Deno.serve (#19154) Fixes for various `Attemped to access invalid request` bugs (#19058, #15427, #17213). We did not wait for both a drop even... — committed to denoland/deno by mmastrac a year ago
fix(ext/http): Ensure cancelled requests don't crash Deno.serve (#19154) Fixes for various `Attemped to access invalid request` bugs (#19058, #15427, #17213). We did not wait for both a drop even... — committed to denoland/deno by mmastrac a year ago
fix(napi): properly handle arguments in napi_get_cb_info (#19269) Closes https://github.com/denoland/deno/issues/17213 — committed to denoland/deno by bartlomieju a year ago

Most upvoted comments

We’ve managed to track down the bug here. Will try to fix it tonight.

bartlomieju on May 25, 2023

Thank you for personally addressing this issue @bartlomieju ❤️

danopia on May 29, 2023

This fix hasn’t been released yet. I will be later tonight/tomorrow.

bartlomieju on May 29, 2023

Thanks, that’s very useful. I traced the problem to the call to napi_typeof, which somehow passes an empty pointer as an argument, which is explicitly guarded against. Since it works in Node I assume it’s a problem in another napi_ symbol we have that doesn’t return a proper value.

bartlomieju on May 24, 2023

Sure, here’s a minimal repro of @swc/core crashing:

#!/usr/bin/env -S deno run --allow-env --allow-read --allow-run --allow-ffi
import swc from "npm:@swc/core";
console.log(await swc.transform("export {}"));

> ./repro.ts 
error: Uncaught Error: Failed to convert napi value into rust type `Option<T>`
    at Compiler.<anonymous> (file:///home/dan/.cache/deno/npm/registry.npmjs.org/@swc/core/1.3.59/index.js:216:33)
    at Generator.next (<anonymous>)
    at file:///home/dan/.cache/deno/npm/registry.npmjs.org/@swc/core/1.3.59/index.js:34:71
    at new Promise (<anonymous>)
    at __awaiter (file:///home/dan/.cache/deno/npm/registry.npmjs.org/@swc/core/1.3.59/index.js:30:12)
    at Compiler.transform (file:///home/dan/.cache/deno/npm/registry.npmjs.org/@swc/core/1.3.59/index.js:202:16)
    at Object.transform (file:///home/dan/.cache/deno/npm/registry.npmjs.org/@swc/core/1.3.59/index.js:344:21)
    at file:///home/dan/Code/danopia/repro.ts:3:33

danopia on May 24, 2023

How would you approach it? Internally in Deno we translate CJS code to ESM on the fly, but it’s internal functionality that’s currently not exposed in any way.

I’d make Deno permissive.

For example, a widespread problem is npm packages having invalid ESM imports, e.g. import './foo' instead of import './foo.js', which makes Node.js choke. Another example is packages that ship ESM but don’t have type: "module" in their package.json. Deno should be able to execute npm packages that ship invalid code.

I’d make Deno permissive only for npm packages, while being more strict for user land and Deno packages. In order to foster a Deno ecosystem that is correct.

Sounds good, let me know if there’s anything concrete we can help with here.

I think the number one goal for now is to fix the many problems users encounter because of Node.js.

Together with Vite we have a unique opportunity to own the entire stack while fostering a diverse ecosystem (in contrast to other companies’ tendency to control everything and being ecosystem-unfriendly), enabling folks to inovate like Svelte, Solid, Hydrogen/Preact, etc. Our “only” job being to offer basic tools that work very well. Vite is hitting a limit because there is no communication between the Vite team and the Node.js team (I’m not sure if the Node.js team is intersted in that to begin with).

On my side, let me first show you a prototype of that React framework “Base”. I think you’ll like what you see.

(Base is only a thin wrapper on top of vite-plugin-ssr, which means that improvements also benefits the entire Vite ecosystem.)

Ideally I’ll ship Base with Deno right away. We can then systematically polish Deno to fix problems, most notably the many ESM/CJS issues users are having today. FYI another pet peeve of mine is that errors can be swallowed. That’s a no-go, exceptions should always emit a stack trace. (Although I’m not sure whether it’s a V8 problem that Deno cannot work around.)

I’ve always like Deno, because Deno cares, truly cares.

brillout on Dec 29, 2022