Investigate "cannot redefine property: alert" error while running tests with Blockly beta version

Category Plugins

Component Some plugins (currently under investigation)

Describe the bug When using the Blockly beta release, test fails with the error “TypeError: Cannot redefine property: alert”.

To Reproduce

Steps to reproduce the behavior:

1. npm install blockly@beta (you may need to also update the upper bound of the peerDependency in package.json)
2. npm run test
3. See error

webpack-internal:///./node_modules/blockly/blockly_compressed.js:1893
if(module$exports$Blockly$utils$global.globalThis.Blockly&&"object"===typeof module$exports$Blockly$utils$global.globalThis.Blockly){var descriptors=Object.getOwnPropertyDescriptors(Blockly),accessors={},key;for(key in descriptors)if(descriptors[key].get||descriptors[key].set)accessors[key]=descriptors[key];Object.defineProperties(module$exports$Blockly$utils$global.globalThis.Blockly,accessors)};Blockly.serialization.variables={};var module$contents$Blockly$serialization$variables_State;Blockly.serialization.variables.State=module$contents$Blockly$serialization$variables_State;var module$contents$Blockly$serialization$variables_VariableSerializer=function(){this.priority=Blockly.serialization.priorities.VARIABLES};
                                                                                                                                                                                                                                                                                                                            ^

TypeError: Cannot redefine property: alert
    at Function.defineProperties (<anonymous>)
    at Object.eval (webpack-internal:///./node_modules/blockly/blockly_compressed.js:1893:317)
    at eval (webpack-internal:///./node_modules/blockly/blockly_compressed.js:8:37)
    at eval (webpack-internal:///./node_modules/blockly/blockly_compressed.js:11:2)
    at Object../node_modules/blockly/blockly_compressed.js (/usr/local/google/home/kozbial/github/blockly/samples-moniika/plugins/block-plus-minus/build/list_create.mocha.js:1169:1)
    at __webpack_require__ (/usr/local/google/home/kozbial/github/blockly/samples-moniika/plugins/block-plus-minus/build/list_create.mocha.js:30:30)
    at eval (webpack-internal:///./node_modules/blockly/blockly.js:4:39)
    at eval (webpack-internal:///./node_modules/blockly/blockly.js:9:2)
    at Object../node_modules/blockly/blockly.js (/usr/local/google/home/kozbial/github/blockly/samples-moniika/plugins/block-plus-minus/build/list_create.mocha.js:1158:1)
    at __webpack_require__ (/usr/local/google/home/kozbial/github/blockly/samples-moniika/plugins/block-plus-minus/build/list_create.mocha.js:30:30)

Additional context

Although the test fail, running the plugins (npm run start) seem to work fine.

[cpcallen]

OK. I think I understand what is going on.

We did not include configurable: true in the property descriptors passed to Object.defineProperties. This prevents the accessor properties from being redefined, which would be OK except that in blockly.js the accessor properties from that module’s exports object are copied onto globalThis.Blockly.

In uncompiled mode, this typically adds them to the global Blockly object created as a result of the remaining goog.provide or goog.module.declareLegacyNamespace calls for Blockly.**, in to which the properties from the exports object get merged when blockly.js itself has finished evaluating. That’s what we want, because the accessor properties would not get copied by the merge code in base.js.

In compiled mode, this adds them to the placeholder Blockly object created manually by the code in core/msg.js (Blockly.Msg). Also fine normally, since at some point (depending on exactly how blockly_uncompressed.js is loaded) there’s going to be an assignment that will completely replace this stub Blockly object with the actual exports object from blockly.js.

Where we get in to trouble is that apparently some of the plugins (or at least their tests) are trying to load two different copies of the blockly module. The first load succeeds, but during the second one the accessor-copying code in blockly.js ends up trying to modify the accessors on globalThis.Blockly which is the exports object from the earlier-loaded copy. They’re non-configurable so this fails with TypeError.

The first fix I thought of was to add configurable:true to the accessors on the exports object in blockly.js; this will ensure (in either compiled or uncompiled mode) that the copies on globalThis.Blockly are configurable, preventing the error. But that’s actually horrifying, because the accessor properties on the earlier-loaded copy would end up calling get/set functions on the later-loaded copy.

Here is a better plan:

• We should figure out why the plugins are ending up with two different copies of Blockly, and fix that. I think npm is supposed to de-dupe them, but evidently it is not working for whatever reason—probably versioning.

• We should modify blockly.js so that it only copies the accessors in uncompiled mode.

(I note that the same basic issues will affect loading translations: if you end up with two copies of the Blockly module loaded, then loading translations via a <script> tag (which writes properties on globalThis.Blockly.Msg) loads messages in to one copy of Blockly but not the other.)

[cpcallen]

As far as I know the actual error reported in this issue has now been fixed.

I’ve filed #949 to consider improvements to the test running system.