Electron 28.0.0 has been released! It includes upgrades to Chromium 120.0.6099.56, V8 12.0, and Node.js 18.18.2.

The Electron team is excited to announce the release of Electron 28.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​

• Implemented support for ECMAScript modules or ESM (What are ECMAScript modules? learn more here. This includes support for ESM in Electron proper, as well as areas such as the UtilityProcess API entrypoints. See our ESM documentation for more details.
• In addition to enabling ESM support in Electron itself, Electron Forge also supports using ESM to package, build and develop Electron applications. You can find this support in Forge v7.0.0 or higher.

Stack Changes​

• Chromium 120.0.6099.56
  • New in Chrome 119 and in DevTools 119
  • New in Chrome 120 and in DevTools 120
• Node 18.18.2
  • Node 18.18.0 notes
  • Node 18.18.1 notes
  • Node 18.18.2 notes
• V8 12.0

New Features​

• Enabled ESM support. #37535
  • For more details, see the ESM documentation.
• Added ESM entrypoints to the UtilityProcess API. #40047
• Added several properties to the display object including detected, maximumCursorSize, and nativeOrigin. #40554
• Added support for ELECTRON_OZONE_PLATFORM_HINT environment variable on Linux. #39792

Breaking Changes​

Behavior Changed: WebContents.backgroundThrottling set to false affects all WebContents in the host BrowserWindow​

WebContents.backgroundThrottling set to false will disable frames throttling in the BrowserWindow for all WebContents displayed by it.

Removed: BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) has been removed, the BrowserWindow.setWindowButtonPosition(position) API should be used instead which accepts null instead of { x: 0, y: 0 } to reset the position to system default.

// Removed in Electron 28
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Replace with
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

Removed: BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition() has been removed, the BrowserWindow.getWindowButtonPosition() API should be used instead which returns null instead of { x: 0, y: 0 } when there is no custom position.

// Removed in Electron 28
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // No custom position.
}

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // No custom position.
}

Removed: ipcRenderer.sendTo()​

The ipcRenderer.sendTo() API has been removed. It should be replaced by setting up a MessageChannel between the renderers.

The senderId and senderIsMainFrame properties of IpcRendererEvent have been removed as well.

Removed: app.runningUnderRosettaTranslation​

The app.runningUnderRosettaTranslation property has been removed. Use app.runningUnderARM64Translation instead.

// Removed
console.log(app.runningUnderRosettaTranslation);
// Replace with
console.log(app.runningUnderARM64Translation);

End of Support for 25.x.y​

Electron 25.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

Reflecting on the improvements and changes in Electron's developer ecosystem in 2023.

In the past few months, we've been cooking up some changes across the Electron ecosystem to supercharge the developer experience for Electron apps! Here’s a swift rundown of the latest additions straight from Electron HQ.

Electron Forge 7 and beyond​

Electron Forge 7 — the newest major version of our all-in-one tool for packaging and distributing Electron applications — is now available.

While Forge 6 was a complete rewrite from v5, v7 is smaller in scope but still contains a few breaking changes. Going forward, we will continue to publish major versions of Forge as breaking changes need to be made.

For more details, see the full Forge v7.0.0 changelog on GitHub.

Alterações significativas​

• Switched to notarytool for macOS notarization: As of 2023-11-01, Apple sunset the legacy altool for macOS notarization, and this release removes it from Electron Forge entirely.
• Minimum Node.js increased to v16.4.0: With this release, we’ve set the minimum required Node.js version to 16.4.0.
• Dropped support for electron-prebuilt and electron-prebuilt-compile: electron-prebuilt was the original name for Electron’s npm module, but was replaced by electron in v1.3.1. electron-prebuilt-compile was an alternative to that binary that came with enhanced DX features, but was eventually abandoned as a project.

Highlights​

• Google Cloud Storage publisher: As part of our push to better support static auto updating, Electron Forge now supports publishing directly to Google Cloud Storage!
• ESM forge.config.js support: Electron Forge now supports ESM forge.config.js files. (P.S. Look forward to ESM entrypoint support in Electron 28.)
• Makers now run in parallel: In Electron Forge 6, Makers ran sequentially for ✨ legacy ✨ reasons. Since then, we’ve tested out parallelization for the Make step with no adverse side effects, so you should see a speed-up when building multiple targets for the same platform!

