Is your feature request related to a problem? Please describe.
Issue #902 occurred (in part) because dev-scripts/scripts/test.js compiles each 1-20 KiB tests/*.mocha.js test file into a 17–25 MiB webpack'd monstrosity in build/, each containing a complete copy of all of its dependencies (including the whole of blockly_compressed.js et al.), and then these files are required and executed one at a time (but in the same invocation of node.
This seems to have several disadvantages:
The build process is fairly slow.
Running the tests is also at least somewhat slower than it could be.
It violates the normal assumption that a particular module will only be imported once. Blockly didn't like having this assumption violated, and though (AFAIK) most of the problematic code has now been removed or fixed there are still some potential problems as long as there remain any goog.module.declareLegacyNamespace calls or usage of globalThis (e.g. for the translation loading hack or jsdom installation)
E.g., if Blockly is imported multiple times, even as named requires saved in a non-global variables, only the first copy will grab (globalThis.)Blockly.Msg, so later copies will not be able load translations via <script> tags or equivalent.
Nevertheless, this arrangement was set up for various reasons, including (as I understand it):
to solve certain issues with tests finding their dependencies, and
to ensure isolation between tests by avoiding sharing a Blockly instance.
Describe the solution you'd like
I think it would be worth trying to revise the test runner for these tests with a view to achieving the following (in order of priority):
Don't load more than one instance of Blockly in a given JS engine invocation.
Run the tests (including any needed build process) as quickly as possible.
Make the test running machinery as simple and easy to understand as possible.
Describe alternatives you'd like to see considered
Can we just load dependencies directly from nodee_modules/ and skip the build step completely?
If we need isolation between tests, would it be much slower just to run node once for each tests/*.mocha.js file? (This incurs the cost of loading all the dependencies for each test, but would probably still be faster than building a webpack for each one first.)
I think we need to bump mocha to v10 and drop node 12 support before we remove the build step. My understanding is mocha uses node to run our code, and node doesn't support esmodules until >=13.
Category
Component
Is your feature request related to a problem? Please describe.
Issue #902 occurred (in part) because
dev-scripts/scripts/test.js
compiles each 1-20 KiBtests/*.mocha.js
test file into a 17–25 MiB webpack'd monstrosity inbuild/
, each containing a complete copy of all of its dependencies (including the whole ofblockly_compressed.js
et al.), and then these files are required and executed one at a time (but in the same invocation ofnode
.This seems to have several disadvantages:
goog.module.declareLegacyNamespace
calls or usage ofglobalThis
(e.g. for the translation loading hack or jsdom installation)Blockly.Msg
, so later copies will not be able load translations via<script>
tags or equivalent.Nevertheless, this arrangement was set up for various reasons, including (as I understand it):
Describe the solution you'd like
I think it would be worth trying to revise the test runner for these tests with a view to achieving the following (in order of priority):
Describe alternatives you'd like to see considered
nodee_modules/
and skip the build step completely?node
once for eachtests/*.mocha.js
file? (This incurs the cost of loading all the dependencies for each test, but would probably still be faster than building a webpack for each one first.)Additional context
See #902.