Switch to using block.json to register blocks.

[tcmulder]

Rather than glob requiring index.php files, get rid of them. Instead, run register_block_type via blocks.php on the blocks's individual directories (it'll pick up the block.json automatically).

A few notes if I go this route:

1. Can enqueue style and viewScript via block.json. Shouldn't do editor, bc still want to add more to it (or even skip loading the front-end styles altogether).
2. For dynamic blocks, css works fine, but viewScript will only work with a script slug when render is defined for the PHP template. I can enqueue the script within my-block-markup.php though since it's JS and loads in the footer, so still no index.php needed.
3. Add php to the top of hooks.php, since those still may be required. Ensure it blocks direct access:

defined( 'ABSPATH' ) || die( 'Silence is golden.' );

[tcmulder]

Also, think through this: could go back to the old way of glumping all -style.css/-script.js files into one, and then name these something else, like -block.css/-block.js. So parcel2 would pick up these front-end files separately, and you could still use *-style.css for things like core block edits.

[tcmulder]

Oh, on #1, note that style gets enqueued as the view and editor anyway, so it's not possible to skip loading front-end styles and therefore there's no advantage to the whole approach of lading editor styles in the special way they are now.

[tcmulder]

Quick update: I've created a working test of this on a v7.0.0 branch. It does seem to work... but WordPress fights me on a few items, e.g. assets it loads from block.json have incorrect paths (it's adding plugin paths even though it's part of the theme), and it tries to inline all CSS rather than loading them as stylesheet files. I'm not hacking things, it's a clean strategy, but it could be worth much greater testing to ensure it'll work fine across other use cases than just the grd block I played around with.