Closed mkszepp closed 1 year ago
do you have a reproduction readily available?
I've successfully used @cached
in v2 addons 🤔
@NullVoxPopuli here a simple repo with Ember 4.1, Embroider 1.2
& @cached
which doesn't work.
https://github.com/mkszepp/embroider-cached
With this repo there is possible to reproduce: https://github.com/embroider-build/embroider/issues/1086#issuecomment-1044028028
When i add ember-cached-decorator-polyfill
in this repo, the @cached
decorator works, but i think i get as side effect after x-rebuilds the error from this issue.
With Embroider <=1.0.0
& Ember 4.1
, i have got no problems with the @cached
decorator since now (works everything without problems, but the polyfill is necessary otherwise it doesn't work because the fix for @cached
was added in embroider 1.2.0
)
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:
have sourcemaps turned on, because webpack output is not human-friendly. (I'm using devtool: 'source-map'
)
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.
as I scroll through the search results though, I see that something is pulling in the cached-decorator-polyfill we don't want this.
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
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.
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.
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
😩
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, 🤷
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!!!
In hindsight, I probably should have started with the compat code. 🙃
I hope every PR could have a step-by-step debugging / developing process like what @NullVoxPopuli did here, wonderful!
@NullVoxPopuli thank you for this step by step debugging & PR 🙃. Wunderful
fix was released in embroider 1.3
bad news... now with embroider 1.4 @cached
decorator works without polyfill, but the error from this issues was not solved 😢
the files is really missing in TMP folder... folder when there is the bug:
folder when it works:
did you delete /tmp/embroider
?
@NullVoxPopuli i have now manually removed the /tmp/embroider
folder & i will try it
@NullVoxPopuli after some changes i was running in the same error 😢
do you have a reproduction?
i will try to create a repository, which i can share you... but i think, its difficult...
@NullVoxPopuli with new repo there is not possible to reproduce, but i have something found out: This bug is not only, when i save a file & i have found a way how can i reproduce it in my repo.
I'm working on Windows 10 x64 with VSCode. Sometimes (not always) when i open a file in VSCode (from the VSCode tree), ember starts a rebuild (i think windows is changing a timestamp in this situation and a rebuild starts) When i open files from the tree, while he is building, this error appreas. Looks like a timeing problem or file lock while create/remove... The simplest way to reproducte was, to open the complete tree and clicking step by step all files in the tree.
My repo is already a little bit larger (+- 3 secounds for a rebuild).
Maybe you have a large repository, so you can try it to reproduct it with them, otherwise i must create a repo with x-components...
are you using WSL-2?
no, at the moment i'm working directly in windows with powershell, but there is planned to switch to WSL-2, because its faster and also recommended from ember
I think we can close this issue for now.
If anyone has a similar error, please open a new issue <3
Ember: 4.1.0 Embroider 1.2.0 OS: Win 10
Sometime after file changes the build fails.
The only fix is to stop and restart ember serve. This bug cames randomly after x file changes
We use
ember-cached-decorator-polyfill
because@cached
doesn't work with the latest embroider versionMaybe related: https://github.com/embroider-build/embroider/issues/1086#issuecomment-1044028028
Looks like the path is wrong?
ENOENT: no such file or directory, open '$TMPDIR\embroider\a1864e\node_modules\@glimmer\tracking\index.js\index.js'