Where is blockly_compressed.js?

[Eric Nashil]

Hello,

I'm really puzzled. Since Blockly version 9.1.0, various javascript files at the root of the project, like blockly_compressed.js or blocks_compressed.js have disappeared from the repository. In 9.0.1 they are here, and in 9.1.0 they are gone.

All examples shown in the doc invite to include those js files in the html of our Blockly app. See for example: https://developers.google.com/blockly/guides/contribute/core/building

I've come to understand that those files can be generated with npm run build. However this command fails on 9.1.0 (and on master as well):

SourceError: Error in source file "C:\Dev\nerd\data\gui\blockly\blocks\blocks.js": The symbol "Blockly.libraryBlocks" has already been defined at C:\Dev\nerd\data\gui\blockly\build\src\blocks\blocks.js
    at new Graph (C:\Dev\nerd\data\gui\blockly\node_modules\google-closure-deps\lib\depgraph.js:319:17)
    at main (C:\Dev\nerd\data\gui\blockly\node_modules\google-closure-deps\bin\closuremakedeps.js:296:5)
    at async C:\Dev\nerd\data\gui\blockly\node_modules\google-closure-deps\bin\closuremakedeps.js:313:22

So my questions are:

1. why have those files been suddenly removed from the git repo? (it's not even mentioned in the changelog)

2. are we expected to build them? If so, why is the build script above failing presumably since 9.1.0 without a fix?

Sorry if I'm completely missing something here. I've searched the forums for people having similar issues but I seem to be the only one, which suggests I misunderstand something.

Thanks for your help!

[Eric Nashil]

Forget what I said about the npm run build command, I just had an old build folder that was interfering. 

That being said, it works fine up to version 9.3.0 where we still get another error (not fixed in master apparently):

[09:17:16] Error: Unable to identify chunk
    at C:\Dev\data\gui\blockly\scripts\gulpfiles\build_tasks.js:568:23
    at Array.map (<anonymous>)
    at getChunkOptions (C:\Dev\data\gui\blockly\scripts\gulpfiles\build_tasks.js:558:38)
    at buildCompiled (C:\Dev\data\gui\blockly\scripts\gulpfiles\build_tasks.js:641:24)
    at bound (node:domain:433:15)
    at runBound (node:domain:444:12)
    at asyncRunner (C:\Dev\data\gui\blockly\node_modules\bach\node_modules\async-done\index.js:55:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
[09:17:16] 'build' errored after 5.54 s

When it works, the expected compressed.js files are stored in a dist folder. So, are we supposed to now rebuild and use the dist folder in our projects? Again, it feels like I'm missing something here. One would expect the github repo to provide everything needed for development out of the box.

Thanks!

[Maribeth Bottorff]

You shouldn't be building Blockly yourself unless you're contributing directly to the Blockly repo. The recommended approach is to get Blockly from the npm registry. Otherwise, you can download the code from the GitHub release you want to use, as documented here. It's quite common for published packages to not include the compiled code in the repository. We removed them as the checked-in files were frequently out of date with the actual source code, causing confusion, bugs, and inaccurate tests. Apologies though, this should have been mentioned in the release notes.

Maribeth

[Eric Nashil]

Thanks for the clarification Maribeth. I'm actually integrating Blockly in a C++ app that renders its UI through an html renderer. Blockly is simply a submodule in my git repo. I don't think I could use npm in this context. It's fine for me to add a build stage in my bootstrap process, so if it's working I just need to update the src of the compressed js files, which are now compiled in a dist folder.

Still, as mentioned above, the npm run build is failing on master (since 9.3.0). I hope it will be fixed in some future updates (shall I fill in a bug report?). It could be useful also to update the official doc that still implies the existence of the js file, and don't mention how to rebuild them.

Thanks again!

[Maribeth Bottorff]

Unfortunately the build support on windows is shaky, because none of us on the core team use Windows and we simply don't have the resources to commit to debugging this when most people never need to build Blockly themselves. I think the particular error message you're seeing was reported here and I suggested a fix but don't have the ability to test it. If you are able to test this fix and open a PR if it works, that would be much appreciated.

In your steps, you likely want to run `npm run package` not just `npm run build`. This will ensure you have a clean output directory (will prevent the first error you saw) and in general do all the same tasks that we do in order to generate the file you can download from npm/github.

I'd also recommend using 9.3.3 as we had several important bug fixes after releasing 9.3.0

As for the docs, do you have a particular place in mind that you would like to see updated? The building blockly page you linked in the first message is in the contributing to blockly section, and it does explain how to rebuild the files (though it is also out of date in other respects).

Maribeth

[Eric Nashil]

Hi Maribeth,

I've tried the suggested patch to fix the build on windows (using path.sep), but it does not fix the problem unfortunately. But ok, I can download a release as a tgz in my bootstrap and that should work.

So, I've downloaded the tgx releases instead and this works fine now (all the compressed js files are there, there is a slight change of path for msg/js/en.js that becomes msg/en.js but that's ok). However, now at the app level there are some changes in 9.1.0 and then 9.2.0 that breaks my app:

• In 9.1.0, I cannot click on a block in the toolbox to drag it on the workspace. I get this error:

[LOG] [JSConsole]: [JS] [Error] ReferenceError: Can't find variable: PointerEvent

[LOG]     => (file:///gui/blockly/blockly_compressed.js @ line 16, col 430)

• Starting in 9.2.0, I don't even see my block toolbox anymore, and no error shows in the console, so I'm stuck. Same thing on 9.3.x onwards, including 9.3.3.

I've read carefully the release notes of each version, but couldn't find a mention of deprecation for PointerEvent (which I don't directly use anyway, it seems to be in internal issue). As for the disappearance of the toolbox, I have no clue what could be going on. Probably some deep change in the way Blockly is supposed to be used/configured, so I should start from scratch assuming this is not a temporary bug on Blockly side.

I think I should stick to 8.0.5 for now, there are too many breaking changes in 9.x.x and possible bugs that have not been resolved yet. In any case: thanks a lot for your efforts and for maintaining this great project!

Best regards

[Maribeth Bottorff]

Hello Eric,

PointerEvent is referring to the Web API, and it's something we started using, not deprecated. It's been supported in all major browsers for a while now, and switching to PointerEvent allowed us to greatly simplify our touch handling code. It sounds like you may not be using a standard web browser in your application, so you may want to look into polyfilling this API if it's not natively supported in the engine you're using.

As for the toolbox not showing up, I'm not sure. I don't think we changed anything about the way you configure a toolbox. If you post a minimal reproduction or perhaps at least your `inject` call maybe we can spot the problem.

Maribeth

[Eric Nashil]

Thanks again for your answer Maribeth. As a matter of a fact, I'm using Ultralight UX (https://github.com/ultralight-ux/Ultralight) to render html/js inside a C++ app. It's quite popular for games. Thanks for the tip on polyfilling PointerEvent, I will perhaps try this (there are some github projects that seem to do it already) and if I do I'll post an update here. I might also wait for an update of Ultralight, which will perhaps magically solve all these issues! No rush anyway, Blockly 8.0.5 works like a charm for what I do.

All the best,

Eric

[Christopher Allen]

Hi Eric,

Still, as mentioned above, the npm run build is failing on master (since 9.3.0). I hope it will be fixed in some future updates (shall I fill in a bug report?).

Can you please take a look at PR #7127 and let us know if it fixes the build on for you on WIndows?

It could be useful also to update the official doc that still implies the existence of the js file, and don't mention how to rebuild them.

My apologies for the confusion, which is totally my fault: I've had a part-finished update to the docs sitting in my stashes for ages which I had forgotten about.  I will endeavour to get that finished and committed ASAP.

Christopher

[Eric Nashil]

Hi Christopher,

It appears PR #7127 has been merged into develop, so I tried the develop branch. When I run "npm run package", I still get the same error:

[07:23:19] Error: Unable to identify chunk
    at C:\Dev\blockly\scripts\gulpfiles\build_tasks.js:564:23

    at Array.map (<anonymous>)

    at getChunkOptions (C:\Dev\blockly\scripts\gulpfiles\build_tasks.js:554:38)
    at buildCompiled (C:\Dev\blockly\scripts\gulpfiles\build_tasks.js:637:24)

    at bound (node:domain:433:15)
    at runBound (node:domain:444:12)

    at asyncRunner (C:\Dev\blockly\node_modules\bach\node_modules\async-done\index.js:55:18)

    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)

[07:23:19] 'package' errored after 5.59 s

Best,

Eric

[Christopher Allen]

Hi Eric,

On Fri, 2 Jun 2023 at 04:26, Eric Nashil <erna...@gmail.com> wrote:

Hi Christopher,

It appears PR #7127 has been merged into develop, so I tried the develop branch. When I run "npm run package", I still get the same error:

[07:23:19] Error: Unable to identify chunk
    at C:\Dev\blockly\scripts\gulpfiles\build_tasks.js:564:23
    at Array.map (<anonymous>)
    at getChunkOptions (C:\Dev\blockly\scripts\gulpfiles\build_tasks.js:554:38)
    at buildCompiled (C:\Dev\blockly\scripts\gulpfiles\build_tasks.js:637:24)
    at bound (node:domain:433:15)
    at runBound (node:domain:444:12)
    at asyncRunner (C:\Dev\blockly\node_modules\bach\node_modules\async-done\index.js:55:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
[07:23:19] 'package' errored after 5.59 s

 

Can you change line 564 of scripts/gulpfiles/build_tasks.js to read:

    if (!chunk) throw new Error(`Unable to identify chunk for ${f}');

and let us know what it prints?  (A few examples are sufficient!)

Christopher

[Eric Nashil]

Hi Christopher,

{f} is not defined out of the scope of find, but nevermind, I think I have a fix that works:

$ git diff
diff --git a/scripts/gulpfiles/build_tasks.js b/scripts/gulpfiles/build_tasks.js
index 1a9cbc74a..f010208c6 100644
--- a/scripts/gulpfiles/build_tasks.js
+++ b/scripts/gulpfiles/build_tasks.js
@@ -560,7 +560,7 @@ function getChunkOptions() {
     // Figure out which chunk this is by looking for one of the
     // known chunk entrypoints in chunkFiles.  N.B.: O(n*m).  :-(
     const chunk = chunks.find(
-        chunk => chunkFiles.find(f => f.endsWith(path.sep + chunk.entry)));
+        chunk => chunkFiles.find(f => f.split(path.posix.sep).join(path.win32.sep).endsWith(chunk.entry)));
     if (!chunk) throw new Error('Unable to identify chunk');

I couldn't test it on Linux because after a fresh install of blockly, and "npm install gulp", now I get this error when running "npm run package":

SyntaxError: Unexpected token '('
    at compileFunction (<anonymous>)
    at wrapSafe (internal/modules/cjs/loader.js:915:16)
    at Module._compile (internal/modules/cjs/loader.js:963:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/home/dev/blockly/node_modules/rimraf/node_modules/minimatch/dist/cjs/index.js:9:18)
    at Module._compile (internal/modules/cjs/loader.js:999:30)

Perhaps you can try the fix on Linux on your side, and if it works, it could be added to a PR.

Cheers,

Eric