@jlengstorf if you have some time, could you check this out and chime in on any of the questions! I think this could be some nice functionality for debugging, helping people, etc.

Per @pieh perhaps tarball the .cache directory so we can investigate further.

Send this off to a REST API (or something) that we're in control of

Are we adding the snapshot functionality here?

@KyleAMathews I didn't add it, because I didn't know where it should go, whether we have an API in place, etc. I think the functionality is worth introducing regardless, but it'd be helpful to have some debug info to help us troubleshoot things in the future, so I'm open to releasing it as is or building in some type of API call.

My vote would be to release this and add a follow-up issue to design the API for sending snapshots on clean. Maybe we can add that to the new GraphQL API I just launched? See gatsbyjs/api.gatsbyjs.org#11 for the new code; we could add a mutation in there to accept the snapshot and log it somewhere.

@pieh you wanna give this a once over and maybe we can get this merged today?

@pieh this is ready now. For those following along, this PR will:

• Provide a gatsby clean command, which will wipe out public/, .cache, and node_modules
  • This command has arguments, e.g. --no-install, --env-info, etc. which do what their name implies
• This does not add in any reporting/analysis/snapshot to this command currently, so I'm OK to leave this mostly undocumented for now (README is fine!)
• Updates the envinfo functionality to default to markdown format

Going to hold off on merging this until at least tomorrow to iron out some potential issues with Gatsby v1/v2, e.g. the info command not being present in the current version of gatsby that the CLI is being used with and several other issues.

@wardpeet want to give this another once over? I scaled it back quite a bit--think it's ready and generally applicable now.

@marcysutton I'll look at docs to see how to best document this feature (troubleshooting?) but let me know if you have any ideas.

Just wanted to voice my support for @wardpeet 's comment above re: separating wiping .cache/public from also wiping node_modules. I've often needed to delete .cache (e.g. when messing with webpack config, gatsby-node.js, etc.) but I've never had to delete node_modules.

I think building a command into Gatsby that wipes Gatsby's state (.cache, public) makes a lot of sense. Building a command into Gatsby that wipes someone else's (npm/yarn's) state feels... less clean?

@rgiese that behavior you describe is exactly how it works :)

I reverted the node_modules deletion in 32a952b

@DSchau for docs the "Debugging" section seems like a logical place. But I'm wondering if maybe the section should be renamed "Troubleshooting Gatsby" so we can add things like gatsby clean in there and make it sound less like Gatsby is full of bugs and more about troubleshooting project state. @shannonbux do you have any opinions on a section rename? Or is there a better spot for it? https://www.gatsbyjs.org/docs/debugging/

@marcysutton I don't have an opinion; I would just call it whatever seems like the most common / understandable way developers describe the tasks involved in the section. The reason we called it debugging was mostly because other platforms have a "debugging" section, so it is standard (doesn't mean it's the best name, though :)

Here are relevant blog posts about where the current organization of the docs came from:
https://www.gatsbyjs.org/blog/2018-06-26-card-sort-results/
https://www.gatsbyjs.org/blog/2018-07-31-docs-redesign/

@shannonbux @marcysutton see f24aa24. Happy to make any changes, I put it together pretty quickly.

Successfully published:

• [email protected]
• [email protected]