@blockly/field-colour causes "CSS already injected" and "Invalid block definition" errors after upgrading Blockly to v11

[green-study]

Check for duplicates

• [x] I have searched for similar issues before opening a new one.

Description

Our project was originally using Blockly v6, but after upgrading to Blockly v11, we encountered issues when adding the now separately packaged @blockly/field-colour library.

Main Issues:

1. CSS Injection Error

CSS already injected
    at Object.register$$module$build$src$core$css [as register] 
    (http://localhost:3000/link/static/js/bundle.js:130440:52)
    at http://localhost:3000/link/static/js/vendors-node_modules_blockly_field-colour_dist_index_js-node_modules_react-datepicker_dist_re-735a00.chunk.js:278:48

• This error occurs when initializing Blockly with @blockly/field-colour.
• It suggests that the CSS for this module is being injected multiple times, leading to conflicts.
• Tried setting css: false in Blockly.inject, but it did not resolve the issue.

2. "Invalid block definition" Error When importing registerFieldColour from @blockly/field-colour: import { registerFieldColour } from '@blockly/field-colour'; The following error occurs for all blocks when the Blockly toolbox loads:

Uncaught TypeError: Invalid block definition for type: example_type
    at new Block$$module$build$src$core$block (blockly_compressed.js:11432:1)
    at new BlockSvg$$module$build$src$core$block_svg (blockly_compressed.js:15073:1)
    at WorkspaceSvg$$module$build$src$core$workspace_svg.newBlock (blockly_compressed.js:20917:1)
    at domToBlockHeadless$$module$build$src$core$xml (blockly_compressed.js:2509:1)
    at domToBlockInternal$$module$build$src$core$xml (blockly_compressed.js:2355:1)
    at VerticalFlyout$$module$build$src$core$flyout_vertical.createFlyoutBlock (blockly_compressed.js:18033:1)
    at VerticalFlyout$$module$build$src$core$flyout_vertical.createFlyoutInfo (blockly_compressed.js:17993:1)
    at VerticalFlyout$$module$build$src$core$flyout_vertical.show (blockly_compressed.js:17961:1)
    at Toolbox$$module$build$src$core$toolbox$toolbox.updateFlyout_ (blockly_compressed.js:20838:1)
    at Toolbox$$module$build$src$core$toolbox$toolbox.setSelectedItem (blockly_compressed.js:20814:1)

The important point is that all blocks are throwing errors, even those that do not use field_colour. This breaks all block definitions, including our custom blocks.

Steps to Reproduce:

1. Upgrade Blockly from v6 to v11.
2. Install @blockly/[email protected].
3. Import and register field-colour:

import { registerFieldColour } from '@blockly/field-colour';
registerFieldColour();

4. Initialize Blockly with a toolbox containing a block with a colour field.
5. Observe the "CSS already injected" error in the console.
6. Open the Blockly toolbox and observe "Invalid block definition" errors for all blocks.

Expected Behavior:

• Blockly should initialize without CSS injection errors.
• Blocks should render properly without "Invalid block definition" errors.

Actual Behavior:

• Registering @blockly/field-colour causes CSS conflicts.
• Importing registerFieldColour breaks all blocks in the toolbox.

Environment:

• Blockly Version: 11.2.1
• @blockly/field-colour Version: 5.0.12
• React Version: 18.3.1
• Browser: Chrome
• Operating System: Windows

Additional Notes:

• This issue did not occur in Blockly v6, as colour fields were part of the core package.
• Other Blockly modules (@blockly/workspace-backpack, @blockly/workspace-minimap) work fine.
• The issue seems to be related to how @blockly/field-colour handles registration in module-based environments (React, Webpack, etc.)

Block Definition:

Blockly.Blocks["example_type"] = {
  init: function() {
    this.jsonInit({
      message0: "%{BKY_EXAMPLE_TYPE}",
      args0: [
        {
          type: "field_image",
          src: matchBaseUrl + "/images/icons/led.svg",
          width: 25,
          height: 25,
          alt: "*"
        },
        {
          type: "field_colour",
          name: "colour",
          colour: "#ff0000",
          colourOptions:
            ["#FF0000", "#ff8c00", "#FFFF00", "#00FF00", "#ACE5EE", 
             "#1974d2", "#5D3FD3", "#ff00ff", "#FFFFFF", "#000000"]
        },
        {
          type: "input_value",
          name: "brightness"
        },
        {
          type: "input_dummy",
          name: "PLACEHOLDER"
        }
      ],
      previousStatement: null,
      nextStatement: null,
      colour: HUE_Violet,
      tooltip: "example_code()",
      helpUrl: ""
    });
  }
};

PythonGenerator:

pythonGenerator.forBlock['example_type'] = function(block) {
  var arg0 = block.getFieldValue("colour");  
  var r = parseInt("0x" + arg0.substring(1, 3), 16);
  var g = parseInt("0x" + arg0.substring(3, 5), 16);
  var b = parseInt("0x" + arg0.substring(5, 7), 16);
  if (r === "0x00" && g === "0x00" && b === "0x00") {
    return "example_code()\n";
  }

  var brightness = pythonGenerator.valueToCode(block, 'brightness', Order.ATOMIC) || '0';
  return "example_code(" + r + ", " +  g + ", " + b +", " + brightness + ")\n";
}

I have done my best to modify the existing code to be compatible with Blockly v11. However, our project has been stalled for a week due to this issue. If any additional information is needed to resolve the issue, please let me know. If anyone can provide assistance, it would be greatly appreciated.

I also posted this on the forum's conversation, but it seems to have been omitted for some reason, so I'm also leaving it as a GitHub issue. I appreciate your understanding.

Browsers

Chrome desktop

[cpcallen]

Looks like your forum post was held up in moderation, but [is live now]https://groups.google.com/g/blockly/c/I67WTS7AvbM/m/ksBBu5asAgAJ?e=48417069).

Leaving this open for @gonfunko to deal with, as he thinks there may be an actual bug here.

[cpcallen]

Moving this bug to samples.