Need advice regarding how best to contribute a universal binary js and possibly notiration js script(s) to the project

[markatosi]

I have these scripts to contribute AS-IS. I also will write documentation for them but I need to know where they should be placed in the repository as they are electron.net adjacent but not really part of the core project just something useful to have on hand if needed. The MakeUniversal.js is written now specifically for the new Electron.net though.

[softworkz]

Can you outline how this works?

Especially at what moment it needs to get invoked. If it requires two publish operations first and only works on the generated output afterwards, then I don't see a way to integrate it in a reasonable way, because a publish run is a top-level operation without any over-arching process which could invoke that script.
(but otherwise, chances are increasing at least..)

[markatosi]

This isn't anything that you would need or want to integrate into the electron.net build process per se and it's primarily useful as a scaffolding for how to build a production electron.net/blazor application as a universal binary to the apple macos app store. You would need to have an apple developer account to use this script properly. It uses another npm package that does the actual stitching of the intel and arm packages and signing the application so that is can be submitted.

So the work flow is you develop your application as usual using the blazor, electron.net tooling and when you want to submit to apple you can use the command node MakeUniversal.js to build your application. If someone wants to integrate that script with their own CI/CD process that's up to them but has nothing to do with electron.net. So this script is just a contribution for others to utilize if they have a need and don't want to re-invent the wheel.

[softworkz]

Understood, thanks for the explanation.

Then it would probably most suitable to have a sample app with this script included and instructions how to use, I suppose?

[markatosi]

My plan is to have instructions in the wiki how to build an apple universal app for distribution in the app store and place the script(s) in a directory called contrib/apple-universal. People could then read the wiki and have a link to the necessary files that they would incorporate into their local project folder. An example app is probably OK it's just the example apple would never work on their end without modification because of the need to provide their own apple profile file plus other apple developer specific things which will be different for each developer/company depending on how they are electing to build/distribute their application in the apple ecosystem.

[softworkz]

place the script(s) in a directory called contrib/apple-universal.

This might sound like a good idea from the perspective of someone who knows about it. But doing so is convoluting the project structure on one side and makes it difficult to discover on the other side. I've come across so many projects and so many times couldn't find what I was looking for until I - much later - accidentally found it in some corner I hadn't looked at, or hidden in some discussion).
I know that there is only moderate value for the sample per-se in this case, but there is value in having a consistent structure - just very stupidly:

Use case => sample
Use case => sample
Use case => sample

...rather than "this time, we do it this way" and "that time, we do it that way"

The sample itself will still build and that the script requires parameters in order to run should be clear anyway.

[softworkz]

Also - eventually - I still think that the samples should be published to a separate repository (always updated to the latest nuget packages versions). As a library consumer, you should not be required to clone the full source repo of the library, just to get sample code/apps.

[markatosi]

This sounds fine. I'll go the sample route but there still needs to be guidance via the wiki that people can use to understand what is going on under the hood, plus other helpful advice on how to setup their electron-builder.json file for publishing to the app store or ad-hoc. Apple makes this process arcane and frankly frustrating and throwing electron in the mix makes it all the more frustrating so if i lighten the load for someone regarding this process i'm happy to do so.

[FlorianRappl]

Wonderful - thanks a lot @markatosi. Much appreciated!

[softworkz]

here still needs to be guidance via the wiki that people can use to understand what is going on under the hood,

Right. Short hints in the sample, long explanation on the Wiki would be perfect.

[softworkz]

@markatosi - Here's something you might like (and probably others as well):

#987

[markatosi]

That is very very cool.

[markatosi]

As an update I have finally gotten the universal build script in a state that is usable by people other than me. I'll start work on the sample(s) soon. Although Tahoe is the last version of macOS that supports both intel and Arm the universal build will still be useful until apple decides they will no longer allow distribution of intel builds either in the app store or ad hoc. Development will be a problem for silicon mac owners trying to build intel distributions once they drop Rosetta but whatever... not like all the intel macs just cease to exist because apple says so.