Segmentation fault in a fresh React project if using plugins

[hizkifw]

When I try to create a new Vite project using yarn create vite and selecting React with Typescript + SWC, I can perform yarn build just fine, however when I yarn add -D @swc/plugin-emotion and update my Vite config, the build fails with a segmentation fault.

I also get the same result with @swc/plugin-noop and @swc/plugin-styled-components.

vite.config.ts:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react-swc'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react({
    plugins: [['@swc/plugin-emotion', {}]]
  })],
})

package.json

{
  "name": "testing1234",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives --max-warnings 0",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@swc/plugin-emotion": "^2.5.115",
    "@types/react": "^18.2.43",
    "@types/react-dom": "^18.2.17",
    "@typescript-eslint/eslint-plugin": "^6.14.0",
    "@typescript-eslint/parser": "^6.14.0",
    "@vitejs/plugin-react-swc": "^3.5.0",
    "eslint": "^8.55.0",
    "eslint-plugin-react-hooks": "^4.6.0",
    "eslint-plugin-react-refresh": "^0.4.5",
    "typescript": "^5.2.2",
    "vite": "^5.0.8"
  }
}

Running yarn build gets stuck at this step:

-> % yarn build
yarn run v1.22.21
$ tsc && vite build
vite v5.0.12 building for production...
transforming (1) index.html

After some time, it crashes with SIGSEGV

-> % yarn build
yarn run v1.22.21
$ tsc && vite build
vite v5.0.12 building for production...
error Command failed with signal "SIGSEGV".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I'm running Arch Linux, node v20.9.0.

[ArnaudBarre]

This is probably a regression on SWC. Can you check by using a fixed version of SWC 1.3.104?

[hizkifw]

I've tried upgrading to 1.3.104, 1.3.105, and the latest nightly, and still seeing the same behavior.

yarn add -D @swc/[email protected]

[ikim23]

I have experienced the same issue with the @swc/plugin-styled-components.
Going down to the @swc/[email protected] fixed it for me.

[hizkifw]

Looks like downgrading to @swc/[email protected] fixed it for me as well.

[Codex-]

@swc/plugin-emotion latest is build with the newest swc_core crate. As a result it requires @swc/core@1.3.106

See https://swc.rs/docs/plugin/selecting-swc-core#swc_core

[Codex-]

Looks like the package for the vite swc plugin has been bumped: https://github.com/vitejs/vite-plugin-react-swc/blob/main/package.json#L17 (needs another bump already)

I wonder if it would make sense to have @swc/core as a peer dep instead so it's easier to keep up with the upstream breaking changes

[ArnaudBarre]

Package manager allows to specify an indirect dependency (resolve or something like that).
What I should do is add this plugin to th SWC ecosystem so we have less regressions

Note: While peer dep will be cleaner in theory, the idea of this plugin and the babel one is too keep them close enough so that switching from one to the other is just adding -swc and updating the import the bite config. This is even more important for React meta framework building on top, where they want there users choose between one or the other

[Codex-]

That's reasonable

Consumers of this plugin could also choose to override the @swc/core version too I suppose if they need bleeding edge

[DiFuks]

I encountered a similar problem related to upgrading @swc/core to version 1.3.106. I am developing an external library and cannot force all consumers to specify resolutions in package.json :( It would be nice if @vitejs/plugin-react-swc allowed passing the required version of the swc instance in parameters. As it is done, for example, here.

[ArnaudBarre]

@DiFuks I don't understand your use case, how does your library require to run SWC for consumers?

[DiFuks]

@ArnaudBarre

I'm developing a library-bundler based on Vite, which is used for building frontends within our company. It has the following dependencies:

		"@swc/plugin-styled-components": "1.5.116",
		"@vitejs/plugin-react-swc": "3.5.0",

We use fixed versions specifically because we want to strictly control the package versions to avoid breaking changes. However, since @vitejs/plugin-react-swc uses @swc/core as a dependency with an unfixed version, there can be a situation where @swc/core upgrades its version while the @swc/plugin-styled-components plugin remains outdated. We've solved this issue by specifying the version like this:

-		"@swc/plugin-styled-components": "1.5.116",
+		"@swc/plugin-styled-components": "^1.5.116",
		"@vitejs/plugin-react-swc": "3.5.0",

But, we still want the ability to control the version of @swc/core by passing its instance into the @vitejs/plugin-react-swc plugin.

[ArnaudBarre]

Yeah but in that case you will download two version of SWC. I suppose your template enforce a package manager, and in that case I think using https://docs.npmjs.com/cli/v10/configuring-npm/package-json#overrides or equivalent is a better solution

[DiFuks]

I don't see anything wrong with loading 2 versions of @swc/core - one just won't be used. Library users install it with a simple command yarn add @my-org/frontend-scripts. In this case, they will have to manually add overrides/resolutions to each project (and there are hundreds of them). Even if they do this once, when running yarn up @my-org/frontend-scripts (where, for example, the swc plugin has been updated), they will have to change the version in overrides/resolutions to the one that is currently supported by @my-org/frontend-scripts. That is, I can't control the version at the library level

[ArnaudBarre]

Ok I see. I personally don't advice to use Vite as a library builder. It's in freeze mode. If you still want to build in that direction you can open a feature request with a summary of the need and I can bring this up to a team meeting

[DiFuks]

Perhaps you misunderstood me. We don't use Vite for library builds. It's used as part of our internal library for building Vite-based applications. But alright. I got you - I'll bring up a feature request.