Open lukemelia opened 3 years ago
This sounds a lot like the issue that I fixed by making @glimmer/tracking an addon (https://github.com/glimmerjs/glimmer.js/pull/306) but your demo is already using @glimmer/tracking@1.0.3.
This sounds a lot like the issue that I fixed by making @glimmer/tracking an addon (glimmerjs/glimmer.js#306) but your demo is already using @glimmer/tracking@1.0.3.
I tried it with 1.0.4 as well and the behavior is the same.
@rwjblue making glimmer/tracking an empty addon will help with the auto-import case, but yeah, it's going to break embroider.
@glimmer/tracking
looks like a good candidate for conversion to a v2 addon. That would solve both builds.
Oh, I'm remembering more about why glimmer/tracking works like it does. Under ember it actually does nothing, right? The real implementation is in Ember itself. The stuff in the real package is for glimmerjs only.
The problem here is that it's neither entirely virtual (like @ember/component
) nor entirely real (like @glimmer/component
). It's trying to be both, and that's just... too weird.
I think it would be easiest to give it a real implementation, even that implementation just looks up the one from ember and returns it, like:
// @glimmer/tracking/addon/index.js
try {
// on ember > 3.27 there's a real module
return window.require('@glimmer/tracking')
} catch (err) {
return Ember._tracked;
}
hello @lukemelia doing a little housekeeping here and wondering if this is still an issue or if it can be closed
With embroider (0.37), ember beta 3.27.0-beta.1, and ember-cli-babel >= 7.24.0...
The @glimmer/tracking module is output into the intermediate build directory without any javascript and the build then fails when your app code tries to
import { track } from '@glimmer/tracking';
.Minimal reproduction: https://github.com/lukemelia/tracking-build-issue-with-ember-beta