Remove DB tools dependence on /api

[Ekrekr]

No description provided.

[BenBirt]

I don't follow the intent of this change. What is it you are actually trying to do? @dataform/api doesn't actually exist.

[Ekrekr]

I don't follow the intent of this change. What is it you are actually trying to do? @dataform/api doesn't actually exist.

Fair point, what I really mean is moving /api inside of /cli now that @dataform/api is not it's own entity.

Aside from this PR, the main change before doing this is that rather than having tests/api which covers functionality of the @dataform/api, we test functionality that is relevant to the CLI. All part of removing dead code and simplifying maintainability.

*To clarify, I don't mean only invoking tests via the CLI and not through the existing API class - more contextualising /api, and potentially restructuring it to simplify how it fits in as part of the CLI rather than its own module

[BenBirt]

I think I still don't really follow.

I think there is almost certainly value in maintaining these library functions (whether called api or whatever) separately from the CLI - not least from a testing perspective.

It's hard to know whether this is a good change without actually knowing what the destination is.

[Ekrekr]

value in maintaining these library functions

This is the bit I'm interested in, could you give some examples? If we're OK with not supporting a packaged javascript client then why not minimise it's exposure to the rest of the repo too?

Note that although the VSCode extension has it as a build dependency, it doesn't actually use /api at all.

[BenBirt]

I guess I think that having a separate layer of code - which doesn't have to concern itself with CLI parsing/parameterization/etc - is just good design; again, in particular, from a testing perspective.

I guess if you are genuinely planning on moving all relevant api tests into cli tests, then I could get on board with it? I'd still think having the separation (at least in some form!) would be better code design, but if you feel strongly about getting rid of it then 🤷

[Ekrekr]

I'm keen to keep the separate layer of code, but in my grand scheme it makes more sense living under the CLI. I should better define this though.

It's hard to know whether this is a good change without actually knowing what the destination is.

I'll do this in a subsequent CL so that later once I think it will be more clear why I think it makes more sense living under the CLI.

I still think this CL PR is a nice bit of clean up without necessarily moving under /cli though:

• Less inter-dependence with a similar number of lines of code.
• This setup is used to test /api, so at the moment we're depending on the code we're testing to set up the test (though I do realise not significantly).