* refactor(blocks): Auto-migration of blocks/loops.js to ts
* fix(blocks): Manually migrate types and fix imports in loops.ts
* chore: respond to PR comments
* refactor(blocks): Auto-migration of blocks/lists.js to ts
* fix(blocks): Manually migrate & fix types in lists.ts
* chore(blocks): format lists.ts
Not running clang-format on this as for some reason it decides
half way through the file to indent everything after that by
an extra four spaces (and then has to re-wrap a bunch of lines
that are consequently too long).
* refactor(blocks): Improve types in lists.ts
It turns out that the way I originally specified the types for
the mixins meant that they were all 'any', which is a bit
useless. Change them so that tsc actually typechecks
properties (including method calls) on the mixed-in blocks,
and then fix the numerous additional type errors which
doing this revealed.
(By "fix", I mean apply "as" casts and "!"s as required to
suppress type errors from tsc. Actually fixing the code in a
way that makes the blocks meaningfully more bulletproof is
left as an exercise to the reader - sorry, I mean: will be
dealt with in a future PR.)
* fix(blocks): Additional fixes for comments PR #6902
The 'compareDocumentPosition' call was inherited from Closure Library, in order to work with IE 8 and earlier. Use the more modern 'contains' call instead.
This change was originally added here:
https://github.com/google/blockly/pull/1991
Remove the DOCUMENT_POSITION_CONTAINED_BY constant which is not a NodeType and should never have been part of that enum.
This change was originally added here:
https://github.com/google/blockly/pull/2736
Temporarily exclude the generated .d.ts files for blocks/* and
generators/* from the package.
This will in due course replace the (very simplistic) hand-written
versions in typings/, but for now they are not referenced
anywhere a developer's tooling should be looking, and contain
in some cases actually incorrect typings (e.g., in unmigrated
blocks files, the blocks export is typed as ObjectConstructor,
which is wrong), so do not include them in the package least they
cause problems for the unwary.
We introduced the SKIP_SETUP sentinel value when converting
Field and its subclasses to ES6 class syntax, because super
must be called before any other code in a subclass
constructor, breaking the previous mechanism where subclasses
would set some properties before calling their superclass
constructor.
SKIP_SETUP was a singleton value of class Sentinel.
Recently, in PR #6639 @btw17 introduced the isSentinel type
predicate to improve the typing of Field. Unfortunately, there
were some aspects of this change that were not very elegant:
- isSentinel was declared as a static method on Field (rather
than on Sentinel itself).
- It only checks against the specific value SKIP_SETUP,
rather than checking if the argument is instanceof Sentinel
(though perhaps this is for efficiency?)
Additionally - as a result of the migration from ES6 to TS, and
predating PR #6639 - The signature for the Field constructor's
first argument was typed T|Sentinel, with subclass constructors
generally being <some type(s)>|Sentinel.
This creates a small problem when attempting to port Fields from
core to plugins, because Sentinel is not reexported by
core/utils.ts (and therefore not from core/blockly.ts either).
The latter problem could be solved simply by reexporting Sentinel,
or by having plugin constructors not accept SKIP_SETUP (though
this potentially makes them more difficult to subclass), but
neither is particularly desirable.
Instead, this PR proposes that we:
- Make Field.SKIP_SETUP a (unique) Symbol.
- Change the value argument to the Field constructor to accept
T|typeof Field.SKIP_SETUP - where typeof Field.SKIP_SETUP is
(like a literal type) a type that accepts just the single
value SKIP_SETUP.
- Remove the Sentinel class and core/utils/sentinel.ts.
Not treating this as a breaking change:
- Removes Field.isSentinel - though this addition has not yet
been published, so it can only break our own as-yet-unreleased
code in samples.
- Changes the type of Field.SKIP_SETUP and the first argument
of the Field constructor from Sentinel to typeof SKIP_SETUP
(a unique Symbol) - but given that Sentinel has never been
exported this should not break any actual external code.
