[EPIC] Extend the CLI with optional DX improvements

[jlengstorf]

NOTE: This issue is an epic, which bundles up lots of related issues into a single goal. If you have the free ZenHub extension, you’ll be able to see overall progress and related issues, as well as a "board view" that shows this epic from a bird's-eye view.

Who will own this?

Responsibility	Contributor(s)
AoR owner	@KyleAMathews
Domain owner	TBD
Project manager	TBD
Tech lead	TBD
Contributors	@jlengstorf

Description

In a few sentences, describe what you want to do and why it is important.

There have been several previous conversations about extending the Gatsby CLI with additional features (e.g. #3900 (comment), #4200 (comment)).

There have been a few ideas on improving the developer experience (DX) of getting started with Gatsby, including a desktop app (#4201) and an updated CLI.

CLI extensions include:

• Post-install scripts for starters, plugins, etc. (see Add postinstall hello script to official starters #4200)
• Improved gatsby new experience via templating (e.g. node-plop)
• Support for creating plugins from starters (e.g. gatsby new plugin)
• Support for a guided setup where the CLI asks for details and can update gatsby-config.js on your behalf.
• Support for opening bug reports including the most recent crash data (env info, stack trace, etc.)
• Support for anonymized usage/crash stats to help maintainers identify issues quickly
• Support for adding plugins to a Gatsby site (e.g. gatsby add gatsby-plugin-helmet) with an interactive option to auto-configure gatsby-config.js

There are probably a thousand other ways that we could make the CLI more powerful — please share your ideas here!

Goals

What are the top 3 goals you want to accomplish with this epic? All goals should be specific, measurable, actionable, realistic, and timebound.

1. Developers should be able to accomplish common tasks directly from the CLI
2. Common workflows should be improved to make the Gatsby workflow even better
3. Ecosystem authors should be able to extend the CLI to make their plugins and starters easier to start with

How will we know this epic is a success?

What changes must we see, or what must be created for us to know the project was a success. How will we know when the project is done? How will we measure success?

• We will see an increase in CLI usage for common dev workflows
• We will see positive feedback from the community about the new CLI
• We will see high adoption of the CLI extension APIs from starter/plugin authors

What are the risks to the epic?

In a few sentences, describe what high-level questions we still need to answer about the project. How could this go wrong? What are the trade-offs? Do we need to close a door to go through this one?

• Expanding the CLI means there will be more maintenance overhead
• If we get this wrong, it could increase friction for developers

What questions do we still need to answer, or what resources do we need?

Is there research to be done? Are there things we don’t know? Are there documents we need access to? Is there contact info we need? Add those questions as bullet points here.

• What changes, if any, need to be made to the existing CLI to make it extendable?
• How much power should we hand over to third-party plugins/starters (e.g. string-based questions only, or more advanced code-moddy stuff)?
• What else can the CLI handle well?
• What shouldn't the CLI try to handle?

[m-allanson]

I'd love to see the output of gatsby develop and gatsby build improved. The existing output has evolved over time in a fairly haphazard way, I'd love to see what it'd look like if we rethough the output from scratch.

One example is the difference between develop and build. develop is generally a long-running process that could be more suited to a dashboard-style output. build is a one-off job that's often run on CI servers, so the output should read sequentially.

The CLI could implement reporters (similar to eslint, webpack, mocha etc) to allow customising the output.

There's some good stuff in https://medium.com/webpack/webpacks-new-cli-hotness-d6a2063168a8

[m-allanson]

Make it easy to find existing issues

Whenever fastlane runs into an unexpected situation, it will not only show similar GitHub issues, but also print out the GitHub search URL. The long-term plan is to also support StackOverflow questions

[jlengstorf]

I'm assigning this over to @KyleAMathews so it shows up on his radar for prioritization. I'd love to build this, but it may not make sense for me to tackle it given the other things we want to accomplish in the community/company backlog. At the very least I'd like to be part of the initial planning, because I've built these before and have some experience to share.

[gatsbot]

Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open!

[gatsbot]

This issue is being closed due to inactivity. Is this a mistake? Please re-open this issue or create a new issue.