Document custom_main.js #1018

New Issue

claunia · 2026-01-29T16:55:17Z

claunia commented

2026-01-29 16:55:17 +00:00

Originally created by @softworkz on GitHub (Nov 20, 2025).

Document the possibility of adding a custom_main.js file which will be execute before Electron initialization

Provide a sample.

Maybe we should create a new repositoty for publishing app samples.
(and eventually mark the current ones as archived)

Originally created by @softworkz on GitHub (Nov 20, 2025). Document the possibility of adding a custom_main.js file which will be execute before Electron initialization Provide a sample. Maybe we should create a new repositoty for publishing app samples. (and eventually mark the current ones as archived)

claunia added the help wanted Feature documentation good first issue labels 2026-01-29 16:55:17 +00:00

claunia closed this issue

2026-01-29 16:55:18 +00:00

claunia commented

2026-01-29 16:55:18 +00:00

@niteshsinghal85 commented on GitHub (Dec 6, 2025):

Hi @FlorianRappl , @softworkz

I’m interested in working on this issue and contributing for a sample/documentation about usage of custom_main.js.
Before I start implementation, I’d like to confirm your expectations:

Should the sample be part of a new repository (as you suggested), or integrated into the existing docs?
Do you envision a minimal example (just showing custom_main.js usage), or a more complete app sample?
Are there specific scenarios you’d like highlighted (e.g., environment variables, preload scripts, logging)?

Once I have your guidance, I’ll be happy to start drafting the sample and documentation.

Thanks!

@niteshsinghal85 commented on GitHub (Dec 6, 2025): Hi @FlorianRappl , @softworkz I’m interested in working on this issue and contributing for a sample/documentation about usage of `custom_main.js`. Before I start implementation, I’d like to confirm your expectations: - Should the sample be part of a new repository (as you suggested), or integrated into the existing docs? - Do you envision a minimal example (just showing `custom_main.js` usage), or a more complete app sample? - Are there specific scenarios you’d like highlighted (e.g., environment variables, preload scripts, logging)? Once I have your guidance, I’ll be happy to start drafting the sample and documentation. Thanks!

claunia commented

2026-01-29 16:55:19 +00:00

@softworkz commented on GitHub (Dec 6, 2025):

Thinking about it more, I see two sides:

From a user perspective, it would be desirable when there's a separate repo with a collection of samples, ideally versioned, so that the samples are matching a specific release and already have the corresponding nuget packages configured
But for developing and managing the samples it would be much better when they are part of the main repo, so that they can be updated and tested in parallel with development. Otherwise we might end up again with outdated samples (like now)

So, maybe we should do both: Have the samples in the main repo and on every release, we copy them over to a samples repo, where we are creating a new branch for each release - so users will be able to use the branch selector in the samples repo to choose the version for which they want to get samples.

This would also give us freedom to add or drop samples without causing any confusion. What I mean is for example, a sample like this: https://github.com/ElectronNET/electron.net-musicplayer-sample which is no longer maintained can be removed and it's just no more visible (as long as somebofy would switch to an old versiion branch in the samples repo.

