[RFC] Support for additional sides

At the moment we have two hard-coded sides to RedwoodJS: api and web. We use these two sides to inform a bunch of branches in the CLI:

• yarn rw dev [side]
• yarn rw build [side]
• yarn rw test [side]

The [side] part can be either api or web, and both when none are defined. My proposal is that we move the concept of “sides” into the configuration @redwoodjs/internal and supply a bunch of default commands that can be overwritten by the user.

As an example:

When you run yarn rw build api the CLI does something like this:

if (side === "api") {
   await execa("cd api; yarn babel")
}

So, instead of hard-coding that value into the CLI we’re just move it into a configuration option, by default we’ll have something like this (this will not be visible to the user):

// sides.config.js
export const api  = {
    path: './api',
    distPath: './api/dist/',
    commands: {
        build: "yarn babel",
    },
}

Now, the CLI will grab the sides configuration and determine if the “build” command supports and api side during runtime.

This will allow us, and others, to easily expand the concept of sides.

[viperfx]

I have an additional use case for this feature. I am doing some funky stuff with the router to accept routes via a wildcard subdomain and an “app” domain.

const Routes = () => {
  const subdomain = useSubdomain()

  if (subdomain == "app") {
    return (
      <Router>
        .... admin app routes on app.domain.com
      </Router>
    )
  }else{
    return (
      <Router>
        .... portal app routes on *.domain.com
      </Router>
    )
  }
}

After chatting with @Tobbe about my use case and showing him some issues I’ve noticed with the router and multiple flashes on render, he suspected it may be due to the way I set up the router.

So this seems like a great solution for this, where I would be able to have two web sides.

[tubbo]

Shared code amongst sides, for which we currently don’t have a solution. Should we… could this be one of the supported sides?

The create-redwood-app CLI generates a package.json that configures the app’s workspaces to be api, web, and packages/*. I’m not sure if people already use this directory for anything, but I always saw that packages directory as a future convention for shared code amongst sides. You could maybe consider all workspaces to be a “side”, except the ones in packages/, and use each side workspace’s package.json scripts for those redwood CLI subcommands.