Repository navigation
TDZ ReferenceError with 2.0.0-beta.8 #302
Description
I was playing with updating the GlimmerX packages to use the recent 2.0.0-beta.8 release here (still on my sisyphean quest to escape the MonomorphicTagImpl type error), but its test suite no longer boots. While the module graph is initializing, an error is thrown along these lines:
ReferenceError: Cannot access 'scheduled' before initialization
at scheduleRevalidate (webpack:///./node_modules/@glimmer/core/dist/modules/src/render-component/index.js?:54:3)
at dirtyTag (webpack:///./node_modules/@glimmer/core/node_modules/@glimmer/validator/dist/modules/es2017/lib/validators.js?:193:87)
at eval (webpack:///./node_modules/@glimmer/core/node_modules/@glimmer/validator/dist/modules/es2017/lib/validators.js?:256:1)
at Module../node_modules/@glimmer/core/node_modules/@glimmer/validator/dist/modules/es2017/lib/validators.js (http://localhost:7357/9903/dist/tests.bundle.js:649:1)
at __webpack_require__ (http://localhost:7357/9903/dist/tests.bundle.js:20:30)
at eval (webpack:///./node_modules/@glimmer/core/node_modules/@glimmer/validator/dist/modules/es2017/index.js?:3:73)
at Module../node_modules/@glimmer/core/node_modules/@glimmer/validator/dist/modules/es2017/index.js (http://localhost:7357/9903/dist/tests.bundle.js:577:1)
at __webpack_require__ (http://localhost:7357/9903/dist/tests.bundle.js:20:30)
at eval (webpack:///./node_modules/@glimmer/core/dist/modules/src/utils/autotracking.js?:3:76)
at Module../node_modules/@glimmer/core/dist/modules/src/utils/autotracking.js (http://localhost:7357/9903/dist/tests.bundle.js:481:1)
This turns out to be a TDZ error, where scheduleRevalidate is seemingly called before that point in the module body has actually been executed:
glimmer.js/packages/@glimmer/core/src/render-component/index.ts
Lines 84 to 88 in c168354
Poking around a little bit, I'm not positive what the problem is, but there's a suspicious circular dependency between the core/src/environment/delegates module and core/src/render-component. The top of the stack when the error occurs is this module-scope warmup code in @glimmer/validator, which also points toward a circular dependency/half-instantiated-module problem.
My guess is that this is sensitive to the order modules are resolved in, which would explain why it hasn't cropped up in the tests in this repo, but here's the GlimmerX branch where I ran across this:
glimmerjs/glimmer-experimental@master...dfreeman:update-glimmer-dependencies
Activity
rwjblue commentedon Sep 8, 2020
@pzuraq - Have any time to poke at this?
john-griffin commentedon Sep 8, 2020
I see this error when booting a fresh app after running
ember new glimmer-app --blueprint @glimmer/blueprint@2.0.0-beta.8.lifeart commentedon Sep 16, 2020
looks like it's may be fixed by #305
pzuraq commentedon Sep 17, 2020
it seems like something odd is happening due to the fact that we don't pin to an exact version of packages in the VM, but do here. We should probably start pinning exact versions everywhere, where it matters.