Better static storage auto updates​

Squirrel.Windows and Squirrel.Mac are platform-specific updater technologies that back Electron’s built-in autoUpdater module. Both projects support auto updates via two methods:

• A Squirrel-compatible update server
• A manifest URL hosted on a static storage provider (e.g. AWS, Google Cloud Platform, Microsoft Azure, etc.)

The update server method has traditionally been the recommended approach for Electron apps (and provides additional customization of update logic), but it has a major downside—it requires apps to maintain their own server instance if they are closed-source.

On the other hand, the static storage method has always been possible, but was undocumented within Electron and poorly supported across Electron tooling packages.

With some great work from @MarshallOfSound, the update story for serverless automatic app updates has been drastically streamlined:

• Electron Forge’s Zip and Squirrel.Windows makers can now be configured to output autoUpdater-compatible update manifests.
• A new major version of update-electron-app (v2.0.0) can now read these generated manifests as an alternative to the update.electronjs.org server.

Once your Makers and Publishers are configured to upload update manifests to cloud file storage, you can enable auto updates with only a few lines of configuration:

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
  updateSource: {
    type: UpdateSourceType.StaticStorage,
    baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
  },
});

The @electron/ extended universe​

When Electron first started, the community published many packages to enhance the experience of developing, packaging, and distributing Electron apps. Over time, many of these packages were incorporated into Electron’s GitHub organization, with the core team taking on the maintenance burden.

In 2022, we began unifying all these first-party tools under the @electron/ namespace on npm. This change means that packages that used to be electron-foo are now @electron/foo on npm, and repositories that used to be named electron/electron-foo are now electron/foo on GitHub. These changes help clearly delineate first-party projects from userland projects. This includes many commonly used packages, such as:

• @electron/asar
• @electron/fuses
• @electron/get
• @electron/notarize
• @electron/osx-sign
• @electron/packager
• @electron/rebuild
• @electron/remote
• @electron/symbolicate-mac
• @electron/universal

Going forward, all first-party packages we release will also be in the @electron/ namespace. There are two exceptions to this rule:

• Electron core will continue to be published under the electron package.
• Electron Forge will continue to publish all of its monorepo packages under the @electron-forge/ namespace.

Introducing @electron/windows-sign​

Starting on 2023-06-01, industry standards began requiring keys for Windows code signing certificates to be stored on FIPS-compliant hardware.

In practice, this meant that code signing became a lot harder for apps that build and sign in CI environments, since many Electron tools take in a certificate file and password as config parameters and attempt to sign from there using hardcoded logic.

This situation has been a common pain point for Electron developers, which is why we have been working on a better solution that isolates Windows code signing into its own standalone step, similar to what @electron/osx-sign does on macOS.

In the future, we plan on fully integrating this package into the Electron Forge toolchain, but it currently lives on its own. The package is currently available for installation at npm install --save-dev @electron/windows-sign and can used programmatically or via CLI.

Please try it out and give us your feedback in the repo’s issue tracker!

What's next?​

We'll be entering our annual December quiet period next month. While we do, we'll be thinking about how we can make the Electron development experience even better in 2024.

Is there anything you'd like to see us work on next? Conte para nós!

The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

Going forward​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

Electron 27.0.0 has been released! It includes upgrades to Chromium 118.0.5993.32, V8 11.8, and Node.js 18.17.1.

The Electron team is excited to announce the release of Electron 27.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.

It’s been more than a week since CVE-2023-4863: Heap buffer overflow in WebP was made public, leading to a flurry of new releases of software rendering webp images: macOS, iOS, Chrome, Firefox, and various Linux distributions all received updates. This followed investigations by Citizen Lab, discovering that an iPhone used by a “Washington DC-based civil society organization” was under attack using a zero-click exploit within iMessage.

Electron, too, spun into action and released new versions the same day: If your app renders any user-provided content, you should update your version of Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, and v22.3.24 all contain a fixed version of libwebp, the library responsible for rendering webp images.

Now that we are all freshly aware that an interaction as innocent as “rendering an image” is a potentially dangerous activity, we want to use this opportunity to remind everyone that Electron comes with a process sandbox that will limit the blast radius of the next big attack — whatever it may be.

