All ember-source modules missing from a build

Seems that all modules from ember-source end up missing from /assets/my-app.js and the build fails with errors like these:

ERROR in ./components/-dynamic-element-alt.js 1:0-41
Module not found: Error: Can't resolve '@ember/component' in '$TMPDIR\embroider\889da1\components'
 @ ./assets/my-app.js 383:13-62
 
ERROR in ./components/badge.js 1:0-67
Module not found: Error: Can't resolve '@ember/component/template-only' in '$TMPDIR\embroider\889da1\components'
 @ ./assets/my-app.js 395:13-47

I understand that’s a pretty vague error description, so maybe someone familiar with the source code could provide some pointers as to what to check, e.g. where this list of modules in my-app.js gets created, so that I can start debugging from there.

Thanks.

compat build, require(‘@embroider/compat’).compatBuild(app, Webpack); ember-source: 4.3.0-alpha.3 ember-cli: 4.2.0-beta.1 node: 14.16.1 os: win32 x64

[NullVoxPopuli]

I’m gonna log how I’m trying to debug this in this comment. (I’ll be updating the comment instead of adding more posts as I figure things out).

---

The original error I got ended with

16 errors have detailed information that is not shown.
Use 'stats.errorDetails: true' resp. '--stats-error-details' to show it.

But adding that to the webpack config (in my autoImport config at the time of debugging) had no effect, so I assume the stats option isn’t being merged. Instead, I catd the full error log and placed a breakpoint in webpack here:

For me, this error appears when I’m running node_modules/.bin/ember test. So I must use VSCode’s JavaScript Debug Terminal, which attaches itself to all spawn sub-processes. Very nice. (Though, I have to close the default terminal and re-open JavaScript Debug Terminal from the command pallet when I start VS Code.

Success: breakpoint hit, now I can walk the stack backwards and poke around for useful information.

The main thing I’m looking for is. Where did webpack even look for these packages? On disk, they all exist at node_modules/ember-source/dist/packages/… so… why didn’t webpack look there?

---

Going up the stack, I only make it to here before the stack devolves into only enhanced-resolve frames. So, I’ve set a new breakpoint so I don’t have to crawl back up here, and I can poke around in this file for what resolver is and figure that out (I need to find where the callback is called without all the enhanced-resolve stuff).

I see that at the top of the function with this new breakpoint, resolver is passed in. So I’m placing a breakpoint at the top in case I can catch it before enhanced-reslove steps in: At this point though, I need to kill my current ember test execution and start over, clicking “continue” in the debugger controls kept hitting my other breakpoints, so I think this _resolveResourceErrorHints is called earlier. The name also implies the error has still already happened, and all this code is just for printing the error (and trying to help out the dev)

Hitting that breakpoint, and going up the stack a frame brings me here: So now I’m going to repeat the process and see what’s calling resolveResource’s resolver.resolve callback. Variables that look potentially interesting right now are context, contextInfo, and resolveContext

I’m also gonna start needing conditional breakpoints based of the missing package name, because I’m getting in to area of webpack where the success path is the common path, and I don’t want to debug what’s working (yet?)

I’ve gotten to the top of where NormalModuleFafctory starts its thing, and I don’t feel like I’m able to discern anything meaningful. So now I need to do this some process but for a project that is resolving @ember/template-factory (and most of the @glimmer/* and @ember/* packages) – but my wrist hurts, so I gotta take a break.

Hope this helps someone!

[NullVoxPopuli]

as it is in node_modules

this is the kicker, you can’t guarantee it is, because how node_modules is organized is an implementation detail of the package manager. in both yarn@v1 and npm (which have broken dependency management techniques, though npm@8 is quite a bit better), the will shove everything flatly into node_modules – this gives you the illusion that you can import your transient dependencies. What yarn3, pnpm, and npm@8 (with strict settings still enabled) do is manage deps correctly, in that you can only import what is declared in your package.json (be that via nested node_modules, or whatever other technique they’re implementing).

This isn’t an emborider issue – embroider is following the correct resolution algorithm, in that it doesn’t re-implement bugs that yarn@v1 and older npm contain