Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: Remove last remaining circular import in core/ #6818

Merged
merged 7 commits into from
Feb 7, 2023

Conversation

cpcallen
Copy link
Contributor

@cpcallen cpcallen commented Feb 3, 2023

The basics

  • I branched from develop
  • My pull request is against develop
  • My code follows the style guide
  • I ran npm run format and npm run lint

The details

Resolves

Fixes #6817.

Proposed Changes

  • Move textToDom from core/xml.ts to core/utils/xml.ts.
  • Re-enable goog.declareModuleId multiple-call check in closure/goog/base.js.

Reason for Changes

The textToDom function being in core/xml.ts is the cause for the last remaining circular import in core/ (between variables.ts and xml.ts). Moving it to core/utils/xml.ts makes sense anyway, since there is nothing Blockly-specific about this function.

Reenabling the assertion which checks to make sure that goog.declareModuleId is not called more than once in a module will also catch circular imports amongst ES modules, which are not detected by closure-make-deps).

Test Coverage

Passes npm test.

No manual test changes expected.

@cpcallen cpcallen added the PR: chore General chores (dependencies, typos, etc) label Feb 3, 2023
@cpcallen
Copy link
Contributor Author

cpcallen commented Feb 3, 2023

Leaving this as a draft for the moment because it turns out I missed some calls to textToDom from outside core/ that should also be updated to call the version in utils/xml.ts.

@cpcallen cpcallen force-pushed the fix/6817-no-cyclic-imports branch 2 times, most recently from dbd8a20 to d0783af Compare February 6, 2023 12:02
This function being in core/xml.ts was the cause for the last
remaining circular import in core/ (between variables.ts and
xml.ts).

Moving it to utils/xml.ts makes sense anyway, since there is
nothing Blockly-specific about this function.

Fixes google#6817.
Reenable an assertion which check to make sure that
goog.declareModuleId is not called more than once in a module
(and which also catches circular imports amongst ES modules, which
are not detected by closure-make-deps).
@cpcallen cpcallen force-pushed the fix/6817-no-cyclic-imports branch from d0783af to f409de7 Compare February 6, 2023 13:02
Testing the migration file entry by auto-migrating all uses of
Blockly.Xml.textToDom to Blockly.utils.xml.textToDom.
Update the one remaining call to textToDom (in blocks/lists.ts)
to the function's new location - also removing the last use of
the Blockly.Xml / core/xml.ts) module from this file.
@cpcallen cpcallen marked this pull request as ready for review February 6, 2023 13:17
@cpcallen cpcallen requested a review from a team as a code owner February 6, 2023 13:17
@cpcallen cpcallen requested a review from gonfunko February 6, 2023 13:17
@cpcallen cpcallen removed the request for review from gonfunko February 6, 2023 16:21
core/utils/xml.ts Outdated Show resolved Hide resolved
Copy link
Collaborator

@rachel-fenichel rachel-fenichel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM once you fix conflicts.

@cpcallen cpcallen merged commit 167e265 into google:develop Feb 7, 2023
@cpcallen cpcallen deleted the fix/6817-no-cyclic-imports branch February 7, 2023 12:11
cpcallen added a commit to cpcallen/blockly that referenced this pull request Feb 8, 2023
Prior to PR google#6818, circular imports resulted in the debug module
loader (in closure/goog/base.js) failing to record the
goog.module ID of most modules that were
involved in the cycle, and in particular of the Blockly.Xml
module.  This had secondary fallout that resulted
in library blocks modules being loaded in the wrong order.

A kludge was introduced in PR google#6703 that worked around this
problem by making sure that window.Blockly was set, allowing
the modules loaded out-of-order to still work.

Now that we have removed all remaining circular dependencies
there is no need for the kludge, since all module IDs are
properly recorded and modules are loaded in the correct order.
cpcallen added a commit that referenced this pull request Feb 8, 2023
* chore(tests): Remove circular import loading issue kludge

  Prior to PR #6818, circular imports resulted in the debug module
  loader (in closure/goog/base.js) failing to record the
  goog.module ID of most modules that were
  involved in the cycle, and in particular of the Blockly.Xml
  module.  This had secondary fallout that resulted
  in library blocks modules being loaded in the wrong order.

  A kludge was introduced in PR #6703 that worked around this
  problem by making sure that window.Blockly was set, allowing
  the modules loaded out-of-order to still work.

  Now that we have removed all remaining circular dependencies
  there is no need for the kludge, since all module IDs are
  properly recorded and modules are loaded in the correct order.

* chore(build): Remove exclude for non-existent core/blockly.js

  There was a transitional period where we had both
  core/blockly.ts and core/blockly.js, and wished to exclude
  the latter from tsc's input, but the latter file was deleted
  (and inadvertently restored, then re-deleted) some time ago.
oszizsolt pushed a commit to oszizsolt/react-blockly that referenced this pull request Jul 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: chore General chores (dependencies, typos, etc) PR: refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make it possible to load Blockly directly from tsc-generated ESMs
3 participants