The sandbox was available ever since Electron v1 and enabled by default in v20, but we know that many apps (especially those that have been around for a while) may have a sandbox: false somewhere in their code – or a nodeIntegration: true, which equally disables the sandbox when there is no explicit sandbox setting. That’s understandable: If you’ve been with us for a long time, you probably enjoyed the power of throwing a require("child_process") or require("fs") into the same code that runs your HTML/CSS.

Before we talk about how you migrate to the sandbox, let’s first discuss why you want it.

The sandbox puts a hard cage around all renderer processes, ensuring that no matter what happens inside, code is executed inside a restricted environment. As a concept, it's a lot older than Chromium, and provided as a feature by all major operating systems. Electron's and Chromium's sandbox build on top of these system features. Even if you never display user-generated content, you should consider the possibility that your renderer might get compromised: Scenarios as sophisticated as supply chain attacks and as simple as little bugs can lead to your renderer doing things you didn't fully intend for it to do.

The sandbox makes that scenario a lot less scary: A process inside gets to freely use CPU cycles and memory — that’s it. Processes cannot write to disk or display their own windows. In the case of our libwep bug, the sandbox makes sure that an attacker cannot install or run malware. In fact, in the case of the original Pegasus attack on the employee’s iPhone, the attack specifically targeted a non-sandboxed image process to gain access to the phone, first breaking out of the boundaries of the normally sandboxed iMessage. When a CVE like the one in this example is announced, you still have to upgrade your Electron apps to a secure version — but in the meantime, the amount of damage an attacker can do is limited dramatically.

Migrating a vanilla Electron application from sandbox: false to sandbox: true is an undertaking. I know, because even though I have personally written the first draft of the Electron Security Guidelines, I have not managed to migrate one of my own apps to use it. That changed this weekend, and I recommend that you change it, too.

There are two things you need to tackle:

1. If you’re using Node.js code in either preload scripts or the actual WebContents, you need to move all that Node.js interaction to the main process (or, if you are fancy, a utility process). Given how powerful renderers have become, chances are high that the vast majority of your code doesn’t really need refactoring.

   Consult our documentation on Inter-Process Communication. In my case, I moved a lot of code and wrapped it in ipcRenderer.invoke() and ipcMain.handle(), but the process was straightforward and quickly done. Be a little mindful of your APIs here - if you build an API called executeCodeAsRoot(code), the sandbox won't protect your users much.

2. Since enabling the sandbox disables Node.js integration in your preload scripts, you can no longer use require("../my-script"). In other words, your preload script needs to be a single file.

   There are multiple ways to do that: Webpack, esbuild, parcel, and rollup will all get the job done. I used Electron Forge’s excellent Webpack plugin, users of the equally popular electron-builder can use electron-webpack.

All in all, the entire process took me around four days — and that includes a lot of scratching my head at how to wrangle Webpack’s massive power, since I decided to use the opportunity to refactor my code in plenty of other ways, too.

Electron 26.0.0 has been released! It includes upgrades to Chromium 116.0.5845.62, V8 11.2, and Node.js 18.16.1. Read below for more details!

The Electron team is excited to announce the release of Electron 26.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Electron 25.0.0 has been released! It includes upgrades to Chromium 114, V8 11.4, and Node.js 18.15.0. Read below for more details!

The Electron team is excited to announce the release of Electron 25.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

22.x.y Continued Support​

As noted in Farewell, Windows 7/8/8.1, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023. The October support date follows the extended support dates from both Chromium and Microsoft. On October 11, the Electron team will drop support back to the latest three stable major versions, which will no longer support Windows 7/8/8.1.

Notable Changes​

• Implemented net.fetch within Electron's net module, using Chromium's networking stack. This differs from Node's fetch(), which uses Node.js' HTTP stack. See #36733 and #36606.
• Added protocol.handle, which replaces and deprecates protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Extended support for Electron 22, in order to match Chromium and Microsoft's Windows 7/8/8.1 deprecation plan. See additional details at the end of this blog post.

Electron 24.0.0 has been released! It includes upgrades to Chromium 112.0.5615.49, V8 11.2, and Node.js 18.14.0. Read below for more details!

The Electron team is excited to announce the release of Electron 24.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

