TypeScript issues with 9.0.0-beta.1

[clementcontet]

Describe the bug
Following this discussion https://groups.google.com/g/blockly/c/beh5vO-hbLA, I've tested Blockly 9.0.0-beta.1 with my TypeScript project (https://github.com/Orange-OpenSource/super-coding-ball).

And I have the following issues:

1. I use the field-slider plugin and I had to force install it because it is not compatible with Blockly 9 (https://github.com/google/blockly-samples/blob/master/plugins/field-slider/package.json#L50)
2. The compiler doesn't find the class AnyDuringMigration.
   There is this line https://github.com/google/blockly/blob/develop/core/any_aliases.ts#L2 but it doesn't seem to be referenced. Fixed with 9.0.0-beta.1
3. I can't localize Blockly: import * as Fr from 'blockly/msg/fr'; and Blockly.setLocale(Fr); are not found in types
4. JavaScript generator is not working:

• If I use import * as Blockly from 'blockly'; then Blockly.JavaScript is undefined
• If I use import * as Javascript from 'blockly/javascript'; then Javascript.workspaceToCode() is not found

5. When I dispose the workspace when the Angular component is destoyed, I get: TypeError: Workspace is headless.
6. In ITheme, shouldn't FontStyle be optionnal if I don't want to override it?
7. Idem for colourSecondary and colourTertiary in Blockly.Theme.BlockStyle: previously I didn't set them and Blockly was fine
8. Idem for all fields of Theme.ComponentStyle; they are all nullable, so they should also be optional?

Desktop:

• OS: Windows10
• blockly 9.0.0-beta.1
• typescript 4.5.5
• tslint 6.1.3

[ktbytechibong]

I also ran into issues 2, 3, and 4. Here's the tsconfig.json file of my project (which depends on blockly) if it helps.

"compileOnSave": true,
"compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "sourceMap": false,
    "removeComments": true,
    "listEmittedFiles": false,
    "newLine": "LF",
    "downlevelIteration" : true,
    "incremental": true,
    "jsx": "react",
    "resolveJsonModule": true,
    "lib": [
        "dom",
        "es2021",
        "WebWorker",
    ],
    "skipLibCheck": true,
}

[BeksOmega]

If I use import * as Javascript from 'blockly/javascript'; then Javascript.workspaceToCode() is not found

Yeah this had to change a little bit with the new release. What you want to do now is: import javascript from 'blockly/javascript' Then javascript.workspaceToCode() will be defined. If you do import * as Javascript from 'blockly/javascript' you need to access it via Javascript.javascript.workspaceToCode().

Thanks for posting this issue! I'll continue looking into the other problems =)

[clementcontet]

What you want to do now is: import javascript from 'blockly/javascript' Then javascript.workspaceToCode() will be defined.

If I do that, I get this error: blockly_javascript__WEBPACK_IMPORTED_MODULE_1___default(...).workspaceToCode is not a function :(

[BeksOmega]

If I do that, I get this error: blockly_javascript__WEBPACK_IMPORTED_MODULE_1___default(...).workspaceToCode is not a function :(

Whoops, I was actually incorrect before. The new way to import generators is import {javascriptGenerator} from 'blockly/javascript' Then you can do javascriptGenerator.workspaceToCode I've filed #6412 to fix the typings for the generators.

I've been working through the other problems you highlighted, and I think I understand all of them except for this one:

In ITheme, shouldn't FontStyle be optionnal if I don't want to override it?

Could you explain a bit more about where you're running into problems with this? The FontStyle is optional in the Theme constructor, so I wouldn't expect it being required by the interface to be a problem.

[clementcontet]

The new way to import generators is import {javascriptGenerator} from 'blockly/javascript' Then you can do javascriptGenerator.workspaceToCode

Thanks, it works now!

Could you explain a bit more about where you're running into problems with this? The FontStyle is optional in the Theme constructor, so I wouldn't expect it being required by the interface to be a problem.

Well, I didn't use the constructor, I just instanciated the interface (https://github.com/Orange-OpenSource/super-coding-ball/blob/eb825dc661594eec296fd378a6b6be3b440e5886/src/app/services/code.service.ts#L37-L42).
I followed the examples on dev portal (https://developers.google.com/blockly/guides/configure/web/themes#create_a_theme) and also the dedicated Codelab (https://blocklycodelabs.dev/codelabs/theme-extension-identifier/index.html#0).

Indeed it works if I use the constructor (but then I have to modify the created theme with startHats field as I can't set it in the constructor).

[BeksOmega]

When I dispose the workspace when the Angular component is destoyed, I get: TypeError: Workspace is headless.

Hello! I'm not super familiar with Angular, and our Angular sample doesn't seem to actually handle destruction :/ Could you post the full stack trace of your error and the code you're using to destroy the component?

That way hopefully I can reproduce the issue so I'll be able to work on a fix hehe.

Thank you for your time!

[clementcontet]

Hi!

Could you post the full stack trace of your error and the code you're using to destroy the component?

I've put my progress so far with Blockly 9 on this branch: https://github.com/Orange-OpenSource/super-coding-ball/tree/blockly9

You can just pull the branch, npm install and ng serve

To encounter the issue, you can just go to the "How do we play" section, and then go back.

The 3 workspaces are then disposed with https://github.com/Orange-OpenSource/super-coding-ball/blob/89bc61a5d1b8441312088cf650c43f2a1cdfb159/src/app/components/howto/howto.component.ts#L77-L79

And while it was working fine in Blockly6 (I didn't try the versions in between), with 9.0.0-beta.1 I get:

ERROR Error: Uncaught (in promise): TypeError: Workspace is headless.
TypeError: Workspace is headless.
    at BlockSvg$$module$build$src$core$block_svg.initSvg (blockly_compressed.js:711:380)
    at RenderedConnection$$module$build$src$core$rendered_connection.respawnShadow_ (blockly_compressed.js:704:277)
    at RenderedConnection$$module$build$src$core$rendered_connection.disconnect (blockly_compressed.js:439:189)
    at BlockSvg$$module$build$src$core$block_svg.unplugFromRow_ (blockly_compressed.js:633:80)
    at BlockSvg$$module$build$src$core$block_svg.unplug (blockly_compressed.js:632:457)
    at BlockSvg$$module$build$src$core$block_svg.dispose (blockly_compressed.js:631:116)
    at BlockSvg$$module$build$src$core$block_svg.dispose (blockly_compressed.js:727:458)
    at BlockSvg$$module$build$src$core$block_svg.dispose (blockly_compressed.js:632:83)
    at BlockSvg$$module$build$src$core$block_svg.dispose (blockly_compressed.js:727:458)
    at BlockSvg$$module$build$src$core$block_svg.dispose (blockly_compressed.js:632:83)
    at resolvePromise (zone.js:1262:1)
    at resolvePromise (zone.js:1216:1)
    at zone.js:1329:1
    at push.3484._ZoneDelegate.invokeTask (zone.js:443:1)
    at Object.onInvokeTask (core.mjs:25535:1)
    at push.3484._ZoneDelegate.invokeTask (zone.js:442:1)
    at push.3484.Zone.runTask (zone.js:214:1)
    at drainMicroTaskQueue (zone.js:632:1)
    at push.3484.ZoneTask.invokeTask [as invoke] (zone.js:529:1)
    at invokeTask (zone.js:1727:1)

PS: I'm not sure it is an issue with Angular components being destroyed, because I get the same issue when launching a game and no component is destroyed in this case.

Thanks again!

[BeksOmega]

Fixed all the issues in various pull requests!