@softworkz commented on GitHub (Dec 6, 2025): Thinking about it more, I see two sides: - From a user perspective, it would be desirable when there's a separate repo with a collection of samples, ideally versioned, so that the samples are matching a specific release and already have the corresponding nuget packages configured - But for developing and managing the samples it would be much better when they are part of the main repo, so that they can be updated and tested in parallel with development. Otherwise we might end up again with outdated samples (like now) So, maybe we should do both: Have the samples in the main repo and on every release, we copy them over to a samples repo, where we are creating a new branch for each release - so users will be able to use the branch selector in the samples repo to choose the version for which they want to get samples. This would also give us freedom to add or drop samples without causing any confusion. What I mean is for example, a sample like this: https://github.com/ElectronNET/electron.net-musicplayer-sample which is no longer maintained can be removed and it's just no more visible (as long as somebofy would switch to an old versiion branch in the samples repo.

claunia commented

2026-01-29 16:55:19 +00:00

@FlorianRappl commented on GitHub (Dec 6, 2025):

Should the sample be part of a new repository (as you suggested), or integrated into the existing docs?

I agree with @softworkz but to keep things simple let's integrate them in this repo to the existing docs.

Do you envision a minimal example (just showing custom_main.js usage), or a more complete app sample?

Minimal is sufficient in my opinion. However, the more you like to show / document the better.

Are there specific scenarios you’d like highlighted (e.g., environment variables, preload scripts, logging)?

I have nothing in my mind (env. variables is a great scenario to cover), so you have as much freedom as you like.

@FlorianRappl commented on GitHub (Dec 6, 2025): > Should the sample be part of a new repository (as you suggested), or integrated into the existing docs? I agree with @softworkz but to keep things simple let's integrate them in this repo to the existing docs. > Do you envision a minimal example (just showing custom_main.js usage), or a more complete app sample? Minimal is sufficient in my opinion. However, the more you like to show / document the better. > Are there specific scenarios you’d like highlighted (e.g., environment variables, preload scripts, logging)? I have nothing in my mind (env. variables is a great scenario to cover), so you have as much freedom as you like.

claunia commented

2026-01-29 16:55:20 +00:00

@niteshsinghal85 commented on GitHub (Dec 6, 2025):

@FlorianRappl
ok then I start working on this.

@niteshsinghal85 commented on GitHub (Dec 6, 2025): @FlorianRappl ok then I start working on this.

claunia commented

2026-01-29 16:55:20 +00:00

@softworkz commented on GitHub (Dec 6, 2025):

A good example for a use case might be the case that had recently been brought up, which is about registering protcol handlers (like custom://abcde). This has to be done before initialization of the Electron app.

Another example would be about setting up a telemetry provider (like Sentry), which also needs to be done (1) early and (2) at the node.js side.

Do you envision a minimal example (just showing custom_main.js usage), or a more complete app sample?

Minimal is sufficient in my opinion. However, the more you like to show / document the better.

I agree and I would even say that a good sample is always minimal in general. While it can be more complex in the topic that it demonstrates, everything aound that is unrelated must be as minimal as possible and should not use any other patterns - which might be elegant and useful - but they never are for the one who is interested in the topic of the sample - such things are just a distraction.

It's much better to have many samples, each of which demonstrating one specific featuie or usage, than a huge all-in-one sample where a new user would have no clue where one feature ends and another one starts in the code.

@niteshsinghal85 - if you'd like to do a bit more, I'd have ideas for a number of other interesting samples:

How to inject a Preload Script
e.g. for setting up IPC messaging between web content and .net ap
Build Customization via electron-builder hook scripts
like beforePack, afterPack, artifactBuildStarted, artifactBuildCompleted
This allows for example to manipulate or replace the *.desktop file for Linux apps
A comprehensive sample for electron-builder.json
That's something you can hardly find anywhere...
Multi-Project Example
How you can have a base project with Electron.NET code that is shared by multiple Electron.NET apps
ElectronHostHook Sample
A sample project, showing just ElectronHostHook without any distractions
App Icons Sample
A working sample with icons for all 3 platforms (Win, Linux, Mac)

(for most of them, I can provide something based on which a sample can be created)

@softworkz commented on GitHub (Dec 6, 2025): A good example for a use case might be the case that had recently been brought up, which is about registering protcol handlers (like `custom://abcde`). This has to be done before initialization of the Electron app. Another example would be about setting up a telemetry provider (like Sentry), which also needs to be done (1) early and (2) at the node.js side. > > Do you envision a minimal example (just showing custom_main.js usage), or a more complete app sample? > > Minimal is sufficient in my opinion. However, the more you like to show / document the better. I agree and I would even say that a good sample is always minimal in general. While it can be more complex in the topic that it demonstrates, everything aound that is unrelated must be as minimal as possible and should not use any other patterns - which might be elegant and useful - but they never are for the one who is interested in the topic of the sample - such things are just a distraction. It's much better to have many samples, each of which demonstrating one specific featuie or usage, than a huge all-in-one sample where a new user would have no clue where one feature ends and another one starts in the code. @niteshsinghal85 - if you'd like to do a bit more, I'd have ideas for a number of other interesting samples: - **How to inject a Preload Script** e.g. for setting up IPC messaging between web content and .net ap - **Build Customization via electron-builder hook scripts** like `beforePack`, `afterPack`, `artifactBuildStarted`, `artifactBuildCompleted` This allows for example to manipulate or replace the `*.desktop` file for Linux apps - **A comprehensive sample for electron-builder.json** That's something you can hardly find anywhere... - **Multi-Project Example** How you can have a base project with Electron.NET code that is shared by multiple Electron.NET apps - **ElectronHostHook Sample** A sample project, showing just ElectronHostHook without any distractions - **App Icons Sample** A working sample with icons for all 3 platforms (Win, Linux, Mac) (for most of them, I can provide something based on which a sample can be created)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Electron.NET#1018