https://github.com/opencrew-tech/openbsd-electron
Ongoing OpenBSD port of Electron
https://github.com/opencrew-tech/openbsd-electron
electron openbsd vscode
Last synced: 1 day ago
JSON representation
Ongoing OpenBSD port of Electron
- Host: GitHub
- URL: https://github.com/opencrew-tech/openbsd-electron
- Owner: opencrew-tech
- Created: 2024-05-24T17:42:04.000Z (11 months ago)
- Default Branch: main
- Last Pushed: 2025-03-30T19:08:47.000Z (about 1 month ago)
- Last Synced: 2025-04-25T01:14:30.918Z (5 days ago)
- Topics: electron, openbsd, vscode
- Language: BitBake
- Homepage:
- Size: 2.45 MB
- Stars: 10
- Watchers: 4
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# OpenBSD + Electron
An effort to port Electron (and, by extension, VS Code) to OpenBSD.
It includes custom `modnpm` and `modyarn` modules to facilitate the integration of Node-based ports.
***Status : Working**, need some more cleaning.*
## Electron
Electron is built on Chromium, utilizing the same patches and features as the current port.
The implementation includes OpenBSD-specific support for pledge and unveil, with a per-application design.
Electron is installed system-wide with a single installation, and applications should be compatible with this shared version.
Instead of creating distfiles or bundling Electron with individual applications (though technically feasible), each application
includes a dedicated wrapper to properly initialize Electron with its specific configuration and resources.
*Efforts are underway to implement [fuses](https://www.electronjs.org/docs/latest/tutorial/fuses) support with a single, sensible default.*
## Node packages managers
To avoid network usage during the build process, the available options are quite limited:
* Using a pre-made cache for offline functionality, which requires someone to distribute the archive
* Filling the cache before the extraction phase, necessitating a tool to populate the cache
* Extracting directly into node_modules, which should be the package manager's job and is complex to implement
*The most viable solution seems to fill the cache before extraction.*
* `yarn`: works well with a simple, flat, directory cache
* `npm`: use cacache and also repository API, not only package module
* `pnpm`: todo
* `berry`: to study
Each package manager generates a lock file that describes all dependencies and the structure of `node_modules`.
The `port-modules` tool parses these lock files to produce a `modules.inc` file.
* `moyarn`: fill the cache during extract, limited support for Electron ports only
* `modnpm`: setup node_modules, lightly tested on different kinds of ports
*The plan is to implement a `cache-add` CLI for each package manager, aiming for upstream adoption.*
## Ports included
* VScode : everythings seems to works **without sandboxing**, kerberos support not tested
* teams-for-linux : screen share, webcam, audio tested ok
* signal-desktop : screen share, webcam, audio tested ok
* stretchly : ok
* byar-chobby : ok