chore: automated electron tests

[axi92]

I just figured out that it is possible to run electron tests with xvfb and that xvfb is already present in the ubuntu-latest github runner image.

This little example electron app connects on launch to mqtt://broker.hivemq.com:1883 in the electron web context.

I am yet not sure on how to integrate this into the project.

Todo:

• check if the connection uses mqtt and not ws as a fallback because of browser detection.
• If this should get merged at some point I have to change this https://github.com/axi92/MQTT.js/blob/feature/automated-electron-tests/.github/workflows/electron-tests.yml#L6 back to main only.

[robertsLando]

@axi92 Well done with this, does it works? Another thing you could do is to add an export of is-browser things in mqtt.ts or index.ts so you can check for those values too in your test :)

[axi92]

@robertsLando I added the isBrowser test and also check the protocol string from the client that is used for the connection to make sure that it is not falling back to ws

[GuoSirius]

In fact, this test should not be placed here for judgment.

Because the rendering process is also a browser environment, since it is a browser environment, it should go the browser logic.

Otherwise, the ws module may be mistakenly loaded in the browser environment of the rendering process, and the ws module cannot run in the browser environment.

If you do need to use the mqtt protocol in an electron application, it is recommended to put the connection establishment logic in the main process, and then use the interprocess communication mechanism to interact between the row rendering process and the main process.

The rendering process must have a window and a document, but not necessarily a Node.js environment, depending on the configuration at instantiation time.

With the main rendering process's responsibilities clearly divided, the browser environment's detection mechanism can maintain the previous standard judgment logic.

[GuoSirius]

The Electron main process owns all Node environments and can establish connections according to the logic of non-browser environments.

The rendering process belongs to the browser environment and should follow the logic of the browser environment to establish the connection.

Just because the rendering process has more process, Node, and other accessible environments than the normal browser environment, it should not be attributed to the Node environment.

In this cross-end application, it is up to the user to decide which way to establish the connection. According to the needs, the connection can be established in the main process or the rendering process, rather than the application library to force detection to determine the protocol.

According to the above convention, the is-browser.ts file is purely used to detect the browser environment, regardless of whether there are other factors, such as the main process or the rendering process.

[axi92]

I rebased my branch.