Extended Toolchain

[wperron]

Related to #8664 and a discussion on Discord https://discord.com/channels/684898665143206084/684911491035430919/807241638543753267

I want to open up the discussion about the tooling included in the cli; does it make sense to put every tool in the cli? should we put some of them in std? should we have an "extended toolchain" similar to Golang's tools?

I think at some point it would make sense to include the tools that are used 80% of the time in the cli, and the tools that are used for the remaining 20%, and that are more decoupled from the core in a set of curated tools officially supported. Whether that's in the deno.land/std or another directory like deno.land/tools I'm not sure.

Should those tools have a special treatment from the cli, for example through a deno tool subcommand is another thing to consider.

[ghost]

Personally, I find more consistent and transparent that every option available on the CLI should also be available programmatically in code. So the idea to decouple the tooling from the CLI in a std/tools repo makes sense to me.

After all, deno is firstly a scripting runtime and secondarily a CLI interface, so every CLI feature should have its own programmatic counterpart, made optional to compilation by moving them into separate tools or std modules.