Mise à jour d'une application
Il existe plusieurs façons de mettre à jour automatiquement votre application Electron. The easiest and officially supported one is taking advantage of the built-in Squirrel framework and Electron's autoUpdater module.
Utilisation du stockage d'objets cloud (sans serveur : serverless)
For a simple serverless update flow, Electron's autoUpdater module can check if updates are available by pointing to a static storage URL containing latest release metadata.
When a new release is available, this metadata needs to be published to cloud storage alongside the release itself. The metadata format is different for macOS and Windows.
Publishing release metadata
With Electron Forge, you can set up static file storage updates by publishing metadata artifacts from the ZIP Maker (macOS) with macUpdateManifestBaseUrl and the Squirrel.Windows Maker (Windows) with remoteReleases.
See Forge's Auto updating from S3 guide for an end-to-end example.
Manual publishing
On macOS, Squirrel.Mac can receive updates by reading a releases.json file with the following JSON format:
{
"currentRelease": "1.2.3",
"releases": [
{
"version": "1.2.1",
"updateTo": {
"version": "1.2.1",
"pub_date": "2023-09-18T12:29:53+01:00",
"notes": "Theses are some release notes innit",
"name": "1.2.1",
"url": "https://mycompany.example.com/myapp/releases/myrelease"
}
},
{
"version": "1.2.3",
"updateTo": {
"version": "1.2.3",
"pub_date": "2024-09-18T12:29:53+01:00",
"notes": "Theses are some more release notes innit",
"name": "1.2.3",
"url": "https://mycompany.example.com/myapp/releases/myrelease3"
}
}
]
}
On Windows, Squirrel.Windows can receive updates by reading from the RELEASES file generated during the build process. This file details the .nupkg delta package to update to.
B0892F3C7AC91D72A6271FF36905FEF8FE993520 electron-fiddle-0.36.3-full.nupkg 103298365
These files should live in the same directory as your release, under a folder structure that is aware of your app's platform and architecture.
Par exemple :
my-app-updates/
├─ darwin/
│ ├─ x64/
│ │ ├─ my-app-1.0.0-darwin-x64.zip
│ │ ├─ my-app-1.1.0-darwin-x64.zip
│ │ ├─ RELEASES.json
│ ├─ arm64/
│ │ ├─ my-app-1.0.0-darwin-arm64.zip
│ │ ├─ my-app-1.1.0-darwin-arm64.zip
│ │ ├─ RELEASES.json
├─ win32/
│ ├─ x64/
│ │ ├─ my-app-1.0.0-win32-x64.exe
│ │ ├─ my-app-1.0.0-win32-x64.nupkg
│ │ ├─ my-app-1.1.0-win32-x64.exe
│ │ ├─ my-app-1.1.0-win32-x64.nupkg
│ │ ├─ RELEASES
Reading release metadata
The easiest way to consume metadata is by installing update-electron-app, a drop-in Node.js module that sets up autoUpdater and prompts the user with a native dialog.
For static storage updates, point the updateSource.baseUrl parameter to the directory containing your release metadata files.
const { updateElectronApp, UpdateSourceType } = require('update-electron-app')
updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-bucket.s3.amazonaws.com/my-app-updates/${process.platform}/${process.arch}`
}
})
Utilisation de update.electronjs.org
L'équipe GitHub d'Electron maintiens update.electronjs.org, un service web gratuit et open-source que les applications Electron peuvent utiliser pour se mettre à jour. Ce service est conçu pour les applications Electron répondant aux critères suivant:
- L'application tourne sous macOs ou Windows
- L'application a un répertoire GitHub public
- Les compilations sont publiées dans GitHub releases
- Builds are code-signed (macOS only)
La façon la plus simple d'utiliser ce service est d'installer update-electron-app, un module Node.js pré-configuré pour être utilisé avec update.electronjs.org.
Installez le module en utilisant votre gestionnaire préféré de paquets Node.js:
- npm
- Yarn
npm install update-electron-app
yarn add update-electron-app
Puis, appelez l'updater depuis le fichier du processus principal de votre application :
require('update-electron-app')()
Par défaut, ce module vérifiera les mises à jour au démarrage de l'application, toutes les dix- minutes. Lorsqu’une mise à jour est trouvée, elle sera automatiquement téléchargée en arrière-plan. Une fois le téléchargement terminé, une boîte de dialogue s’affiche permettant à l’utilisateur de redémarrer l’application.
Si vous devez personnaliser votre configuration, vous pouvez passer des options à update-electron-app ou utiliser le service de mise à jour directement.
Utilisation d'autres services de mise à jour
Si vous développez une application Electron privée, ou si vous ne publiez pas votre application sous GitHub, il peut être nécessaire de mettre en place votre propre serveur de mise à jour.
Etape n°1 : Déploiement d’un serveur de mise à jour
Selon vos besoins, vous pouvez choisir parmi l'un d'entre eux :
- Hazel - Serveur de mise à jour pour les applications privées ou open source qui peuvent être déployées gratuitement sur Vercel. Cela récupère les releases GitHub et exploite la puissance du CDN de GitHub.
- Nuts – Utilise aussi les releases GitHub, mais met en cache les mises à jour des applications sur le disque et prend en charge les dépôts privés.
- electron-release-server – Fournit un tableau de bord pour la gestion des releases et n'exige pas que les releases soient créés sur GitHub.
- Nucleus – Un serveur de mise à jour complet pour les applications Electron maintenues par Atlassian. Prend en charge plusieurs applications et canaux; utilise un magasin de fichiers statique pour minimiser le coût du serveur.
Une fois votre serveur de mise à jour déployé , vous pourrez utiliser le code de votre application pour recevoir et appliquer les mises à jour avec le module autoUpdater d'Electron.
Étape 2 : Réception des mises à jour dans votre application
Tout d'abord, importez les modules requis dans votre code de processus principal. Le code suivant devoir être modifié pour différents logiciels de serveur, mais il fonctionne comme décrit lors de l'utilisation de Hazel.
Veuillez vous assurer que le code ci-dessous ne sera exécuté que dans votre application empaquetée, et non en développement. You can use the app.isPackaged API to check the environment.
const { app, autoUpdater, dialog } = require('electron')
Next, construct the URL of the update server feed and tell autoUpdater about it:
const server = 'https://your-deployment-url.com'
const url = `${server}/update/${process.platform}/${app.getVersion()}`
autoUpdater.setFeedURL({ url })
Comme dernière étape, vérifiez les mises à jour. L'exemple ci-dessous vérifiera chaque minute:
setInterval(() => {
autoUpdater.checkForUpdates()
}, 60000)
Once your application is packaged, it will receive an update for each new GitHub Release that you publish.
Étape 3 : Notifier les utilisateurs lorsque des mises à jour sont disponibles
Maintenant que vous avez configuré le mécanisme de mise à jour de base de votre application, vous devez vous assurer que l’utilisateur sera notifié quand il y a une mise à jour. This can be achieved using the autoUpdater API events:
autoUpdater.on('update-downloaded', (event, releaseNotes, releaseName) => {
const dialogOpts = {
type: 'info',
buttons: ['Restart', 'Later'],
title: 'Application Update',
message: process.platform === 'win32' ? releaseNotes : nomrelease,
détail:
'Une nouvelle version a été téléchargée. Redémarrez l'application pour appliquer les mises à jour.'
}
dialog.showMessageBox(dialogOpts).then((returnValue) => {
if (returnValue.response === 0) autoUpdater.quitAndInstall()
})
})
Also make sure that errors are being handled. Voici un exemple pour les renvoyer sur stderr:
autoUpdater.on('error', (message) => {
console.error('There was a problem updating the application')
console.error(message)
})
Puisque que les requêtes faites par la mise à jour automatique ne sont pas sous votre contrôle direct, vous pouvez vous trouver dans des situations difficiles à gérer (comme lorsque le serveur de mise à jour est protégé par une authentification). Le champ url supporte le protocole file:// , ce qui signifie qu'avec un peu d'effort, vous pouvez contourner l'aspect communication avec le serveur du processus en chargeant votre mise à jour depuis un répertoire local. Voici un exemple expliquant comment cela pourrait fonctionner.
Update server specification
For advanced deployment needs, you can also roll out your own Squirrel-compatible update server. For example, you may want to have percentage-based rollouts, distribute your app through separate release channels, or put your update server behind an authentication check.
Squirrel.Windows and Squirrel.Mac clients require different response formats, but you can use a single server for both platforms by sending requests to different endpoints depending on the value of process.platform.
const { app, autoUpdater } = require('electron')
const server = 'https://your-deployment-url.com'
// e.g. for Windows and app version 1.2.3
// https://your-deployment-url.com/update/win32/1.2.3
const url = `${server}/update/${process.platform}/${app.getVersion()}`
autoUpdater.setFeedURL({ url })
Windows
A Squirrel.Windows client expects the update server to return the RELEASES artifact of the latest available build at the /RELEASES subpath of your endpoint.
For example, if your feed URL is https://your-deployment-url.com/update/win32/1.2.3, then the https://your-deployment-url.com/update/win32/1.2.3/RELEASES endpoint should return the contents of the RELEASES artifact of the version you want to serve.
B0892F3C7AC91D72A6271FF36905FEF8FE993520 https://your-static.storage/your-app-1.2.3-full.nupkg 103298365
Squirrel.Windows does the comparison check to see if the current app should update to the version returned in RELEASES, so you should return a response even when no update is available.
macOS
When an update is available, the Squirrel.Mac client expects a JSON response at the feed URL's endpoint. This object has a mandatory url property that maps to a ZIP archive of the app update. All other properties in the object are optional.
{
"url": "https://your-static.storage/your-app-1.2.3-darwin.zip",
"name": "1.2.3",
"notes": "Theses are some release notes innit",
"pub_date": "2024-09-18T12:29:53+01:00"
}
If no update is available, the server should return a 204 No Content HTTP response.