I recently added a tailwind Generator to Redwood. (You can try it out now by upgrading to the latest canary,
yarn rw upgrade -t canary.) It got me thinking about the nature of Generators.
One thing’s no surprise: Redwood loves Generators. There’s one for nearly everything, and that’s probably why I added one for tailwind: why wrangle with a webpack config if you could just punch in a CLI command? It should be that easy (and now it is!). At least, Redwood got me thinking that way.
Looking at all the Generators in Redwood, there’s the routine lot, like Layout, Page, Cell, Component, etc., that crunch boilerplate by handing you a directory stuffed with files. We run them many times as we’re building out our app; they make developing a joy. Then there’s the group like Auth. (And it’s Auth that kicked this all off.) This group is super: they don’t just get rid of boilerplate, but install packages, modify files–whatever it takes to wire up your app, from front to back, Side to Side, Web to API.
Both of these are wins for DX. But are both of these really Generators? It seems like there’s a better way to think about the super group:
You can think of the Auth Generator as setting something up for you. It’s a one-time thing: you run it, specifying your provider, and you’re good to go. So we’re proposing a new entry-point CLI command to match this thinking:
setup. It’d look something like this:
yarn rw setup auth0 yarn rw setup tailwindcss yarn rw setup vercel-deploy
You’d run it just like any other Redwood command. But instead of there being any types (e.g.
yarn rw g page home), there’d be a single namespace: whatever’s after
setup is what’s being setup.
We thought about a dual namespace, where running Setup resembles running a Generator:
yarn rw setup auth auth0
But we decided against it after thinking about the kind of extensibility we’re after. In the future, we’re thinking about providing a Deno-like convenience. That is, just give
setupa URL and it’ll run:
yarn rw setup https://github.com/jtoar/my-custom-redwood-setup/releases/tag/v0.3.0
The steps from here would be:
- Introduce a new CLI command,
setup, as an alternate entry point to Auth, Deploy, and Utils commands.
- Provide a deprecation warning for running Auth, Deploy, and Utils commands via
Let us know what you think!