Post-v1 Roadmap: feedback wanted

Get Involved Contributing
62

Sharing code between API & web would be easy to do with support for a mono repo tool like Nx.

63

actually always wanted to suggest this, but maybe this fails to capture the “iterate fast” nature of redwood (since now there’s 2 whole languages)

but honestly, I think having a speedy cli would far outweight this (same way I’m begging for a rust node pm)

64

Isn’t this possible with modules? iirc you can just yarn rw g module <name> and it makes a common package Nope, that’s Nest

65

Hello. I’ve been considering using Redwood to bootstrap a project for a vc-backed product.

Love Redwood’s stack, tooling, and opinions. I think tRPC would be a wonderful addition. I will spend some time over the next few days to integrate tRPC in a scaffolded Redwood project. Is there already someone working on this that I can chat with? If not, perhaps I can contribute this option to Redwood if my efforts are successful.

1 Like
66

Hey @hankedori! The lead maintainer of tRPC @KATT is actually here on the forums and I’ve been chatting with him about next steps for tRPC integration with Redwood.

I’m happy to hear you’re interested cause I think we’ll definitely need some help from the community to make it happen. Are you already in the tRPC Discord?

We’re currently working through the new tRPC release which will provide a stable foundation for future collaboration with Redwood.

67

Wonderful! I’ll join the discord and continue the conversation there. Thank you for all the great work.

68

