¡Electron ha sido aceptado una vez más como una organización mentora para Google Summer of Code (GSoC) 2025! Google Summer of Code es un programa global centrado en traer nuevos colaboradores al desarrollo de software de código abierto.

Para obtener más detalles del programa, consulta la página de inicio de Summer of Code.

Sobre nosotros​

Electron es un framework JavaScript para construir aplicaciones multiplataforma de escritorio usando tecnologías web. El framework central de Electron es un ejecutable binario compilado construido con Chromium y Node.js, y está escrito principalmente en C++.

Fuera del repositorio de Electron también mantenemos varios proyectos para apoyar el ecosistema Electron incluyendo:

• Herramientas de distribución del usuario final (por ejemplo, Electron Forge y update.electronjs.org).
• Material de aprendizaje para desarrolladores de Electron (por ejemplo, electronjs.org y Electron Fiddle).
• Herramientas internas para optimizar la productividad del desarrollador (por ejemplo, Electron Build Tools y Sheriff).

Como colaborador de Summer of Code, estarías colaborando con algunos de los principales colaboradores de Electron en uno de los muchos proyectos bajo el paraguas github.com/electron.

Antes de aplicar​

Si no estás muy familiarizado con Electron, te recomendamos que comiences leyendo la documentación y probando ejemplos en Electron Fiddle.

Para obtener más información sobre la distribución de aplicaciones de Electron intente crear una aplicación de ejemplo con Electron Forge:

npm init electron-app@latest my-app

Después de familiarizarte un poco con el código, ven a unirte a la conversación en el Servidor de Discord de Electron.

Colaboraciones del proyecto​

Le animamos a que eche un vistazo a cualquier repositorio que sea relevante para las ideas de proyectos que le interesen. Una forma de hacer su investigación es hacer contribuciones reportando errores, clasificando problemas existentes, o enviando pull requests. Hacerlo es una forma efectiva de adquirir experiencia práctica con nuestras bases de código, pero no es obligatorio para enviar propuestas. Una propuesta bien elaborada debe ser capaz de demostrar su conocimiento del código sin necesidad de referirse a contribuciones anteriores.

Estos son algunas recomendaciones si está buscando contribuir con Electron antes de enviar su propuesta:

1. Sírvanse proporcionar un problema descriptivo o descripciones de relaciones públicas al enviar contribuciones. Independientemente del código en sí, dedicar esfuerzo a la parte escrita de una contribución nos demuestra que puedes ser un comunicador eficaz en un entorno colaborativo.
2. Los PR son siempre bienvenidos para las cuestiones abiertas. No es necesario que comentes un problema preguntándole a un mantenedor si se te puede asignar la tarea. Tenga en cuenta que aún le animamos a discutir posibles soluciones sobre un problema si necesita refinar una idea para una solución, pero comentarios estrictamente preguntando si puedes trabajar en algo son redundantes y añadir ruido al gestor de incidencias.
3. Contribuciones de proyectos de bajo esfuerzo (p. ej. informes de incidencias no válidos, términos triviales cambios en un README, o cambios estilísticos menores en el código front-end) impactará negativamente su propuesta final, ya que ocupan tiempo limitado de mantenedor y no proporcionan ningún beneficio neto al proyecto Electron.
4. Mientras que los asistentes de codificación de IA pueden ser una herramienta eficaz para depurar y entender nuevos conceptos, desanimamos enormemente las contribuciones que se copian/pegan directamente de la salida generada por la IA. Estas a menudo resultan de baja calidad. y a menudo es más esfuerzo para los mantenedores limpiar el código generado a partir de un LLM que rechazar completamente una PR.

Artesanos de su propuesta​

¿Estás interesado en colaborar con Electron? Primero, revisa los siete borradores de ideas del proyecto que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas.

Si tienes una idea única que no está en la lista, estamos abiertos a considerarla, pero asegúrate de que tu propuesta esté detallada y detallada. En caso de duda, le recomendamos que se aferre a nuestras ideas listadas.

Su solicitud debe incluir:

• Una propuesta detallada en la que se esboza lo que se pretende conseguir durante el verano.
• Su experiencia como desarrollador. Si tiene un currículum, por favor incluya una copia. De lo contrario, cuéntanos tu experiencia técnica pasada.
  • La falta de experiencia en ciertas áreas no te descalificará, pero ayudará a nuestros mentores a elaborar un plan para ayudarte mejor y asegurarte de que tu proyecto de verano sea un éxito.

