generate v0.0.1

[EthanThatOneKid]

This is a large PR intended to resolve EthanThatOneKid/dengen#1.

It consists of a module (mod.ts) and a CLI tool (main.ts).

[NfNitLoop]

Didn't have time to review every line, but the shape of things is good. Good docs, especially on your exported interfaces. 👍

My main questions are about the design:

• Why do I want to put //deno:generate <command> in a TypeScript file instead of just in deno task?
• If I have two files that depend on some generated code, which file do I put the annotation in?

[EthanThatOneKid]

Thanks for taking the time to review, @NfNitLoop! I appreciate your feedback. Allow me to address the main questions.

Why do I want to put //deno:generate <command> in a TypeScript file instead of just in deno task?

Using //deno:generate <command> in a TypeScript file instead of solely relying on deno task offers several advantages. Firstly, incorporating //deno:generate directly into the source code allows for better integration between the generators and the codebase. This approach enables developers to easily understand and manage the generators as an integral part of the project.

Additionally, by utilizing //deno:generate, we can conveniently run multiple generators that are closely tied to the specific TypeScript files. While it's technically feasible to write a deno task that mimics the functionality of a series of //deno:generate commands, this approach may not scale efficiently when the project relies on numerous generators. By placing the //deno:generate directives within the relevant TypeScript files, we achieve a more scalable and flexible solution for managing generator-related tasks.

If two files rely on some generated code, it is recommended to make a shared module from which the two files can import the generated code.

In situations where multiple files depend on the same generated code, it's highly recommended to create a shared module. This shared module serves as a central location from which both files can import the generated code. By doing so, we promote better code organization and encourage code reuse.

The shared module approach also simplifies future modifications and updates. If the generated code needs to be modified or enhanced, we can make the changes in a single place—the shared module—and have the updates reflect in both files that depend on it. This not only reduces code duplication but also improves maintainability by ensuring consistency throughout the project.

I hope this clarifies the benefits of using //deno:generate in TypeScript files and the advantages of employing a shared module when dealing with generated code dependencies. Please let me know if you have any further questions or concerns.