embroider: `Build Error (PackagerRunner) in node_modules\@glimmer\tracking\index.js`

Embroider 1.2 & @cached which doesn’t work. because the fix for @cached was added in embroider 1.2.0

these statements seem to be in conflict 🤔

Looking at the changelog: https://github.com/embroider-build/embroider/blob/main/CHANGELOG.md I don’t see the fix you’re talking about in 1.2, but do see it in 1.1: https://github.com/embroider-build/embroider/blob/main/CHANGELOG.md#v110-2022-02-08 (I also typo’d the PR title 😅 )

I was playing around with your reproduction – want to show my debugging process:

1. have sourcemaps turned on, because webpack output is not human-friendly. (I’m using devtool: 'source-map')

2. search for glimmer/tracking in chrome (or firefox) this shows that we have @glimmer/tracking as one of our AMD modules, so that’s good – we should be able to import it.

3. as I scroll through the search results though, I see that something is pulling in the cached-decorator-polyfill we don’t want this.

4. running npm list ember-cached-decorator-polyfill

   ❯ npm list ember-cached-decorator-polyfill
   embroider-cached@0.0.0 <repo>
   └─┬ ember-data@4.1.0
     ├─┬ @ember-data/model@4.1.0
     │ └── ember-cached-decorator-polyfill@0.1.4
     └─┬ @ember-data/store@4.1.0
       └── ember-cached-decorator-polyfill@0.1.4 deduped}
   

   so it’s from ember-data, I figure, “for testing”, let’s see what happens when we remove ember-data so that we get rid of the polyfill

5. after removing ember-data and confirming that the polyfill is gone via npm list ember-cached-decorator-polyfill, the problem persists – so that means the decorator is not a function error has nothing to do with the polyfill.

6. I wanted to check to make sure all your @embroider/* deps were the correct version

   ❯ cat node_modules/@embroider/addon-shim/package.json | jq '.version'
   "0.50.2"
   

   oh! that’s problematic! Let’s try to force everything to be v1.2.0 I kinda got lucky with checking addon-shim first, but you can check everything at once with a glob:

   ❯ cat node_modules/@embroider/*/package.json | jq '.name,.version'
   "@embroider/addon-shim"
   "0.50.2"
   "@embroider/babel-loader-8"
   "1.2.0"
   "@embroider/compat"
   "1.2.0"
   "@embroider/core"
   "1.2.0"
   "@embroider/hbs-loader"
   "1.2.0"
   "@embroider/macros"
   "1.2.0"
   "@embroider/shared-internals"
   "1.2.0"
   "@embroider/webpack"
   "1.2.0"
   

   So, I already kinda cheated and pinned some of these already (due to other similarly reported issues), so my results may not match yours exactly. But, This is what you’d do:

   for npm (v8+):

     "overrides": {
       "@embroider/addon-dev": "^1.2.0",   
       "@embroider/compat": "^1.2.0",
       "@embroider/core": "^1.2.0",
       "@embroider/macros": "^1.2.0"
     },
   

   however, I ran in to this: https://github.com/npm/cli/issues/4232 so, I can’t use npm, apparetly You could use older techniques with npm, if you’re stuck on npm, with something like https://www.npmjs.com/package/force-resolutions

   buuuut, for yarn (v1):

     "resolutions": {
       "@embroider/addon-dev": "^1.2.0",   
       "@embroider/compat": "^1.2.0",
       "@embroider/core": "^1.2.0",
       "@embroider/macros": "^1.2.0"
     },
   

   buuuuut after installing yarn, I still have addon-dev 0.50.2, something else is fishy.

7. Why do we have an old dependency potentially throwing things off?

   ❯ yarn why @embroider/addon-dev
   => Found "@embroider/addon-shim@0.50.2"
      - "ember-welcome-page" depends on it
      - Hoisted from "ember-welcome-page#@embroider#addon-shim"
   

   Let’s remove the welcome-page. It’s not meant to live in app passed the “introduction” anyway. (for ember veterans, it can be skipped with --no-welcome during app generation)

   However, I realize now that I’ve been confusing @embroider/addon-dev with @embroider/addon-shim 😩

8. Go back to step 6, except specify addon-shim instead of addon-dev… and forget about the famous X/Y problem. (As an aside, removing ember-welcome-page does fix the versioning issue, but it’s not the correct fix).

   But now I get this error:

   Build Error (PackagerRunner) in app.js
   
   Module not found: Error: Can't resolve '<repo>/node_modules/@embroider/core/node_modules/@babel/runtime/helpers/esm/defineProperty.js' in '$TMPDIR/embroider/afd5f2/app.js'
   

   So, I need to clear /tmp/embroider. But that didn’t work (same module not found error about babel/runtime). So I’m going to reset / revert all my work and start over with just the overrides/resolutions addition to package.json Success! I’m back to decorator is not a function. Now let’s switch to yarn, as addon-shim is still 0.50.2 Switching to yarn brings back Can't resolve (babel runtime). So… idk what that’s output. I don’t think yarn does nested node_modules? so 🤷 I switch to pnpm, but the decorator is not a function issue is still there.

   What’s interesting is that pnpm, seems to be better and not leaking transitive dependencies to the root node_modules

   ❯ cat node_modules/@embroider/*/package.json | jq '.name,.version'
   "@embroider/compat"
   "1.2.0"
   "@embroider/core"
   "1.2.0"
   "@embroider/webpack"
   "1.2.0"
   

   I don’t know what that means for runtime, 🤷

9. This has gotten a bit ridiculous, I need to step back a bit. Looking again at the @glimmer/tracking module: It’s aliasing @ember/-internals/metal, so let’s go look at that file It’s a big list of exports assigned to some _exports variable in this module. So, let’s see if cached is anywhere in this file (it’s pretty big – I think it’s all of the metal package).

   This is suspicious: but there are more results to look at – this could just be some initialization step for assignment later.

   Ok, here is the decorator: So… it does exist, and is a function.

   So now I’m going to setup some break points in that getter in @glimmer/tracking, and see what value it’s looking at. These breakpoints were never hit.

   Placing a breakpoint in application.js (where @cached is used): reveals the following: @glimmer/tracking doesn’t have the @cached getter… but why?! which @glimmer/tracking is it looking at? clicking the FunctionLocation reveals: _which is the same file we checked earlier to see if cached was exported…

   So now I want to debug the compat package which has the code for the supposed @cached fix… Adding two debuggers, and launching ember s with the JavaScript Debug Terminal

   but, I don’t actually need to run the dubugger (yet), because I think I found the problem): cached is not exported from this fake file.

   Editing that to: Fixes the issue.

   And here is a PR: https://github.com/embroider-build/embroider/pull/1135

Thanks for reporting!!!

@NullVoxPopuli thank you for this step by step debugging & PR 🙃. Wunderful

I hope every PR could have a step-by-step debugging / developing process like what @NullVoxPopuli did here, wonderful!