Aquí está una guía detallada de qué enviar como parte de tu aplicación Electron. Presenta propuestas directamente al portal de Google Summer of Code. Las propuestas enviadas al equipo Electron no serán consideradas como propuestas finales.

Si desea más orientación sobre su propuesta o no está seguro de qué incluir, también recomendamos que sigas [la propuesta oficial de Google Summer of Code escribiendo consejos aquí](https://google. ithub.io/gsocguides/student/writing-a-proposal).

Aplicaciones abiertas el 24 de marzo de 2025 y cierran el 8 de abril de 2025.

¿Preguntas?​

Si tienes preguntas que no enviamos en las publicaciones del blog o consultas para tu borrador de propuestas, por favor envíanos un correo electrónico a Summer-of-code@electronjs. rg o revisa GSoC FAQ. Por favor, lee nuestra guía de colaborador antes de enviar un correo electrónico.

Recursos​

• Electron Google Summer of Code 2025 Lista de ideas
• Electron Google Summer of Code 2025 Orientación para contribuyentes
• Guía para estudiantes/colaboradores de Google Summer of Code

¡Electron 34.0.0 ha sido liberado! It includes upgrades to Chromium 132.0.6834.83, V8 13.2, and Node 20.18.1.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 34.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

HTTP Compression Shared Dictionary Management APIs​

HTTP compression allows data to be compressed by a web server before being received by the browser. Modern versions of Chromium support Brotli and Zstandard, which are newer compression algorithms that perform better for text files than older schemes such as gzip.

Custom shared dictionaries further improve the efficiency of Brotli and Zstandard compression. See the Chrome for Developers blog on shared dictionaries for more information.

@felixrieseberg added the following APIs in #44950 to manage shared dictionaries at the Session level:

• session.getSharedDictionaryUsageInfo()
• session.getSharedDictionaryInfo(options)
• session.clearSharedDictionaryCache()
• session.clearSharedDictionaryCacheForIsolationKey(options)

Unresponsive Renderer JavaScript Call Stacks​

Electron's unresponsive event occurs whenever a renderer process hangs for an excessive period of time. The new WebFrameMain.collectJavaScriptCallStack() API added by @samuelmaddock in #44204 allows you to collect the JavaScript call stack from the associated WebFrameMain object (webContnets.mainFrame).

This API can be useful to determine why the frame is unresponsive in cases where there's long-running JavaScript events causing the process to hang. For more information, see the proposed web standard Crash Reporting API.

const { app } = require('electron');

app.commandLine.appendSwitch(
  'enable-features',
  'DocumentPolicyIncludeJSCallStacksInCrashReports',
);

app.on('web-contents-created', (_, webContents) => {
  webContents.on('unresponsive', async () => {
    // Interrupt execution and collect call stack from unresponsive renderer
    const callStack = await webContents.mainFrame.collectJavaScriptCallStack();
    console.log('Renderer unresponsive\n', callStack);
  });
});

In early 2025, Electron’s npm ecosystem repos (under the @electron/ and @electron-forge/ namespaces) will move to Node.js 22 as the minimum supported version.

What does this mean?​

In the past, packages in Electron’s npm ecosystem (Forge, Packager, etc) have supported Node versions for as long as possible, even after a version has reached its End-Of-Life (EOL) date. This is done to make sure we don’t fragment the ecosystem—we understand that many projects depend on older versions of Node, and we don’t want to risk stranding those projects unless there was a pressing reason to upgrade.

Over time, using Node.js 14 as our minimum version has become increasingly difficult for a few reasons:

• Lack of official Node.js 14 macOS ARM64 builds requires us to maintain CI infrastructure workarounds to provide full test coverage.
• engines requirements for upstream package dependencies have moved forward, making it increasingly difficult to resolve supply chain security issues with dependency bumps.

Additionally, newer versions of Node.js have included many improvements that we would like to leverage, such as runtime-native common utilities (e.g. fs.glob and util.parseArgs) and entire new batteries-included modules (e.g. node:test, node:sqlite).

Why upgrade now?​

In July 2024, Electron’s Ecosystem Working Group decided to upgrade all packages to the earliest Node version where require()of synchronous ESM graphs will be supported (see nodejs/node#51977 and nodejs/node#53500) at a future point after that version reaches its LTS date.

We’ve decided to set that update time to January/February 2025. After this upgrade occurs, Node 22 will be the minimum supported version in existing ecosystem packages.

What action do I need to take?​

We’ll strive to maintain compatibility as much as possible. However, to ensure the best support, we encourage you to upgrade your apps to Node 22 or higher.

Note that the Node version running in your project is unrelated to the Node version embedded into your current version of Electron.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

El proyecto de Electron realizará una pausa para el mes de diciembre de 2024, para después regresar a toda velocidad en enero de 2025.

vía GIPHY

Lo que será igual en diciembre​

1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reporar a través de SECURITY.md.
2. Los reportes relacionados con el Código de conducta continuarán.

Lo que será diferente en diciembre​

1. Las últimas versiones estables de las ramas de 2024, que incluyen Electron 31, 32 y 33, se lanzarán la semana del 1 de diciembre. No habrá lanzamientos adicionales planificados en diciembre.
2. No habrá versiones preliminares ni de prueba durante las últimas dos semanas de diciembre.
3. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
4. No se actualizará el rastreador de incidencias en ningún repositorio.
5. No se ayudará con la depuración en Discord por parte de los encargados.
6. No se publicarán actualizaciones de contenido en las redes sociales.

¡Nos vemos en el 2025!

BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.

Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps​

1. Upgrade Electron to 30.0.0 or higher​

2. Familiarize yourself with where your application uses BrowserViews​

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

3. Migrate each usage of BrowserView​

1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   

   info

   By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. Migrate where the BrowserView gets added to its parent window.

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. Migrate BrowserView instance method calls on the parent window.

   Old Method	New Method	Notas
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	Calling addChildView on an existing view reorders it to the top.
   win.getBrowserViews	win.contentView.children

4. Migrate the setAutoResize instance method to a resize listener.

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   

   tip

   All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4) Test and commit your changes​

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

¡Electron 33.0.0 ha sido liberado! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 33.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
• Extended navigationHistory API with 2 new functions for better history management. #42014
• Improved native theme transparency checking. #42862

Los cambios históricos en las API de Electron ahora serán detallados en los documentos.

Hola 👋, soy Peter, el 2024 Google Summer of Code (GSoC) colaborador de Electron.

Durante el curso del programa GSoC, implementé una función de historial de API para la documentación de Electron y sus funciones, clases, etc. de forma similar a la Nodo. s documentación: permitiendo el uso de un esquema YAML simple pero potente en los archivos Markdown de documentación de la API y mostrándolo bien en el sitio web de documentación de Electron.

¡Electron 32.0.0 ha sido liberado! It includes upgrades to Chromium 128.0.6613.36, V8 12.8, and Node 20.16.0.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 32.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Added new API version history in our documentation, a feature created by @piotrpdev as part of Google Summer of Code. You can learn more about it in this blog post. #42982
• Removed nonstandard File.path extension from the Web File API. #42053
• Aligned failure pathway in Web File System API with upstream when attempting to open a file or directory in a blocked path. #42993
• Added the following existing navigation-related APIs to webcontents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. The previous navigation APIs are now deprecated. #41752

¡Electron 31.0.0 ha sido liberado! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 31.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Extended WebContentsView to accept pre-existing webContents object. #42319
• Added support for NODE_EXTRA_CA_CERTS. #41689
• Updated window.flashFrame(bool) to flash continuously on macOS. #41391
• Removed WebSQL support #41868
• nativeImage.toDataURL will preserve PNG colorspace #41610
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432

¡Electron 30.0.0 ha sido liberado! Incluye actualizaciones a Chromium 124.0.6367.49, V8 12.4 y Node.js 20.11.1.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 30.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Fusible de integridad ASAR ahora soportado en Windows (#40504)
  • Las aplicaciones existentes con la integración ASAR habilitada pueden no funcionar en Windows si no están configuradas correctamente. Las aplicaciones que usan herramientas de empaquetado Electron deben actualizar a @electron/packager@18.3.1 o @electron/forge@7.4.0.
  • Eche un vistazo a nuestro tutorial de integración ASAR para más información.
• Añadido WebContentsView y BaseWindow módulos de proceso principales, haciendo obsoleto y reemplazando BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
  • BrowserView es ahora una corrección sobre WebContentsView y la implementación antigua ha sido eliminada.
  • Consulte nuestra documentación de Incrustaciones Web para una comparación de la nueva API WebContentsView a otras API similares.
• Soporte implementado para File System API (#41827)