feat: add an internal for now studio package

[Princesseuh]

Changes

In the future, Astro Studio will include more features than just DB, as such some of the more internal parts around handling tokens and env need to be elsewhere than the DB package. This PR adds a new @astrojs/studio package that only contains those parts.

In the future, this package could become the "core" Studio package and then we'll have a astro studio command and stuff, but for now, it's just code moved around

Testing

DB tests should still pass!

Docs

N/A for now.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0cf5276

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bholmesdev]

Seems like we're being conservative with the code we're splitting out, so nothing I'd block on. I'd definitely expect the URL consts like studio.astro.build to be pulled to @packages/studio though. Any reason to leave them in @packages/db?

[Princesseuh]

Seems like we're being conservative with the code we're splitting out, so nothing I'd block on. I'd definitely expect the URL consts like studio.astro.build to be pulled to @packages/studio though. Any reason to leave them in @packages/db?

Fixed this! I left the ones that are only relevant for db in the db package for now, but moved everything else

[Fryuni]

Uhuuul, thanks guys!! This removes the need for some very hacky workarounds to use DB connection inside of integration hooks.

[bholmesdev]

This is a good first step! I'll admit I'm still worried the line between studio and db will be hard to draw. For example, what about the remote db client? Do we expect users to generically connect to a db over http, or is this studio-specific? I know it contains code that expects specific response values.Same goes for the db push CLI, which has specific payload shapes to send over http.

[Princesseuh]

This is a good first step! I'll admit I'm still worried the line between studio and db will be hard to draw. For example, what about the remote db client? Do we expect users to generically connect to a db over http, or is this studio-specific? I know it contains code that expects specific response values.Same goes for the db push CLI, which has specific payload shapes to send over http.

Yeah, fwiw right now this is only really to make things easier for us to re-use the code for future work. Users using any of this are in On Their Own:tm:

[Fryuni]

Users using any of this are in On Their Own™️

The bleeding edge is not called that for nothing! We always get cut when doing epic things.