Split out providers into sub packages

[zephraph]

Perceived Problem

Shipping providers inside the main package means consumers pay the cost of the dependencies of those providers even if they're not using said provider. For some things it's may not be a big deal, but for dependencies like playwright it absolutely makes a difference.

Ideas / Proposed Solution(s)

Break the library down into a monorepo. Ship providers as stand along packages in a shared scoped namespace on npm. This will allow supporting things like playwright (and beyond) while not incurring the dependency cost for consumers that don't need it. Having it in one repo but published as different packages means the community can also contribute back to the main repo when adding other useful providers without consumers paying the cost of a new provider.

---

The biggest challenge with this specific approach is dripip doesn't seem to support monorepos. Setting up automatic deployments of monorepos is non-trivial. Historically I've leaned heavily into using auto. There is a conventional commits plugin to map to the current usage.

Obviously that's one potentially solution among many. The tool used is less important than the ultimate result.

[jasonkuhrt]

Agreed with this in principal. Not sure when we'll do it. I might also go a slightly different way. A mega package that bundles all deps, the existing kont. For users that care, letting them install @kont/core @kont/provider-foo @kont/provider-bar .... Not sure though, at some point, the providers will be too niche. Need to find a balance.

Not that bad for now. TypeScript is twice that for example.

[jasonkuhrt]

But it does seem to drag down CI install times