Rethink dependency cycles

[Profpatsch]

yarn/npm modules can have circular dependencies on each other.

Wtf, you might think, how is that even possible?

When A.js loads B.js, then B.js in turn loads C.js. At this point, C.js tries to load A.js. In order to prevent an infinite loop, an unfinished copy of the A.js exports object is returned to the C.js module. C.js then finishes loading, and its exports object is provided to the A.js module.
(source)

This is incredibly worrying in many ways, but 👁️👄👁️

So my thinking here is:

• In case both modules import each other directly at the top of each module one module will be empty anyway, so removing the cycle (in the right way) should be semantically equivalent
• Not sure if that holds for bigger cycles? Probably.
• In every other case, it sucks.

So there’s multiple ways we can solve for it here:

1. Unconditionaly remove cycles (current behaviour). Turn the graph into a dag, then work on the dag as usual. This might be ok in many cases, maybe js devs are just lazy and don’t understand how dependencies work, so it somehow works even though it’s not what they wanted to do semantically.
2. Maybe they actually want a fixpoint over their modules (and who doesn’t love fix points cough nixpkgs cough), and are using them in a ‘smart’ way that doesn’t lead to infinite recursions (or broken code with npm’s resolution mechanism).
   In that case we need to change yarn2nix, to find all strongly connected components in the graph, and merge them together them in a single derivation in a smart way.

At least I have written down the problem now, so I can sleep well again.