feat: use analyzer to check for compile errors before completing sucessfully

[a-wallen]

Description

Right now if you call dart_frog build with code that doesn't compile, it will still build the project.

Requirements
I am requesting that the default behavior be:

• Compile the project (use analyzer)
• Check if there's compile errors.
• If no compile errors output the project.
• If compile errors, forward them to the command line.

Additional Context
If this is a good idea. I can submit a PR.

[tomarra]

Hi @a-wallen 👋 Thanks for opening up this ticket.

We were able to reproduce this locally so we can move forward with making a fix here. In talking with the team it seems like adding a check during the pre-gen phase of the dart frog prod server brick would be the best place to get this check added in.

If you would be able to take a look at this and open a PR we can work to get it through the merge process. Thanks!

[alestiago]

We could introduce static analysis (as suggested in the issue title “use analyzer”) to the process by running dart analyze before finalising the build process. Doing so might require getting dependencies which is already the case to retrieve the analysis options (if hosted remotely publicly). dart analyze has options (for example, --fatal-infos and --no-fatal-warnings) that might alter if the process should terminate or not. I think we should allow developers to specify what they prefer rather than imposing the options we fit like in the build process.

I’m also unsure if the requirements of this task: “Compile the project and Check if there's compile errors.” are the way to go (or if they are informally referring to static analysis).

There are many different ways a Dart program can be compiled, depending on such the code could be valid or not (usually depending on its portability).

The dart_frog build commands generates a Dockerfile that relies on dart compile exe meaning that it compiles to a “A standalone, architecture-specific executable file containing the source code compiled to machine code and a small Dart runtime.”

If we want to assume the developer would like to compile to a self-contained executable, then we could evaluate its correctness based on the result of compiling into it into such. However, the Dockerfile might be customised.

As soon as the user might want another type of compilation, there would be no way for them to run dart_frog build without having the process terminate unsuccessfully. Hence, this might require introducing ways for users to optionally decide how they would like to compile their dart program or suppress any errors that could originate from the compilation differences.

Having said this, we are currently finalizing the details to support a Dart Frog Plugin System that will enable developers to plug into the generation process. Such effort will most likely help land this suggestion and improve the experience for developers if they wish to customize how dart_frog build and dart_frog dev behave. Therefore, we’ll hold back on this feature until we land the new Dart Frog Plugin System.