Diagnosing a broken addon build, floating dependencies

@samselikoff wrote:

Ember CLI Mirage’s master build has been broken for a bit and I’m trying to fix it. The failure is specific: it’s in one of our FastBoot tests, running on a “floating dependencies” scenario. Here’s the build, and you can see “node tests” under “floating dependencies” is the job that’s failing. Here’s the actual failure.

Floating dependencies are hard to debug, because if you get a test failure, how do you know what has changed between that and the working build? The only way is to rm yarn.lock && yarn install && git diff.

If I do that, I get this diff:

https://gist.github.com/samselikoff/357eae2ff9c10875a5f5aa696f18f36f

It’s 8400 lines long! That’s a lot of changes in dep versions between master's yarn.lock file and one that would be generated if yarn install --no-lockfile were run today.

My next idea was to look back at the most recently passing master build, which is here. It ran 25 days ago. The problem is, the yarn.lock in that commit doesn’t represent the dependency graph of yarn install --no-lockfile as of then; it represents the last time we updated the lockfile. What I really want is to compare the dependency graph generated via yarn install --no-lockfile as of 25 days ago, with the dependency graph that you’d get if you ran yarn install --no-lockfile as of today.

Any way to do this?

(I found this issue that references a years-old fork of npm with the functionality, but it looks like it never went anywhere.)

Any other debugging tips? I’m kinda at a loss for how to proceed…

Posts: 8

Participants: 2

Read full topic