RFC: Deprecate @faustwp/blocks and introduce CLI tool to scaffold blocks

[jasonbahl]

Problem

The @faustwp/blocks package currently provides components and associated queries for blocks and allows users to import these components and queries for use within their pages.

The problem with this approach is that the queries and components live within a remote NPM package and when the GraphQL schema changes (i.e. when WordPress 6.3 changed attribute names on blocks, or anything else causes the schema to change) users are stuck waiting for the remote package to see an update.

Proposal

Instead of installing @faustwp/blocks as a dependency, I think it would be nice to offer a CLI tool for users to scaffold out blocks that live in their codebase (similar to @shadcn/ui).

This way users are able to get started quickly using blocks in their codebase, but ultimately maintain control over the blocks and their associated queries. When their schema changes, they can update their codebase. Additionally they can make other tweaks to the components such as tie them in with tailwind or another styling framework that meets their sites needs.

The way I see it is that we can offer something like a faust scaffold blocks command (or similar) that would then prompt the user to select some options (i.e. which blocks to include/exclude, maybe whether to use tailwind or not, etc) then it would generate blocks in the wp-blocks directory for them that they would then be able to customize and tweak for their project(s).

Benefits

• Quick start: users can get started using blocks quickly
• Components and Queries live in the end users versioned code, closer to the schema being queried (users not waiting for a 3rd party package update to adapt to their schema)
• Users can customize the queries and components directly

Tradeoffs

• Individual projects need to update their queries / components in their codebase (vs updating an npm package)