Being a bit late to the party in post-v2 times, but here comes my personal RWJS wishlist here anyway:

  • React 18
    • showstopper to upgrade to Chakra UI 2, really unfortunate as v1.x doesn’t receive patch releases anymore (fixes don’t even get merged in v1 branch)
  • provide a yarn option to create new project with nmMode: hardlinks-global (or make it the default – see discussion in #5011 and linked articles))
    • otherwise, every new project takes up ~0.8 GB more disk space than it would need to
    • currently, only workaround is to create it first, then change .yarnrc, then delete node_modules folder, then yarn install again
  • shared i18n setup (same resource files consumable on both api/web-side, api automatically synced with user-setting in web, and api optionally responding in desired language, i.e. via Accept-Header)
  • dedicated shared code directory (like we already have that for types)
  • Performance, Performance, Performance:
    • keep an eye bun as a future replacement for node runtime,
      ideally enable it as an experimental feature for the hardcore living-on-the-edge folks soon?
    • Startup times on yarn dev & test (can’t do much about prisma & storybook i guess except contribute over there),
      runtime performance of jest as well
    • (awesome to have:) pnpm compatibility (#2907 – compare also #5093)
    • (nice to have:) Preact compatibility (seems like someone already worked on a CLI that would enable that #261) ?
  • Provide an immaculate create-redwood-project experience (unmet dependencies warning #2865, be more resilient to different local environments #4885)

Otherwise, let me reiterate: RedwoodJS is awesome and gets awesome-er by the day! To everyone who built and is building this, give yourself a hug and a hooray at least daily :tada:

2 Likes
69

@ajoslin103 - it seems that we reached a similar level of excitement about the idea of reversible application generation - and a failure of continuing this thread is most likely caused by lack of time (or excitement about too many topics). Let me just remind you that this idea is not to far out in the science fiction area, as @dthyresson hinted before.

If you ever find a spare moment, I am game to start discussing this with more energy.

70

I barely have time to tell you how little time I have !!

I’m still interested in the idea, and haven’t thought of a better idea than up-down generators

What tools are available to us for interpolating the templates?

Is Puppet still your choice for scripting the generators?

71

That does not sound encouraging :wink: - as I only have the time, not too much given my age. My perception of the relative importance of this idea makes me willing to propose to you to just keep your current interest warm enough to care about reading my (yet to be written) ramblings until you can assess whether this idea warrants the creation of a new company (open source, of course).

72

I’m on board for that! I’ve joined companies for less. So we’d be making generators for more than just redwood then?

I don’t consider the idea far-fetched at all.

I am interested in how we would work from templates - I’ve built Templated repositories with interpolated replacements, they stood up well – but weren’t reversible.

I’ve had good success with this module: interpolate-json - npm

And I’ve enviously watched people using the Angular schematics: Angular (as I mentioned before)

I’m interested in your general thoughts on how you would reverse code-mods

Cheers!

Al;

1 Like
73

Would love to have React Native as a new side to RW!

2 Likes
74
  • React 18
    • showstopper to upgrade to Chakra UI 2, really unfortunate as v1.x doesn’t receive patch releases anymore (fixes don’t even get merged in v1 branch)

Work is currently ongoing here: #5881 More help is very welcome

  • provide a yarn option to create new project with nmMode: hardlinks-global (or make it the default – see discussion in #5011 and linked articles))
    • otherwise, every new project takes up ~0.8 GB more disk space than it would need to
    • currently, only workaround is to create it first, then change .yarnrc, then delete node_modules folder, then yarn install again

For anyone who wants this, please add to the discussion taking place in the PR linked above. My personal guess (have not talked to the rest of the team about this) is that a flag specifically for this setting is not going to be added to yarn create redwood-app. But if a single flag that can be used for “all” advanced configuration someone might want to do, that’s something that might get accepted. Similar to the flag we have on yarn rw dev to pass advanced config on to the underlaying webpack dev server (--forward I think we call it)

  • shared i18n setup (same resource files consumable on both api/web-side, api automatically synced with user-setting in web, and api optionally responding in desired language, i.e. via Accept-Header)

Improving the i18n experience is definitely something we want to do. @simoncrypta, @noire.munich and I have a small working-group for this. But it’s been very quiet lately. Unfortunately other things have higher priority for the team right now. There is so much that can be done in this area. Especially around tooling! We’re more than happy for someone from the community to help work on anything i18n related :slight_smile:

  • dedicated shared code directory (like we already have that for types)

Thanks for the +1. This is pretty high up on our TODO list already. And your comment validates our decision to put it there

  • Performance, Performance, Performance:
    • keep an eye bun as a future replacement for node runtime,
      ideally enable it as an experimental feature for the hardcore living-on-the-edge folks soon?

Danny, one of the RW core team members, did some experiments a while ago GitHub - dac09/redwood-bun-try: Trying out Bun.sh with Redwood [Not working yet!] It says “not working” in the title, but he did get very far in the end. It was brought up for discussion again as bun recently got a bit of press spotlight. So we’re very much aware and excited about what’s going on :slight_smile: Our main focus right now however is on getting Vite to work with Redwood. But we’re also going to invite the author of Bun to talk to us.

  • Startup times on yarn dev & test (can’t do much about prisma & storybook i guess except contribute over there),
    runtime performance of jest as well

We’re on it! We’re moving to Vite, which will help a lot. After that I’m guessing vitest isn’t far off :slight_smile:

  • (awesome to have:) pnpm compatibility (#2907 – compare also #5093)

We have a pretty tight relationship with the yarn guys, and now also Nx. So I think we’re staying with yarn for the foreseeable future. But I’m hoping that between all of us we can make something that’s fast enough. I actually watched a yarn conference talk at JSNation in Amsterdam last month and I’m confident in yarn’s speed going forward :slight_smile: If you’re interested this talk is 30 minutes well spent! (It’s going to be available to the public tomorrow, right now it’s only open to conference attendees) Yarn 4 - Modern Package Management by Maël Nison - GitNation

  • (nice to have:) Preact compatibility (seems like someone already worked on a CLI that would enable that #261) ?

@dom’s input on roadmap prio is always spot-on. His last comment in that issue still stands. That said, we’re all real suckers for community contributions. So if someone shows a lot of dedication over a longer period of time we like to support those individuals and try our best to come up with ways for them to get what they want. So if someone did show us a working implementation of preact inside redwood…

  • Provide an immaculate create-redwood-project experience (unmet dependencies warning #2865, be more resilient to different local environments #4885)

I’m 100% on your side here. And not just yarn create redwood-app but also all our generators, setup commands etc. But there’s always the issue of diminishing returns the more you work on this stuff. And prioritizations overall. Should we spend time polishing our CLI tool output, or work on new features/bug fixes. Ideally it’s a bit of both. And again, community involvement goes a long way here :slight_smile:

Otherwise, let me reiterate: RedwoodJS is awesome and gets awesome-er by the day! To everyone who built and is building this, give yourself a hug and a hooray at least daily :tada:

Thank you!

1 Like
75

Mobile support is a very high priority for us. Please add your thoughts to this thread, if you have any

https://community.redwoodjs.com/t/redwoodjs-and-react-native

1 Like
76

I would love to see first party support for

  1. Background jobs
  2. Cron
  3. Prescribed deployment option, or force providers to offer solutions for #1 a #2.

Imo Laravel does this so well. Background jobs and Cron are vital features for a backend application. There are solutions in a serverless environment. I’d love to see first party support for it.

2 Likes
77

Background jobs and Cron are vital features for a backend application

@FullZachDev

Excuse me if I misunderstand, but couldn’t this be achieved with things like Lambda Functions and Postgres Triggers? Watch for a table insert or update and then run a function on AWS or netlify. Maybe the tutorial or docs can expand more on this functionality?

78

Yep! Those are good ideas. The most important part is framework buy in and functionality. Each cloud provider can accomplish it how they want.

From DX point of view, this should all JustWork. I think deployments aren’t there yet too, but devs shouldn’t need to lift a finger to turn this on and have this functionality.

79

Built in playwright tightly coupled with everything, possibly tight story book coupling. Playwright has built in screenshot capabilities. Imagine launching your components in storybook snapping baseline images, and then your tests will always compare against those baseline images. Can run update-snapshots when those baselines need to be updated.

after using every imaginable automation framework possible, playwright is the closest thing to legit selenium overthrower, cypress is too wonky and weird up like can’t handle page re-directs you have to do a weird hack.

1 Like
80

Hi,
I have a datastructure that is polymorphic in nature. But it seems like Prisma is not able to deal with it properly, same as it cant deal with Union and Interface Types. There are lots of unhappy users:

RANT The more our team uses Prisma the more we realise its a well marketed but unfinished product. There are so many basic fundamental features of an ORM that Prisma is missing.

I am wondering if redwood devs are aware of this issue and if alternative ORMs have been discussed?

I can work around this issue, but I am wondering if it limits the scope of what redwood could achieve.

1 Like
81

Update: New Public Roadmap

It’s been a long time coming! We’ve published a new roadmap (along with a number of related announcements and activities). I’m closing this thread in favor of moving discussion to the new post.

Thank you to everyone for your input and ongoing participation in this project! We (the Core Team) are really excited about what’s to come. We hope you’re as inspired as we are!