Export MacPackager class and TypeScript types for codeSigningInfo in AfterPackContext

[jtbandes]

• Version: 22.11.7
• Electron Version: 13.1.2
• Electron Type (current, beta, nightly): current
• Target: macOS

An afterPack script that needs access to the temporary keychain created by MacPackager is able to access it via (await context.packager.codeSigningInfo.value).keychainFile. However, in TypeScript, context.packager is a generic PlatformPackager<any> so this requires awkward type casting (example in https://github.com/foxglove/studio/pull/1270).

It would be nice if the MacPackager class itself, or some sanctioned way of accessing the keychainFile, could be exported from the package's TypeScript definitions.

Workaround: the types for MacPackager can be imported via import type MacPackager from "app-builder-lib/out/macPackager"; but this seems to be an implementation detail. Guarding with context.packager instanceof MacPackager would require a full import from this non-standard path (not just import type) which seems like a bad idea if it's not an official export!

[mmaietta]

That's a great callout.
I'd be happy to accept a PR for this change! Instructions are fairly simple to set up a dev env 🙂
https://github.com/electron-userland/electron-builder/blob/master/CONTRIBUTING.md#to-setup-a-local-dev-environment

[jtbandes]

Thanks, I can try to find a little spare time to work on this. Do you have any thoughts on the best approach? For example: exposing codeSigningInfo? on all packagers, exposing a packager "type" that can be used to safely typecast in TS, exporting the MacPackager class itself so clients can use instanceof, or some other solution?

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jtbandes]

@mmaietta This issue is still relevant for us – if you have some guidance on these questions I'd be open to making a PR!

[mmaietta]

I see two routes I suppose?

• I export MacPackager, LinuxPackager, and WinPackager explicitly from app-builder-lib
• OR
• You continue to use it as an export directly via app-builder-lib/out/xxx.

Or am I misunderstanding your post?

If you're worried about the API changing, I have no intention of doing so. Additionally, if you were to explicitly pin the dependency version in your package.json, you wouldn't need to worry about it randomly breaking when an electron-builder update were to be released.

[jtbandes]

Partly, I would like to avoid importing from app-builder-lib directly. Importing it directly does work, but causes trouble with Dependabot wanting to bump the version of app-builder-lib independently of the version of electron-builder, which sometimes leads to incompatibilities. That's why I was thinking it would be ideal if the types were exported from electron-builder (the package that users actually use directly).

[mmaietta]

Great feedback and clarification. I'll export the classes directly via the main electron-builder typings. PR #8153

[jtbandes]

❤️ thanks! I guess I could’ve included that detail in the original ticket 😅

[jtbandes]

Additionally, we are currently importing log and Arch from builder-util inside an afterPack script, and I’d love to be able to get rid of those imports too. Let me know if you have any advice for those (I don’t think they were exported elsewhere)

[mmaietta]

Wait, just to confirm. Are you also looking for the AfterPackContext have an explicit typing as to what the packager is?

I'm wondering if we change the property signature to be a nested and have access to the specific Packager class based on which packager property is populated. Thoughts?

No matter what, I can't seem to be able to avoid having you do a force-cast in your code, as the packContext is heavily used elsewhere in the code for detecting platform and the like within other logic flows that don't have access to which type of packager is being returned. Still investigating further

  readonly packager: {
    packager: PlatformPackager<any>
    type: 'WinPackager' | 'MacPackager' | 'LinuxPackager'
  }

[mmaietta]

Additionally, we are currently importing log and Arch from builder-util inside an afterPack script

Also, Arch is already exported via electron-builder directly. I can update my PR to do the same for log

[jtbandes]

The main thing I was trying to access was the keychainFile from codeSigningInfo on mac. Having an ability to explicitly check the platform could make sense, though it's not required as long as I can do something like instanceof MacPackager...

https://www.typescriptlang.org/play?#code/IYIwzgLgTsDGEAJYBthjAgCqiAzA9lALaZwDWwA5gKZQA8AIgMIB8CA3gFAC+nnKaDAFk4pWBRpQE1AB4RqAOwAmGbMDyES5KrToBXBWQX4A7grZcECJfhGwAyhD25cACgCUHXrwHoEAGQBLBT0ZMQlaaTlFFSwcAmJwnXoDI1NzDgQfVD8AdWCkySj5ZVV4zULdVOMzCyy+WQAHQkQlagEoamkQogQAQShYAAsOTisrQOAAZgAmBABeBAAGABox8ZkANgAWBYQARjXxhGBiADcAdmQ9maPx06Idvam7qwNAs9owYGvF7Z5OBAAJ6NLpqDSJchMfAKeRyPbrAA+mU6wBsCmQQOkyHa0Bh4ISRAAcsAiNQAFwIABESlOJmCVIQyKpRDQVIA3AhUejMQhGtpJJS7JUoJzeFZkewudQ0TDedQcfAoPjysQSWTKVTkMFQhzpbKMVj+eJkpSgiEwgLaGKkSiZTysQrccqFATNOqKdT6QpZnruXKjVaoGadZaTZIbYCQWCoTC4YhFm7IeJobDZIgAGSjY7+w0IfB6CAMQLBhCQKDBSjs9ZWXO84CNRoAeULxdL5cr1Zz9oDJ0GQ0pA2G1d4nFwBnggRhJ1w8ig4Vc8BklPCqfjnksCECuAQi4gMgAdE6lSr1ISPQt5osAOS0qDe68bmtIfcH40RKAHmx2RzONzuLt6m4IA