Convert `blocks/` and `generators/` to TypeScript

[cpcallen]

This is a tracking bug for the remaining work to migrate the Blockly codebase to TypeScript, following the successful migration of core/.

This is part of #5857, and will resolve #6248 and probably also #2995.

Work to be done

• Update scripts/gulpfiles/build_tasks.js to feed the contents of blocks/ and generators/ through tsc.
  • Done: feat(build): Run tsc on blocks/ and generators/ #6836
• Update tests/bootstrap.js, playgrounds, etc. to load blocks and generators from build/src/ when loading uncompressed.
  • Turned out to be ~no work for now as they use goog.require so don't care about file location.
• Create script to assist with migration (esp. of imports).
  • Done: chore: Create script to help with .js -> .ts migration #6837
• [OPTIONAL:] Refine type of BlockDefinition (in core/blocks.ts) to make defining blocks easier and preferably less error prone.
  • At the moment BlockDefinition is AnyDuringMigration; this works but means that tsc provides no assistance in verifying block definitions—for example, it does not check to make sure that Block methods are being called (or overridden) correctly.
  • @cpcallen has asked a question on Stack Overflow but this has not elicited an answer yet.
  • @btw17 has made some useful suggestions, including in particular defining BlockDefinition as {[Property in keyof Block]?: Block[Property]} & {[key: string]: unknown}, but this is not perfect: e.g. mixin methods do not get the correct type for this.
• Create a model PR, migrating one file in blocks/, to verify that the above works as intended.
  • See refactor(blocks): Migrate blocks/math.js to TypeScript #6900.

blocks/

• blocks.js (refactor(blocks): Migrate blocks/blocks.js to TypeScript #7193)
• colour.js (refactor(blocks): Migrate blocks/colour.js to TypeScript #6901)
• lists.js (refactor(blocks): Migrate blocks/lists.js to TypeScript #6902)
• logic.js (refactor(blocks): Migrate blocks/logic.js to TypeScript #7003)
• loops.js (refactor(blocks): Migrate blocks/loops.js to TypeScript #6957)
• math.js (refactor(blocks): Migrate blocks/math.js to TypeScript #6900)
• procedures.js (refactor(blocks): Migrate blocks/procedures.js to TypeScript #7192 )
• text.js (refactor(blocks): Migrate blocks/text.js to TypeScript #6958)
• variables.js (refactor(blocks): Migrate blocks/variables.js and blocks/variables_dynamic.js to TypeScript #7001)
• variables_dynamic.js (refactor(blocks): Migrate blocks/variables.js and blocks/variables_dynamic.js to TypeScript #7001)

generators/

• Provide more user-friendly generator APIs #7326

• Make CodeGenerator abstract #7401

• dart.js

  • dart/dart_generator.js
  • dart/colour.js
  • dart/lists.js
  • dart/logic.js
  • dart/loops.js
  • dart/math.js
  • dart/procedures.js
  • dart/text.js
  • dart/variables.js
  • dart/variables_dynamic.js

• javascript.js

  • javascript/javascript_generator.js
  • javascript/colour.js
  • javascript/lists.js
  • javascript/logic.js
  • javascript/loops.js
  • javascript/math.js
  • javascript/procedures.js
  • javascript/text.js
  • javascript/variables.js
  • javascript/variables_dynamic.js

• lua.js

  • lua/lua_generator.js
  • lua/colour.js
  • lua/lists.js
  • lua/logic.js
  • lua/loops.js
  • lua/math.js
  • lua/procedures.js
  • lua/text.js
  • lua/variables.js
  • lua/variables_dynamic.js

• php.js

  • php/php_generator.js
  • php/colour.js
  • php/lists.js
  • php/logic.js
  • php/loops.js
  • php/math.js
  • php/procedures.js
  • php/text.js
  • php/variables.js
  • php/variables_dynamic.js

• python.js

  • python/python_generator.js
  • python/colour.js
  • python/lists.js
  • python/logic.js
  • python/loops.js
  • python/math.js
  • python/procedures.js
  • python/text.js
  • python/variables.js
  • python/variables_dynamic.js

[rachel-fenichel]

I took a quick crack at converting some of the generators files to see what broke. What I found:

• Individual language + block files (e.g. generators/javascript/colour.js) require the language generator file (generators.javascript.js) rather than the other way round.
  • That may mean we have to convert the language generator files first.
• Each language generator is declared as a new CodeGenerator('name') and then adds properties in several ways:
  • By calling specific functions (e.g. addReservedWords)
  • By overriding protected functions (e.g. quote_)
  • By adding functions (e.g. JavaScript.finish = function(code) { ... })
  • By adding properties (e.g. JavaScript.ORDER_ATOMIC = 0)
• The language generators also access properties that are protected, such as nameDB_.
  • This causes a warning, because as protected properties those should only be touched by subclasses, and the generator is an instance rather than a subclass.

Adding properties could be done with mixins, I think, but I'm not sure if that helps. As a test I tried something similar to what we do for blocks:

type JavaScriptGenerator = CodeGenerator&MyInterface;
interface MyInterface {
  ORDER_ATOMIC: number,
}

/**
 * JavaScript code generator.
 */
const JavaScript : JavaScriptGenerator = new CodeGenerator('JavaScript');

The declaration of JavaScript breaks with this error:

Type 'CodeGenerator' is not assignable to type 'JavaScriptGenerator'.
Property 'ORDER_ATOMIC' is missing in type 'CodeGenerator' but required in type 'MyInterface'.ts(2322)

Later, the place where I set ORDER_ATOMIC works fine (no warnings or errors).

[IlCallo]

Hey there, I migrated a big chunk of procedures.js to TS for personal purpose
I'm testing it out in these days
Would you like me to send a PR for it, since it seems unassigned?

I used abstract and anonymous classes to model the different objects and the internal state

It will need review since I miss most of the context
There are many usages of values which TS mention being string | null, which are used as if they are always defined
In other places there are checks for vars which should always be defined
And there are some parts of the code which don't really make sense after you add the types which are supposed to describe those snippets