vitejs / vite-plugin-react-swc

Speed up your Vite dev server with SWC
MIT License
834 stars 54 forks source link

Allow passing swc plugins #17

Closed beaumontjonathan closed 1 year ago

beaumontjonathan commented 1 year ago

Congrats on the Vite 4 release & stability of this plugin!

I tried to convert a React/Relay project of mine over to use this, but ran into a few issues. I'm using the Relay Babel plugin which performs a couple of compile time substitutions. There's an almost compatible SWC plugin (https://github.com/swc-project/plugins/pull/122), but @vitejs/plugin-react-swc doesn't currently support passing plugins down to SWC.

This PR experimentalJscConfig plugin prop.

There's an existing issue https://github.com/vitejs/vite-plugin-react-swc/issues/16 about supporting SWC configuration. My understanding is this should also allow using the plugin during the build phase and therefore has a wider scope, meanwhile this PR may unblock some from using this plugin who rely on plugins which already have an SWC counterpart & can take the hit of using a different plugin for build.

E.g., my config looks like

import path from "node:path";
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";
import relayBabel from "vite-plugin-relay";

export default defineConfig(({ command }) => ({
  server: {
    port: 4000,
    host: "127.0.0.1"
  },
  plugins: command === 'serve'
    ? [react({
      experimentalJscConfig: {
        plugins: [[
          '@swc/plugin-relay',
          {
            language: "typescript",
            schema: path.resolve(__dirname, '..', 'graphql-server', 'schema.graphql'),
            rootDir: __dirname,
            src: "src",
            eagerEsModules: true,
            artifactDirectory: path.resolve(__dirname, 'src', '__generated__'),
          },
        ]]
      }
    })]
    : [react(), relayBabel],
}));
ArnaudBarre commented 1 year ago

Thanks for the carefully crafted PR.

I know that there is some possibilities to configure SWC that would not require to make it work a build time, but this would make it difficult to use for many people, will require multiple checks and maybe various config options.

I really want to first get feedback on what people need to configure to avoid adding too many options to soon and be blocked when I want to add some caching.

Do you know if plugin configuration is possible via .swcrc config file? (Just to know, this would not work either for now)

As you addition is very few lines, I think you won't run into many trouble using the plugin with a patch for now.

I can't promise anything, but I think I can fix #16 in the coming month.

beaumontjonathan commented 1 year ago

@ArnaudBarre

Thanks for the response. That's an entirely reasonable choice, respecting the .swcrc file seems like the way to go, and the ability to use SWC for build would be great too.

Do you know if plugin configuration is possible via .swcrc config file? (Just to know, this would not work either for now)

Yes, this is how SWC plugins are configured docs


Can I provide some small input for any work on #16

It would be awesome if the API for this plugin reflected the API for @vite/plugin-react - this includes several options from where the Babel config should be read from (i.e., .babelrc vs. babel.config.js) AND allows inline config object with the presets & plugins fields.

Screenshot 2022-12-13 at 12 19 36

I find this great because there are some situations where I'd like the Vite to use an existing .babelrc file which I'm using for other build tools, and other situations where I'm just using the default options and just want to tweak it for Vite & don't want to include another whole config file.

A new issue https://github.com/vitejs/vite-plugin-react-swc/issues/22 includes a code snippet which would only be possible if this plugin provided a way to configure SWC inline in the Vite config (rather than respecting .swc)

I'm very interested in seeing this completed, so am happy to help with anything on this :smile:

ArnaudBarre commented 1 year ago

I'm still unsure of the API, but I would probably allow both using .swrrc and inline config.

We will not provide as many options as the Babel one. The goal is also to encourage people to use more standard setup so that we can move faster in the future and do not need to fix bugs due to configuration edge cases.

Thanks for your input, you can subscribe to #16, I would post there when I wave a beta version working, it would be great if people can test it before making it stable.

If you have more usecases need about this, don't hesitate to comment there also.

ArnaudBarre commented 1 year ago

Hey 👋

Happy to have feedback on the beta release: 3.1.0-beta.2