O primeiro commit do repositório electron/electron foi em 13 de março de 2013¹.

Após 10 anos e 27,147 mais commits de 1192 contribuintes únicos, Electron se tornou uma das estruturas mais populares para construir aplicativos de desktop hoje. Esse marco é a oportunidade perfeita para celebrar e refletir sobre nossa jornada até agora, e para compartilhar o que aprendemos ao longo o caminho.

Nós não estaríamos aqui hoje sem todos que dedicaram seu tempo e seu esforço para contribuir com o projeto. Embora as contribuições de commits de código-fonte sejam sempre as mais visíveis, também devemos reconhecer o esforço das pessoas que relatam bugs, mantêm módulos de usuário, fornecem documentação e traduções, e participam na comunidade Electron em todo o ciberespaço. Todos os contributos são inestimáveis para nós, como mantenedores.

Antes de continuarmos com o resto do post: obrigado. ❤️

Como chegamos aqui?​

Atom Shell foi construído como a espinha dorsal do GitHub Editor Atom, que foi lançado em beta público em Abril de 2014. Foi construído a partir do zero como uma alternativa aos frameworks baseados na web disponíveis no tempo (node-webkit e Chromium Embedded Framework). Ele tinha um recurso matador: incorporando Node.js e Chromium para fornecer um poderoso tempo de execução desktop para tecnologias web.

Dentro de um ano, Atom Shell começou a assistir a um enorme crescimento das capacidades e da popularidade. Grandes empresas, startups e desenvolvedores individuais também começaram a construir aplicativos com ele (alguns early adopters incluem Slack, GitKraken, e WebTorrent), e o projeto foi apropriadamente renomeado para Electron.

A partir daí, o Electron começou com força total e nunca parou. Aqui está uma olhada em nossa contagem semanal de downloads ao longo do tempo, cortesia de npmtrends.com:

Electron v1 foi lançado em 2016, prometendo maior estabilidade da API e melhores documentos e ferramentas. Electron v2 foi lançado em 2018 e introduzido a versão semântica, tornando mais fácil para desenvolvedores Electron manter controle do ciclo de lançamento.

Por Electron v6, mudamos para uma cadência de lançamento maior de 12 semanas para combinar com a do Chromium. Esta decisão foi uma alteração na mentalidade do projeto, trazendo “ter a versão mais atualizada do Chromium ” de um nicho a ter uma prioridade. Isso reduziu a quantidade de dívida em tecnologia entre atualizações, tornando mais fácil para nós manter o Electron atualizado e seguro.

Desde então, temos funcionado como uma máquina bem oleada, lançando uma nova versão do Electron no mesmo dia que cada versão estável do Chromium. Quando o Chromium acelerou seu cronograma de lançamentos para 4 semanas em 2021, conseguimos simplesmente dar de ombros e aumentar nossa cadência de lançamentos para 8 semanas de acordo.

Agora estamos no Electron v23 (e contando), e ainda estamos dedicados a construir o melhor tempo de execução para construir aplicativos desktop multiplataforma. Mesmo com o boom das ferramentas de desenvolvedor de JavaScript em últimos anos, Electron continuou a ser uma paisagem estável e testada por batalhas do framework do aplicativo para desktop. Aplicativos Electron atualmente são onipresentes: você pode programar com o Visual Studio Code, projetar com Figma, se comunicar com o Slack, e fazer notas com Notion (entre muitos outros casos de uso). Estamos incrivelmente orgulhosos desta conquista e gratos a todos que a tornaram possível.

O que aprendemos ao longo do caminho?​

O caminho para o marco da década tem sido longo e ventoso. Aqui estão algumas coisas-chave que nos ajudaram a administrar um projeto de código aberto grande e sustentável.

Dimensionamento da tomada decisória distribuída com um modelo de governança​

Um desafio que tivemos que superar foi lidar com a direção de longo prazo do projeto uma vez que o Electron explodiu na popularidade. Como lidamos com ser uma equipe de algumas dezenas de engenheiros distribuídos por empresas, países e fusos horários?

