[DRAFT][RFC]: Ejectable Configs

MichaelrMentele commented 2 years ago

Summary

Redwood is an opinionated framework that you can override if you need to. You can swap out auth, you can swap out the graphQL engine etc. but generally you can't swap out configs because they follow a subclass pattern where you merge/override the top level config.

Motivation

Problem #1: It's hard to get the full view of the config since in the case of jest config for example, it's spread across several files

Problem #2: It's difficult to "roll your own" due to the override pattern

As a founder how do I have failsafes / optionality to customize config for:

typescript
babel
webpack
jest

Using the merge/overide file: I can override all the things but then I need to know all the changes from default set in the redwood config which is non-obvious not to mention what if redwood alters that config? The safest way to do this would be to add an override default for every single option (that way you can't accidentally drift).

Who knows why I may want to fiddle with the config. Maybe I need a short term workaround. Maybe I want to optimize it to the max or for my own special usecases. It gives the core team a safety valve.

Unpacking redwood commands: It's worth mentioning that it is possible to override wholesale right now by simply not using the redwood commands. For example you could unpack yarn rw test and run the jest binary directly with node. However this may be unsafe and a maintenance issue because you miss out on any other dependencies or effects of using the "canonical" command.

Detailed proposal

Option A: Eject the config files

redwood should be able to use a different config file wholesale instead of doing a merge with its base config
ideally you can also dump the full config for each concern so that it is reasonable to edit the entire thing

Option B: Dump the full config (could be a milestone towards A)

if we can dump the full config for each concern then we can at least more easily introspect what is happening
worstcase we can at least override as much as we want from the config

Are you interested in working on this?

[ ] I'm interested in working on this

MichaelrMentele commented 2 years ago

This could be a terrible and unnecessary idea. Some downsides could be that is just isn't practical to eject config that is so closely coupled to redwood-isms. For example, special sauce like custom transforms for cells.

pantheredeye commented 2 years ago

I like this concept and I can appreciate the potential someone may have for this need. It led me to this article Ejectable Defaults: Zero Config First, Full Config Later by swyx, which gives an overview of this concept in regards to Gatsby Themes, Next.js and Create-React-App. I have never had to eject config before and have no experience with it. I have basically been in full control of the config with the apps that I have built prior to Redwood. Also, I have not tried to muddle with any of the configs that RW has in-place, so I have no idea what these things currently look like, how many there are, where they are, what they are, etc.

Anyway, from that article:

Bottom Line Up Front: Ejectable Defaults are Great!

One idea I’ve been playing around a lot with is the idea of ejectable defaults. Broadly speaking, this idea leads to a fantastic developer experience for getting build tools going:

your build tool carries internal default files with it, so that you can run it with zero config. Zero config is the best possible initial developer experience.

as you grow, you need more control. you can then choose to eject some of these files to modify them and assume full control. Full config is the best possible subsequent developer experience.

To your second comment, it may be... but, I believe one of the future worlds we could live in is where apps built with RW can continue to track Redwood main versions (maybe not epochs?) while maturing on their own and developing their own needs. In this world, it would be handy for custom configs to play nicely with RW default configs.

However, this may not be truly feasible over the course of years, or epochs. Someone with more experience than I could speak to that. Also, it seems like some early apps, pre v1 did not track with upgrades. This may have been due to the pace/potential of pre v1 breaking changes... or perhaps tracking RW version upgrades becomes a low concern after apps get going in a substantial way.

Either way, digging into config seems like a desirable thing as an app grows, and being able to eject all configs sounds like a very good thing in this regard. 🤷

dac09 commented 2 years ago

I also like this idea - but one of the downsides of "ejecting" is that if there are upstream changes to config in Redwood, upgrading becomes extremely tedious. From the maintainer perspective, how would we know we're not accidentally breaking things between releases?

1) So the first question here is, what would you like to eject?

and

2) Is there another pattern we could adopt instead of just dumping config files into your project?

redwoodjs / redwood