Fix module load order within internals-js/src/specs
directory using index.ts
module
#2924
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.
While attempting to write new tests in the
internals-js/src/specs/__tests__/
directory, I found some circularities in the import structure of theFeatureDefinition
subclasses, triggered by importing a different entry point module than usual.See for example this CI run which fails with the following error:
If you examine that stack trace, the crux of the problem is the
inaccessibleSpec.ts
module attempts to importFeatureDefinition
fromcoreSpec.ts
while thecoreSpec.ts
module is still being evaluated, soFeatureDefinition
has not been exported yet fromcoreSpec.ts
at the momentInaccessibleSpecDefinition
tries to extend it.I'll be the first to argue import cycles are not necessarily evil in JavaScript (ES2015+), but cycles do potentially lead to different module load order depending on which module you import first, and the
internals-js/specs/*Spec.ts
code is especially sensitive to load order because of synchronous use of imports likeFeatureDefinition
in module scope.There are some tricks for getting
extends FeatureDefinition
not to complain ifFeatureDefinition
is undefined (until the first instance of the subclass is created), but, based on some light internet research, a more robust solution is to fix the load order among the sensitive modules using aspecs/index.ts
module that re-exports everything from the other*Spec.ts
modules, and then make sure other code only imports from thatspecs/index.ts
module, rather than importing from individualinternals-js/specs/*Spec.ts
modules. Here's a good writeup of this approach.I'll be pushing commits incrementally so you can see the errors before/after I fix them.