Nos primeiros dias, o grupo de mantenedores do Electron baseou-se em coordenação informal, que é rápido e leve para projetos menores, mas não escala para uma colaboração mais ampla. Em 2019, mudamos para um modelo de governança onde diferentes grupos de trabalho têm áreas formais de responsabilidade. Isto tem sido instrumental na racionalização de processos e atribuição de porções de propriedade do projeto a mantenedores específicos. Qual é a responsabilidade de cada grupo de trabalho (WG) actualmente?

• Obter lançamentos do Electron rápido (Releases WG)
• Atualizar o Chromium e o Node.js (Atualiza o WG)
• Supervisão do design da API pública (Grupo de Trabalho de API)
• Manter o Electron seguro (WG de segurança)
• Manter o site, a documentação e a ferramenta (Ecosystem WG)
• Alcance da Comunidade e corporativa (Outreach WG)
• Moderação comunitária (Community & Segurança WG)
• Manutenção de nossa infraestrutura construtiva, mantenedores de ferramentas e serviços de nuvem (Infraestrutura de WG)

Por volta do mesmo período em que mudamos para o modelo de governança, transferimos a propriedade do Electron do GitHub para a OpenJS Foundation. Embora a equipe central original ainda trabalhe na Microsoft hoje, eles são apenas uma parte de um grupo maior de colaboradores que compõem a governança do Electron.²

Embora esse modelo não seja perfeito, ele nos serviu bem durante uma pandemia global e desafios econômicos contínuos. Indo em frente, nós planejamos renovar a carta de governança para nos guiar durante a segunda década da Electron.

Comunidade​

A parte da comunidade de código aberto é difícil, especialmente quando sua equipe de Outreach é uma dúzia de engenheiros em um casaco de trincheiras que diz "gerente da comunidade". Dito isso, ser um grande projeto de código aberto significa que temos muitos usuários, e utilizar sua energia para o Electron construir um ecossistema da userland é uma parte crucial para sustentar a saúde do projeto.

O que temos estado a fazer para desenvolver a nossa presença na comunidade?

Criando comunidades virtuais​

• Em 2020, lançamos o servidor da nossa comunidade do Discord. Anteriormente tínhamos uma secção no fórum do Atom, mas decidiu ter uma plataforma de mensagens mais informal para ter um espaço para discussões entre mantenedores e desenvolvedores Electron e para ajuda geral na depuração.
• Em 2021, estabelecemos o grupo de usuários Electron China com a ajuda da @BlackHole1. Este grupo tem sido instrumental no crescimento do Electron em usuários da cena tecnológica da China, proporcionando um espaço para eles colaborarem em ideias e discuta o Electron fora de nossos espaços em inglês. Nós também gostaríamos de agradecer à cnpm pelo seu trabalho de apoio aos lançamentos noturnos da Electron, em seu espelho Chinês para o npm.

Participando de programas de alta visibilidade de código aberto​

• Temos comemorado o Hacktoberfest todos os anos desde 2019. O Hacktoberfest é uma celebração anual de código aberto organizada pela DigitalOcean, e todos os anos recebemos dezenas de colaboradores entusiasmados que buscam deixar sua marca no software de código aberto.
• Em 2020, participamos da iteração inicial da Google Season of Docs, onde trabalhamos com @bandantonio para retrabalhar o novo fluxo de tutorial do Electron.
• Em 2022, mentoramos um aluno do "Google Summer of Code" pela primeira vez. @aryanshridhar fez um ótimo trabalho para refatorar a principal lógica de carregamento de versão do Electron Fiddle e migrar o seu empacotamento para webpack.

Automatizar todas as coisas!​

Hoje, a governaça do Electron conta com cerca de 30 mantenedores ativos. Menos de metade de nós somos colaboradores a tempo integral contribuidores, o que significa que há muito trabalho a fazer. Qual é o nosso truque para manter tudo funcionando sem problemas? O nosso lema é que os computadores são baratos, e o tempo humano é caro. De forma típica de engenheiro, nós desenvolvemos um conjunto de ferramentas automatizadas de suporte para tornar nossas vidas mais fáceis.

Not Goma​

A base de código central do Electron é um gigante de código C++, e os tempos de compilação sempre foram um fator limitante na velocidade com que podemos entregar correções de falhas e novos recursos. In 2020, we deployed Not Goma, a custom Electron-specific backend for Google’s Goma distributed compiler service. Não é um processo de compilação do (Goma) que solicita solicitações de máquinas autorizadas do usuário e distribui o processo por centenas de núcleos do backend. Ele também armazena em cache o resultado da compilação, para que qualquer outra pessoa que compile os mesmos arquivos precisem

