feat(Gatsby Recipes): Initial release

[KyleAMathews]

V0.1 of Gatsby Recipes!

Try it out:

npm install -g gatsby-cli@recipes
npm install gatsby@recipes

Then run in a site one of the (three to date) recipes:

gatsby recipes theme-ui
gatsby recipes jest
gatsby recipes eslint

Lots more to come.

RFC is @ #22610
TODOs tracked at https://github.com/gatsbyjs/gatsby/blob/add-recipes/packages/gatsby/src/recipes/todo.md

[freiksenet]

This is a very big PR that adds lots of functionality. It is not ready to be merged to master in this state.

Key blockers:

• All recipes should never overwrite user's code or configuration. The recipes should check if the thing they are writing/removing are possible without destructive changes and ask for confirmation/fail if they are not.
• Recipe parsing on CLI and then passing a JSON encoded parsed file to server feels off - recipe parsing (or file parsing) should be done on server side
• Using latest React version will break Gatsby for any users that don't use latest React version
• Recipes should be part of a separate package or gatsby-cli, not core Gatsby.
• Recipes must quit after finishing, not wait for Enter
• Server feels like an overkill, especially when we don't see an admin use case. It's hard to review something, where only a part of it's feature set is required. I feel that a better first draft wouldn't use server, but run providers directly. Server can be added at the stage when Gatsby Admin is added.

Some architectural questions/issues:

• Why make a new tool instead of using existing one that does the same? Eg yeoman, schematics (used by angular).
• Why use of MDX? Eg Typescript support is hard with MDX (or generally with this format of files, where you do convention instead of importing)

[freiksenet]

This breaks users that have older version of React. We can't have two versions of react in repository, so ink version of react must match the minimal version of react we support.

[KyleAMathews]

All recipes should never overwrite user's code or configuration. The recipes should check if the thing they are writing/removing are possible without destructive changes and ask for confirmation/fail if they are not.

this is the plan — we've been working out the architecture for the providers & will now be moving towards a model where we tell you what will happen & ask if you want to do it.

Recipe parsing on CLI and then passing a JSON encoded parsed file to server feels off - recipe parsing (or file parsing) should be done on server side

yeah — that's the plan — the first prototype was all in the client & we've been building out the server since.

Using latest React version will break Gatsby for any users that don't use latest React version

confused about this — did we upgrade React somewhere or are we relying on newer features than we support?

Recipes should be part of a separate package or gatsby-cli, not core Gatsby.
💯

Recipes must quit after finishing, not wait for Enter

yeah that makes more sense for a CLI. We're also thinking about different designs that e.g. take you back to a main recipes screen — but since we're in single recipe run mode just exiting is best for now

Server feels like an overkill, especially when we don't see an admin use case. It's hard to review something, where only a part of it's feature set is required. I feel that a better first draft wouldn't use server, but run providers directly. Server can be added at the stage when Gatsby Admin is added.

Admin is going to start using this immediately to drive all their UIs so it seemed important to get it in now. The server is also a very big part of the architecture so it felt important to prototype along with the rest of the structure to make sure it worked.

Why use of MDX? Eg Typescript support is hard with MDX (or generally with this format of files, where you do convention instead of importing)

literate programming is important for making recipes work as tutorials & this will enable us to create an IDE along the lines of Blocks for creating/editing/running recipes

[freiksenet]

confused about this — did we upgrade React somewhere or are we relying on newer features than we support?

You are using hooks - hooks are 16.8.0, our min version is 16.4.2.

[wardpeet]

To emphasize @freiksenet point, it's an issue with npm not handling peer dependencies correctly (#15903).

It seems like we are using hooks now. I've just tested it with npm and older react version and we break 😬. It seems like no one is complaining so maybe we're good? (I don't feel comfortable about it, though)

[johno]

👨‍🍳