Peer dependencies are not met correctly with some being circular

[DCzajkowski]

I've found these issues:

1. There is a circular dependency chain: app-builder-lib -(via devDependencies)-> dmg-builder -(via dependencies)-> app-builder-lib
2. dmg-builder uses app-builder-lib which has electron-builder-squirrel-windows in peer dependencies. This means, that dmg-builder should declare electron-builder-squirrel-windows as its dependency or peer dependency.
3. electron-builder uses app-builder-lib which has electron-builder-squirrel-windows in peer dependencies. This means, that electron-builder should declare electron-builder-squirrel-windows as its dependency or peer dependency.
4. electron-builder-squirrel-windows uses app-builder-lib which has dmg-builder in peer dependencies. This means, that electron-builder-squirrel-windows should declare dmg-builder as its dependency or peer dependency.

I think resolving the circular dependency (1) would help with fixing 2/4. However, 2/3/4 can be fixed without fixing 1 by adding peer dependencies as follows:

dmg-builder:
  peerDependencies:
    electron-builder-squirrel-windows
electron-builder:
  peerDependencies:
    electron-builder-squirrel-windows
electron-builder-squirrel-windows:
  peerDependencies:
    dmg-builder

[DCzajkowski]

I was trying to resolve those issues, but I can see this is intentional and it's hard to remove the cyclic dependencies with current architecture.

If I understand the problem better, I think we can come up with a better solution.

What is the reason for having dmg-builder a separate package?

[mmaietta]

Yeah, I've tried to resolve them as well a few times in the past but kept getting stuck with how app-builder-lib pulls from multiple packages, but then is needed by upstream or sub- dependencies. I kept getting back to the same problem of maintaining backward compatibility with external APIs.

I'm not sure if it was intentional, as it far predates me joining this project. I'm open to rearranging in the next major release that I'm currently prepping.

I believe dmg-builder is separate because it is mac-only logic and also with mac-specific deps like "dmg-license", so I guess it was in the spirit of functional isolation.

[DCzajkowski]

Thank you for the answer!

I believe dmg-builder is separate because it is mac-only logic and also with mac-specific deps like "dmg-license", so I guess it was in the spirit of functional isolation.

This makes sense. However, all other one-OS-only targets are inside the main package.

I think there are three approaches that can be taken:

1. Extract all targets to separate @electron-builder/target-{dmg,nsis,msi,...} packages and shift the need to pull them in by consumers. However, this only makes sense if it actually reduces the pulled in size by much. If the difference is marginal, I think it would be better to:
2. Keep everything in a single package.
3. Keep the structure as-is, but extract common types to a separate internal package, that all packages can import from without cyclic deps.