fix(deps): Don't use global variables for jsdom injection in scripts/package/node/core.js and core/utils/xml.ts
#6764
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
PR: fix
Introduce a (hopefully generally applicable) mechanism for injecting dependencies into modules, specifically in this case to inject required bits of JSDOM's Window and Document implementations into core/utils/xml.js when running in node.js or other environments lacking a DOM. The injectDependencies function uses an options object to facilitate optionally injecting multiple named dependencies at the same time. Rename the xmlDocument local variable back to document (was renamed in RaspberryPiFoundation#5461) so that the name used in this module corresponds to the usual global variable it replaces. Change the injection in scripts/package/node/core.js to use injectDependencies instead of setXmlDocument + global variables; also eliminate apparently-unnecessary creation of a special Document instance, using the default one supplied by jsdom instead. Fixes RaspberryPiFoundation#6725.
Mark getXmlDocument and setXmlDocument as @deprecated, with suitable calls to deprecation.warn(). There are no remaining callers to either function within core - setXmlDocument was only used by the node.js wrapper, and and apparently getXmlDocument was never used AFAICT - and we do not anticipate that either were used by external developers.
cpcallen
force-pushed
the
fix/6725-jsdom-inject
branch
from
ce9547e to
678643a
Compare
BeksOmega
reviewed
Jan 12, 2023
BeksOmega
approved these changes
Jan 12, 2023
maribethb
approved these changes
Jan 12, 2023
gonfunko
pushed a commit
that referenced
this pull request
Jan 19, 2023
…/package/node/core.js` and `core/utils/xml.ts` (#6764) * fix(node): Don't use global variables for jsdom injection Introduce a (hopefully generally applicable) mechanism for injecting dependencies into modules, specifically in this case to inject required bits of JSDOM's Window and Document implementations into core/utils/xml.js when running in node.js or other environments lacking a DOM. The injectDependencies function uses an options object to facilitate optionally injecting multiple named dependencies at the same time. Rename the xmlDocument local variable back to document (was renamed in #5461) so that the name used in this module corresponds to the usual global variable it replaces. Change the injection in scripts/package/node/core.js to use injectDependencies instead of setXmlDocument + global variables; also eliminate apparently-unnecessary creation of a special Document instance, using the default one supplied by jsdom instead. Fixes #6725. * deprecate(xml): Deprecate getXmlDocument and setXmlDocument Mark getXmlDocument and setXmlDocument as @deprecated, with suitable calls to deprecation.warn(). There are no remaining callers to either function within core - setXmlDocument was only used by the node.js wrapper, and and apparently getXmlDocument was never used AFAICT - and we do not anticipate that either were used by external developers. * fix: Corrections for comments on PR #6764. (cherry picked from commit cd57e74)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The basics
npm run formatandnpm run lintThe details
Resolves
Fixes #6725.
Proposed Changes
Introduce a mechanism for injecting arbitrary dependencies into modules, specifically in this case
to inject required bits of jsdom's
WindowandDocumentimplementations intocore/utils/xml.jswhen running in node.js or other environments lacking a DOM.Rename the
xmlDocumentlocal variable back todocument(was renamed in Don't monkey-patchBlocky.utils.xml.documentin node module #5461) so that the name used in this module corresponds to the usual global variable it replaces.Change the injection in
scripts/package/node/core.jsto useinjectDependenciesinstead ofsetDocument+ global variables forDOMParserandXMLSerializer; also eliminate apparently-unnecessary creation of a specialDocumentinstance, using the default one supplied by jsdom instead.Mark
getDocumentandsetDocumentas@deprecated, with suitable calls todeprecation.warn().There are no remaining callers to either function within this repository—
setDocumentwas only used by the node.js wrapper, and apparentlygetDocumentwas never used anywhere—and we do not anticipate that either were used by external developers.Behaviour Before Change
If a runtime included multiple separate copies of the blockly package and its dependency jsdom, then XML serialisation and deserialisation would break.
Behaviour After Change
It is safe (but still not advisable) to load multiple separate copies of blockly and jsdom into the same runtime.
Reason for Changes
Fix #6725; allow tests in blockly-samples to pass after updating to Blockly v9.x (e.g. in RaspberryPiFoundation/blockly-samples#1452).
Test Coverage
npm testnpm link blocklyto include these changes.No changes in manual test procedures anticipated.
Documentation
No changes beyond automatic update including
@deprecationnotice.Additional Information
The
injectDependenciesfunction is intended to be a prototype for a generally applicable mechanism for dependency injection—for example, this approach could be used in other modules to break the circular dependencies that currently cause loading errors when trying to load Blockly viaimport * as Blockly from './build/src/core/blockly.js'without support from the Closure module tooling. As such, it uses an options object and destructuring-with-defaults to facilitate injecting arbitrarily-named dependencies either one-at-a-time or (as here incore.js) in bulk.