feat: move code to dart_frog_gen

[renancaraujo]

tl;dr

This is a proposal for a major refactor on how code is organized within the Dart Frog tooling with the goal of promoting greater composability.

The problem

One can identify Dart Frog as not only. package, but an SDK composed for the runtime package (dart_frog), its companion first-party packages (dart_frog auth and dart_frog_websocket, for instance), and most importantly, its tooling, which is the subject of this proposal.

The Dart Frog tooling has its own elements of composition, with two major frontends, the VS Code extension and the dart_frog_cli.

As the backend for the tooling, there is dart_frog_gen, which is responsible for reading the file system under a project's routes and generating a route config from it.

The problem is that we are under-using dart_frog_gen and overusing dart_frog_cli to include all the code generation algorithms.

In the following excalidraw, we can see the current situation:

.

First and third-party tooling has to depend on the CLI (as a library) to access features such as:

• Daemon messages structure (Affects use cases such as #1013)
• Dev server runner
• Route config watching

The proposed solution

Move the backend code to dart_frog_gen.

This would require the gen package to include the following features:

• dev server runner
• runtime compatibility checks
• daemon protocol

Gains

This enables the creation of packages to depend on dart_frog_gen directly without having to rely on the user-installed CLI. Examples of issues that would be facilitated by this:

• A client package for the daemon
• #474
• #152