I tried searching and didn’t find much in the way of discussion on next gen build tooling, so I thought I would give it a go.
It’s common knowledge now that the newest gen of build tools that leverage projects like SWC and esbuild are changing expectations surrounding build times, dev tooling, and the like. From what I can gather on Discord channel, it looks like esbuild is already in the Redwood ecosystem as part of the core package, which makes sense because builds and dev updates appear to run pretty quick.
I’m hitting a pain point in testing though, and I’m sure I’m not alone in this regard. I know Jest was chosen for it’s ubiquity and the fact that it’s feature complete. In anything more that just the tutorial app I’m seeing really long test runs, even in watch mode without the “all” option. the idea of Red, Green, Refactor isn’t something I’m able to work with because of this - I can’t maintain focus and dev velocity and spend more time staring at the terminal than I would like. I’m sure I’m not the only one experiencing this.
I also gathered that some work has been done by the core team to assess possible usage of other build tools. For me, Vite has been amazing to use and bringing it into the Redwood ecosystem appears to be a good fit, but I think the greatest gain for me would be in adopting Vitest in place of Jest. I’ve seen significant speedups in the dev feedback loop which allows the TDD cycle mentioned above, but since Redwood is so “batteries included” I’m not sure how to go about switching between Jest and Vitest. The API’s between the tools are nearly identical, so porting over should me relatively simple, but I haven’t had a chance to do a deep dive and see exactly how Redwood encompasses the functionality from Jest.
I’d love to hear some opinions from others and even see a discussion form surrounding the issue. What experiences are other having? What thoughts do others have regarding switching over? Is anyone aware of technical limitations that would prevent a migration from occuring?
You are correct that some investigation has been made into using other build tools. And now that RW v1 (and v2) are out, this is something we’ve just started looking into again. (And Vite is looking really good right now). So I’m guessing this is the first thing you’ll hear more about. And if we indeed do go with Vite, it sounds like Vitest would be the next logical step @danny might be able to fill in with more details
Not right now unfortunately. But I can give a short update
We’re integrating Vite as part of our effort to enable SSR, and that is a big undertaking!
Core team member Danny has done a tremendous amount of work getting us to a working proof-of-concept implementation
Next step is for Danny to walk the rest of the core team through his code/findings to bring us all up to speed. We’re trying to schedule a meeting for this in the next few weeks
After that we’ll divide up the work among interested parties in the core team and work together to ship SSR to our users
We’ll need the community’s help in shaping and testing this feature. So we’ll try to get some discussion going either here on the forums or in an issue/pr on GitHub. And especially get beta-/RC-releases out for you all to play with.
One integral part of our SSR support is going to be the ability to server-side render Cells. For that we hope to leverage the work I’m doing in #5600. That PR is ready to be merged, just pending a naming decision. This naming decision might impact our SSR implementation too.
Danny talked about the process of adding SSR support to the framework (including Vite) here
(First half of the video is a great presentation/demo of our Storybook integration that I can also recommend that you watch, but the second half is what’s relevant to this discussion. I tried to link straight to that part)