Desde o lançamento Não Goma, os tempos de compilação para mantenedores diminuíram de uma escala de horas para minutos. Uma conexão estável com a internet tornou-se o requisito mínimo de contribuidores para compilar o Electron!

Fator de Autenticação Contínua​

Continuous Factor Authentication (CFA) é uma camada de automação em torno do sistema de autenticação de dois fatores (2FA) do npm, que combinamos com o semantic-release para gerenciar lançamentos seguros e automatizados de nossos vários pacotes @electron/ do npm.

Embora o semantic-release já automatize o processo de publicação de pacotes npm, ele exige desativar a autenticação de dois fatores ou passar um token secreto que contorna essa restrição.

Construímos o CFA para fornecer uma senha de uso único baseada em tempo (TOTP) para o 2FA do npm em tarefas de CI arbitrárias, permitindo-nos aproveitar a automação do semantic-release enquanto mantemos a segurança adicional da autenticação de dois fatores.

Usamos o CFA com um front-end de integração do Slack, permitindo que os mantenedores validem a publicação do pacote de qualquer dispositivo em que o Slack esteja ativado, contanto que tenham seu gerador TOTP útil.

Sheriff​

Sheriff é uma ferramenta de código aberto que escrevemos para automatizar a ferramenta gerenciamento de permissões em todo o GitHub, Slack e Google Workspace.

A proposta de valor-chave do Sherif é que a gestão de permissão deve ser um processo transparente. Ele usa um único arquivo de configuração YAML que designa permissões através de todos os serviços listados acima. Com o Sheriff, obter o status de colaborador em um repositório ou criar uma nova lista de e-mails é tão fácil quanto obter um PR aprovado e mesclado.

O Sheriff também possui um registro de auditoria que posta no Slack, alertando os administradores quando atividades suspeitas ocorrem em qualquer lugar na organização Electron.

…e todos os nossos bots no GitHub​

O GitHub é uma plataforma com a rica extensibilidade da API e um framework de aplicativo de primeiro grupo chamado Probot. Para nos ajudar a focar nas partes mais criativas do nosso trabalho, construímos um conjunto de bots menores que nos ajudam a fazer o trabalho sujo. Eis alguns exemplos:

• Sudowodo automatiza o processo de lançamento do Electron do início ao fim, desde o início das compilações até o upload dos arquivos de lançamento para o GitHub e npm.
• Trop automatiza o processo de backporting para o Electron, tentando aplicar patches (usando cherry-pick) em branches de versões anteriores com base nos labels das Pull Requests (PRs) do GitHub.
• Roller automatiza as atualizações do Chromium do Electron e das dependências do Node.js.
• Cation é nosso bot de verificação de status para electron/electron PRs.

Ao todo, nossa pequena família de bots nos deu um grande impulso na produtividade do desenvolvedor!

What’s next?​

À medida que entramos em nossa segunda década como um projeto, você deve estar perguntando: o que vem por aí com o Electron?

Vamos continuar em sincronia com a cadência de lançamentos do Chromium, lançando novas versões principais do Electron a cada 8 semanas, mantendo o framework atualizado com o que há de mais recente na plataforma web e no Node.js, ao mesmo tempo em que mantemos estabilidade e segurança para aplicativos de nível empresarial.

Normalmente anunciamos notícias sobre iniciativas futuras quando elas se tornam concretas. Se você quiser se manter informado sobre as versões futuras, recursos e atualizações gerais do projeto, você pode ler nosso blog e seguir nossos perfis de mídia social (Twitter e Mastodon)!

Electron 23.0.0 has been released! It includes upgrades to Chromium 110, V8 11.0, and Node.js 18.12.1. Additionally, support for Windows 7/8/8.1 has been dropped. Read below for more details!

The Electron team is excited to announce the release of Electron 23.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Dropping Windows 7/8/8.1 Support​

Electron 23 no longer supports Windows 7/8/8.1. Electron follows the planned Chromium deprecation policy, which will deprecate Windows 7/8/8.1 , as well as Windows Server 2012 and 2012 R2 support in Chromium 109 (read more here).