Good idea :).
Some notes here:

• Diagnostics isn't catching all potential errors. So no diagnostics doesn't mean that everything is ok. It just means that the few tests that we have added so far are passing. This should be captured in the wording so developers don't end up with a faulty mental model, banging their head against the wall
• There are errors that are reported by other tools (like the TS compiler, the prisma toolchain, etc). We could also call into those tools and report their errors during the diagnostics check.

When thinking about where and when the checks should happen, consider the following:

• When using an IDE (or even webpack), tools like TSC will talk directly to the host (they already report errors somehow, regardless of the structure package). This means that we shouldn't expose those errors as part of the structure package (in other words, it would be wrong if, when running structure, it would also run TSC internally). So instead of adding TSC to the structure package, just make sure that the CLI code for redwood diagnostics calls it.

Visually, we could group errors by categories. For example:

$ rw diagnostics

summary:
- 4 redwood structure errors
- 7 typescript compilation errors
- 2 prisma errors

redwood structure errors:
- You cannot add foo to bar (Routes.js:34)
- ...

typescript compilation errors:
- cannot find name "myVariable" - (foo.ts:33)
- ...

prisma errors:
- ...

Maybe rw diagnostics could take options. So, for example, '$rw diagnostics --full` would try to cycle through all the tools, including eslint.

There are errors that are reported by other tools (like the TS compiler, the prisma toolchain, etc). We could also call into those tools and report their errors during the diagnostics check.

^^ I really like this. And it feels on target with the RW v1 goal of consolidating error messaging. If we do rename the CLI command to check, then a specific category of checks could be "Diagnostics". It could default to running ALL checks or running a specific check e.g.

• yarn rw check runs all
• yarn rw check diagnostics prisma runs only diagnostics and prisma (not TS per your example above)

For the Output, I like the idea of a Summary. Assuming we start with output for each check/step that's run, I could see the Summary grouping a bit tighter, e.g.:

$ rw check
... 
[task output]
[task output]
etc
...

SUMMARY
- **Redwood Core Diagnostics** [2 Warnings, 1 Error]
  - _warning_: Your env vars are missing
  - _warning_: Name your queries
  - _error_: missing redwood.toml
- **Typescript** [1 Warning]
  - _warning_: gratuitous use of 'any'
- **Prisma** [All Good]

@aldonline @thedavidprice I am interested in working on this ticket. Can you clarify if this ticket is just adding the success message when rw check is run and there are no errors triggered? Should the more robust summarization work be done within this ticket or as a separate follow-up ticket?

@M0nica nice! This is very needed.

Can you clarify if this ticket is just adding the success message when rw check is run and there are no errors triggered?

^^ This is definitely still up for discussion. It would be very helpful if you could help outline a plan for this:

• The next step could simply be outputting a "Nothing to see here!" message in case output == null. This is a valuable PR in and of itself.
• I'm not even sure the example I created (above) is possible. Could you help us define a viable, ideal end state?
  • and then we could better prioritize when we want to do it
  • as well as identify the separate parts that could be individual PRs

Should the more robust summarization work be done within this ticket or as a separate follow-up ticket?

^^ I'd vote we organize here in this Issue, including the work on the next-step PR. The conversation will naturally move over to the PR, at which time we can create a new tracking Issue for next steps (if applicable). When the next-step PR is merged, this Issue can be closed and we'll have the new Issue open.

Making sense? Ideas/suggestions about improving this or other options?

I think implementing these enhancements could be implemented between four tickets (1) improve the success state by making it more clear, 2) reformatting the CLI output, and 3 + 4)enhancing the diagnostics to include Prisma and TypeScript checks which could be worked on concurrently).

1. updating the check/diagnostics CLI to output something along the lines of "Nothing to see here!" when there are no warnings or errors.
2. update and reformat the current CLI output to have Redwood Core Diagnostics and then print out the individual warnings/errors. I am assuming GraphQL - but not necessarily Prisma, environment, routes, router, SDL files, service functions, TOML, the existing diagnostics in redwood/redwood all would fall under Redwood Core Diagnostics.

$ rw check
... 
[task output]
[task output]
etc
...

SUMMARY
- **Redwood Core Diagnostics** [2 Warnings, 1 Error]
  - _warning_: Your env vars are missing
  - _warning_: Name your queries
  - _error_: missing redwood.toml

3. Update check/diagnostics CLI to integrate with TSC and output any of those errors. Would we want to also allow TSC warnings to print in addition to errors and or for the level that outputs to be configurable by the user?

