feat!: add block definition to multiline text field plugin

[rachel-fenichel]

The basics

• I validated my changes

The details

Resolves

Fixes #2154

Proposed Changes

• Adds a block definition and generators for one block associated with the multiline input field:
  • text_multiline
• Follows the previously established pattern for defining and exporting a library of blocks

BREAKING CHANGE: The multiline text input field no longer registers itself on load. The developer must either manually register the field or install blocks, which will install the field. This is part of a move to have no side effects in field and block definitions, so that tree-shaking can remove unwanted fields and blocks.

Reason for Changes

This is the next step in extracting block definitions from the core library and publishing them as smaller libraries. Developers can then choose which blocks and fields to install, and can tree-shake out unneeded ones.

Test Coverage

• Updated mocha tests to call registerFieldMultilineInput
• Updated test playground to delete/unregister the old block, generators, and field from core, then install/register the new versions.
• Stripped use of old generateFieldTestBlocks helper in favor of manually defining test blocks and the test toolbox.
  • I found the result easier to read and modify, and it won't change frequently.

The test toolbox looks like this:

The first part of the toolbox tests the exported blocks. The later sections test the implementation of the field.

Documentation

Updated README to describe the block and how to use it, and to note that users must install either the block or the field.

Additional Information

Open question: this field only exports one block. I still also exported installAllBlocks. The only value there is consistency. Should I even bother for a single block? In the example code and README I call textMultiline.installBlock().

As with google/blockly#2162, there is some follow-up work:

• Port generator tests from core, to test generated code against golden files.
  • For the purposes of this PR I tested by loading the block in the playground and checking the generated code in the playground.
• Other cleanup tracked in Cleanup after deleting blocks and fields from core #2194

[cpcallen]

Open question: this field only exports one block. I still also exported installAllBlocks. The only value there is consistency. Should I even bother for a single block? In the example code and README I call textMultiline.installBlock().

I think it's worth providing an installAllBlocks for consistency and in case we add more blocks in future—but it can just be an alias for the oen installBlock function for now.

Reciprocal question: I presume you have not attempted to address google/blockly#7209, correct? I ask because the toolbox screenshot seems to be rendered better than I'd expect given that bug.

[cpcallen]

(Duplicate comment body deleted.)

[cpcallen]

Might it be worth adding an "all items optional" comment here?

[rachel-fenichel]

The text above says "you can supply one or more CodeGenerator instances", which i think is sufficient.

[cpcallen]

Why wrap this in a function that is called from createWorkspace, rather than just executing the contents directly a the top level any time before calling document.addEventListener?

[rachel-fenichel]

I find it easy to lose track of where things that are specific to the plugin test are, so I like putting it all into createWorkspace. This is a slight personal preference.

[rachel-fenichel]

As discussed offline, Blake has a fix for the multiline field issue in #2208