Last updated February 1, 2022
RedwoodJS is very close to a stable version 1.0. Over the last two years, the project has matured significantly and is already used in production by a number of startups. We have released a 1.0 release candidate and plan to release a truly production-ready 1.0 in the first half of 2022. Get excited 🚀
What a v1 release candidate means:
- all core features are complete and
- we are done making breaking changes
During the release candidate cycle, we are completing all remaining tasks necessary to publish the 1.0.0 GA.
If you want to follow along with development, we are updating the "Release" GitHub project board continuously.
More importantly, we need community help to reach 1.0.0. There’s a Triage project board, including an important tab view of Issues that are priorities but need community help.
- 👉 Start here: v1 Help Wanted tab on the Triage Project Board (sorted by difficulty)
There are several contributing docs and references, each covering specific topics. Between the guides and the helpful community Forums and Discord, you'll be up and running in no time:
- 👉 Then go here: Contributing: Overview and Orientation
Heads Up: Outdated Content
The following sections have not been updated since the v1.0.0-rc was released in December 2021.
At this stage of development, when it's so important to keep the finish line in mind, a high-level overview is invaluable. Hence, this roadmap, and these color-coded labels:
- Didn't start
- Figuring it out
- There's a plan
- Making it happen
- Polishing
Not everything will be in v1.0. Even things core to the Redwood dream—like more sides and targets—won't be there. But that's by design: we're trying to be careful about our priorities, both because we want v1.0 to be something special and because if we aren't careful, we'll never get there.
One of the hardest things in open source is saying no, but as we get closer to v1.0, it's increasingly what we'll have to do.
With that said, here's the v1.0 roadmap. If you're interested in contributing to one of these categories, just let us know in the RedwoodJS Forum and we'll be happy to get you set up. With so many corners to finish, we need contributors now more than ever, so even the smallest contribution is appreciated!
Polishing
Accessibility is a first-class concern. We want you to be able to build accessible websites without having to jump through hoops. While accessibility is a broad topic that we plan to keep iterating on, v1.0 will bring you a solid foundation, addressing key concerns, like route announcements and scroll. And the best part is: it's all baked-in.
A common theme leading up to v1.0 will be that we want to make sure what we have actually works, so if you're savvy with a screen reader, testing the route announcer on multiple screen readers on multiple browsers would be invaluable feedback!
Polishing
Authentication and authorization are questions Redwood has had answers to since v0.7. Redwood has easy-to-install, sophisticated auth for a variety of providers. There's even role-based access controls (RBACs)! Authentication and authorization are integrated across the whole stack, and when v1.0 rolls around, your Services will be secure by default. For more, see Security.
Making it happen
Redwood depends on a few libraries—namely Prisma—for some of its core functionality. For us to be v1.0, they have to be too. With Prisma recently carrying Migrate and Studio to general availability (GA) to complete the ORM, it's safe to say that they're ready to go. As we transition to Envelop and polish Cells, GraphQL is one of the other core aspects of Redwood that's getting a lot of attention.
Polishing
We want to be able to deploy everywhere and anywhere: serverless, serverful, to the edge—to the world! Much like auth, we've already got a great lineup: Netlify (done), Vercel (done), Render (done), AWS (done), and Google Cloud Run (in the works). We'll always be looking to add more and to support custom deployment strategies.
Making it happen
A major part of Redwood's initial success was it's tutorial. The practice of readable, enjoyable, and comprehensive documentation is something we plan to continue. Getting to v1.0 doesn't mean sacrificing the quality of docs; on the contrary, the more the framework can do, the better the docs have to be.
We welcome any and all contributions, from fixing typos to adding cookbooks!
One thing we plan on doing before v1.0 is moving over to Docusarus to accommodate features like versioning. When we release v1.0, we'll lock the docs in and version from there. The tutorials are over there already, with translations to boot!
Polishing
Generators are part of what makes Redwood a joy. We've made generators more configurable, so you can do things like opt in and out of generating stories and test files, and generate files in TypeScript rather than JavaScript. Look out for another long awaited configuration option: the ability to specify the path—where things get generated.
Polishing
Logging has wiped out almost all of the old-growth Redwoods in California. But that doesn't mean we're not fans of logging here at RedwoodJS. As long as the logging helps you figure out what your app is doing! A production Redwood app will need great logging, so we intend to make it easy to get hooked up.
There's a plan
Can you have great developer ergonomics and performance? We intend to find out.
Bundle size will be important here, so a good place to start is by building with the stats flag (yarn rw build --stats). This will make Redwood bundle with the Webpack Bundle Analyzer.
Polishing
Along with TypeScript, Prerendering was one of our most-requested features. It's been available for some time now; all you have to do is add a single prop to one of your Routes:
<Route path="/" page={HomePage} name="home" prerender />We're not done by any means; there's a lot more features we'll add to Prerendering post v1.0, but for now we're making sure it works and it works well, and that includes any page flashes.
Polishing
We've written our own router for Redwood, and we need to make sure it's competitive with existing routers in the React ecosystem (e.g. React Router, Reach Router). We've taken a stance on desiring a flat routing scheme (vs a nested one) and this currently comes with some performance downsides, some of which we've addressed with Sets. There's a lot of little things for us to polish, so if you're looking to work on something with a smaller scope, the router's a great place to get started.
Polishing
Redwood's component-development workflow starts with Storybook. Being able to develop your components in isolation without ever starting the dev server is a real game-changer. Redwood even generates mock data for your Cells so you can iterate on all of your component states!
Making it happen
Using Redwood's Structure package, we can use the same logic to power both an IDE (i.e. Jamstack IDE) and Redwood itself. Redwood Structure's most common use-case is getting the diagnostics of a complete Redwood project, but being able to programmatically talk about a Redwood project like an AST moves many other amazing things we can't anticipate into the adjacent possible.
Polishing
Redwood makes testing a first-class concern, and maybe even makes it fun? We've integrated testing for both sides, and even wrote a tome telling you how to use it, from the ground-up. We've got a template for Functions in the works, which would all but bring our unit tests to a close. One thing we'd really like to add as a stretch goal is a GitHub Action so you can have CI from the get go!
Making it happen
The TypeScript tracking issue easily has the most reactions of any of our issues and PRs. Bit by bit we've made Redwood more and more TypeScript compliant. @corbt (Kyle Corbitt) even graphed our progress!
Cells were one of the more-recent additions. And some of the things we've got coming, like GraphQL Codegen, are going to be icing on the cake.
Although we want Redwood apps to default to TypeScript, you can still just stick to JS! It's totally up to you. All of our utilities, like generators, support both.