Type generating CLI

[roncohen]

This is a two part PR with a CLI that generates a package _bucket and updates the browser/react SDK to optionally make use of the _bucket package.

It's a lot of added complexity, so any suggestions on simplifying would be greatly appreciated.

CLI

This introduces a new minimalistic CLI package which can:

• bucket init: writes an almost empty bucket.config.json file
• bucket features add: add a new feature to bucket.config.json and call features generate
• bucket features generate: write the _bucket package out based off of bucket.config.json.

thanks to @Swiftwork for laying the ground work for the CLI!

Browser/React SDK

The goal here has been to keep the option to use both libraries without the generated _bucket package and CLI. There's no way to do try { import ... from "_bucket" } catch {} because there's no runtime importing going on. At compile-time there's a bundler that runs and resolves all the imported packages. If you import a package that imports from "_bucket" and that module doesn't exist, you'll get an error.

So, this introduces two sets of files, for each of the Browser and React SDKs:

• a basic set which contains no reference to generated types but is generic so you can "just" fill in the generated types
• a set which relies on a generated package, tentatively called _bucket. This set imports from the _bucket package and exposes a bunch the same classes/types but with the type arguments filled in.

Example:

• BrowserSDK now has two entry points: @bucketco/browser-sdk and @bucketco/browser-sdk/configuredClient. @bucketco/browser-sdk exposes the generic version of the BucketClient: BucketClient<FeatureDefs> and doesn't use the _bucket package, while @bucketco/browser-sdk/configuredClient exposes a BucketClientConfigured which already has the types from the generated _bucket package inserted along with the list of features (the types get removed at compile time, but since we want the toolbar to show the list of features locally, we also need to include an actual list as opposed to just the types).

Similarly, in the ReactSDK we go on the assumption that people will be using the CLI workflow to generate types and this importing @bucketco/react-sdk will give you a BucketProvider which already has the types and the feature list loaded in from _bucket. It imports @bucketco/browser-sdk/configuredClient which does the hard work. You can still import @bucketco/react/baseBucketProvider to get a vanilla BucketProvider without the types/features loaded in.

Why _bucket

I started out with .bucket but unfortunately rollup refuses to resolve it. It works for Prisma because they rely on Node.js package resolving while we have to deal with bundlers. Other options could be @bucketco/_generated @bucketco/_generated-config or similar

UMD build

Unfortunately, vite doesn't support building a UMD when there are multiple entrypoints. We have multiple entrypoints to allow folks to use the libraries without the generated _bucket package. We can probably work around it if we think it's important.