$ rw check
... 
[task output]
[task output]
etc
...

SUMMARY
- **Redwood Core Diagnostics** [2 Warnings, 1 Error]
  - _warning_: Your env vars are missing
  - _warning_: Name your queries
  - _error_: missing redwood.toml
- **Typescript** [1 Warning]
  - _warning_: gratuitous use of 'any'

4. Update check/diagnostics CLI to integrate with Prisma linting (I am not sure how straightforward this type of integration is 🤔)

... 
[task output]
[task output]
etc
...

SUMMARY
- **Redwood Core Diagnostics** [2 Warnings, 1 Error]
  - _warning_: Your env vars are missing
  - _warning_: Name your queries
  - _error_: missing redwood.toml
- **Prisma** [All Good]

Hi @M0nica Huge thanks for moving this forward! I'll comment on plan items 2 - 4 in a next reply.

For now, I'd say go ahead with Step 1 (from above):

updating the check/diagnostics CLI to output something along the lines of "Nothing to see here!" when there are no warnings or errors.

This would be soooo helpful 😆

Looping in @aldonline for thoughts on proposed plan items 2 - 4 (above).

2. update and reformat the current CLI output to have Redwood Core Diagnostics and then print out the individual warnings/errors. ... the existing diagnostics in redwood/redwood all would fall under Redwood Core Diagnostics

^^ yes, I believe your understanding is correct — just focus on the diagnostics coming directly from the structure package. The current Catch 22 is that there is not a lot of diagnostic coverage yet because people don't actually know about this tool and are not yet using the VS Code extension. Once usage goes up, the kinds and quantities of diagnostics will go up. It's likely that over time there will be a natural grouping/categorization within the Core Diagnostics that emerges over time. But not yet.

In summary, I think you've outlined an appropriate approach to step 2.

3. Update check/diagnostics CLI to integrate with TSC and output any of those errors.

I'll defer to @aldonline on specifics here as I'm not familiar enough with TSC checks. Now looking more closely, I’m wondering if it even makes sense to include TSC check along with RW Diagnostics? This feels a bit redundant to me in case of using an editor like VS Code, which will do similar checking.

Also, there a future plans to include this Diagnostics check in a GH Action workflow for Redwood Project CI. The CI will also separately run Build and Lint — maybe that's the right place to run TSC, which could also be easily removed from the runner if not needed? 🤔

4. Update check/diagnostics CLI to integrate with Prisma linting

^^ Similar thoughts on my part here as for number 3. Also, not all Redwood projects will use Prisma (or have an API). So just not sure if it's necessary.

Two quick ideas after seeing #1405

• Verbose option: it could be beneficial if users could pass --verbose to see all the check being run. Maybe?
• --help link to Structure package README: for most commands, if you view help content there's a link to the docs. (See screenshot for info --help below.) There's no doc for diagnostics. @aldonline do you see any benefit in directing people to the Structure package README — possibly for suggesting diagnostics via new Issues, examining the current diagnostics, contributing... ?

I think the --verbose option would be helpful for folks who are looking for more visibility into what types of diagnostics are being run. From what I am seeing the current diagnostic checks maybe we could repurpose the text that is being output in the err field 🤔 for example: yield err( this.path_literal_node!, "The 'Not Found' page cannot have a path" ) or were you thinking less granular? I am curious how substantial of a refactor implementing a verbose option will be.

for example: yield err( this.path_literal_node!, "The 'Not Found' page cannot have a path" ) or were you thinking less granular?

^^ I was thinking to just output it all and see what indeed comes out, firehose style. Given your example, it would probably need a prefix to indicate it's just the step and not the result. Like Checking: ${this.path_literal_node!} The 'Not Found' page cannot have a path.

I didn't look at the code before adding this idea. If this requires refactoring, I'm not sure it's of high enough value. (Although there are not too many checks yet, correct?)

Right now the structure for the diagnostic checks (at least for /routes) is such that if the condition is met that causes a check to fail then an error is thrown with a string like yield err( this.path_literal_node!, "The 'Not Found' page cannot have a path" ) so my understanding is that being able to render information about checks before they fail would require a refactor as the checks aren't explicitly named and the part of the code with the descriptive string is only encountered when a check fails and an error is thrown.

Ah, very helpful. And in that case, I'd vote to put this idea in the proverbial hopper for now.

Thanks!