+100，这对减小应用程序的大小非常有帮助。

Subash 于 2014-10-01

可以更改.asar扩展名吗？匈牙利语听起来很奇怪。基本上这将意味着the shit以一种不好的方式（链接）。

ghost 于 2014-10-01

😄75

.apak?说真的，有很多语言，所以几乎任何扩展在其中一些听起来都很奇怪。

IMO 运行时安装和更新应尽可能简单。许多运行时都有非常烦人的通知。此外，如果您要执行此操作，则应提供一些额外的清单元数据，因为较新的应用程序版本可能无法在旧运行时运行，因此您需要将当前运行时版本与应用程序清单中的版本进行比较（甚至可能与节点中的版本范围相同） packages )，然后如果需要更新运行时，请尽可能简化此过程。我不知道对大多数人来说有多容易，但对我来说它只是带有进度条或状态消息的窗口（“正在下载... 57%”、“正在更新...”）
我不确定，但也可以考虑后台更新。它可能是一些更新服务或只是在应用程序运行时运行时下载并在应用程序关闭时更新。

YurySolovyov 于 2014-10-03

为此+1。我正在开发一个必须为 mac 和 windows 交付的应用程序，这将大大简化交付。

malcolmalex 于 2014-10-21

👍2

这太棒了！

一些想法：

正如@YuriSolovyov所说，我们需要一种方法来声明特定 asar 兼容的原子运行时版本。最好，这也应该允许指定一个确切的版本，因为这可以减轻发布基于 asar 的应用程序时 QA 的负担。
- 为了支持这一点，我们需要允许并排安装多个版本的 atom-runtime，这对用户来说可能是不可见的。
- 请注意，这与限制下载大小的理想有些不一致。但是，一家生产多种基于 asar 的产品的公司可以在内部进行标准化，因此他们的所有应用程序仍然使用相同的版本。
你没有提到在 Mac 上自动更新 atom-runtime 的支持，但这会_非常_有用。
与其在 linux 上仅安装源代码，不如通过 .deb/.rpm 包以及一些不需要 sudo 权限来安装（即每个用户）的方法来支持安装/更新二进制文件。对于按用户安装的运行时，自动更新也非常有用。
是否有任何支持使安装的 asar 文件保持最新 - 还是必须在每个应用程序中独立实施？

最后，这项工作的时间表是什么？如果我想开始实施其中的一部分，最好的开始方式是什么？我愿意贡献。

joshuawarner32 于 2014-10-22

@joshuawarner32目前这只是一个粗略的想法，我计划在解决 atom-shell 的一些主要问题后进行工作，但可能要几个月后。

zcbenz 于 2014-10-23

我认为还值得研究现有的运行时以及它们是如何工作/更新的、它们有多么令人不安以及其他优点和缺点。

YurySolovyov 于 2014-10-23

目前这只是一个粗略的想法，我计划在解决 atom-shell 的一些主要问题后进行工作，但可能需要几个月后。

已经有5-6个月了。实现这一点真是太好了。

steelbrain 于 2015-03-12

👍4

我们已经建立了一个非常适合我们特定用例的内部实现，我们可能能够将其上游化。危险在于它实际上对我们的用例来说太具体了，没有其他人会对额外的复杂性感兴趣。

以下是我们设计的亮点：

为服务器上的多个不同应用程序部署 .asar.gz 文件
向用户分发单个构建的 atom-shell，它不会为特定应用程序捆绑任何代码
在应用程序启动时，下载适当的 .asar.gz 文件（如果它不存在，或者服务器上有更新的文件）。提取它并运行包含的应用程序。
我们的 atom-shell 构建接受--app参数来指定要下载/运行的应用程序

这就是原子壳人的想法吗？这样的东西对其他人有用吗？

joshuawarner32 于 2015-03-13

与 JRE 一样，它可能是 ERE（电子运行时环境），带有 .eapp 文件（电子应用程序）

tonypee 于 2015-05-04

❤12 👍2

-1 为 .eapp

steelbrain 于 2015-05-04

👍13 👎9

+1 我需要它！

sergeysova 于 2015-08-25

在 Windows 上，我们可以为 atom-runtime 提供安装程序和自动更新程序，并注册要使用它打开的 .asar 文件类型。

在 Windows 上安装 Steam 并查看他们如何创建游戏快捷方式，他们实际上使用协议处理程序，它相对聪明

anaisbetts 于 2015-08-25

👍10 ❤1

:+1: 在 Steam 模型上。

实现这一点没有技术障碍，整个事情可以只是一个 Electron 应用程序本身。但问题是实施起来也不容易，考虑到所有细节，我认为这需要一个小团队全职工作，我不确定它是否会发生。

zcbenz 于 2015-09-01

但问题是实施起来也不容易，考虑到所有细节，我认为这需要一个小团队全职工作，我不确定它是否会发生。

在我的脑海里有很多问题，虽然肯定不是不可克服的，但让这个计划变得困难。例如，假设“App 1”需要 0.30.x 并且不能在 0.31.x 上运行，而“App 2”需要相反。谁在这种情况下获胜？

似乎需要很多努力和基础设施/技巧来优化不是我们最大问题的东西 - 磁盘空间和带宽，以牺牲开发人员的复杂性为代价（即现在开发人员必须创建这个疯狂的链安装程序才能首次安装/验证 Electron，然后安装他们的应用程序）

我不是要讨厌一个想法！我只是认为，随着我们花时间做这件事，我们可以把它花在我们的大问题上——让新开发者创建和发布 Electron 应用程序变得非常容易，从他们的第一行代码一直到将其发送给用户

anaisbetts 于 2015-09-01

👍2

@paulcbetts但是，嘿，它的好处是值得的，不是吗？更新应用程序时，用户必须下载不到 1 mb 而不是约 70mb。这意味着我们甚至不需要自动更新框架和所有东西，我们只需要下载并提取包含几个文件的 micro-zip 存档。

过去三个月我在一个速度低于 128kbps 的偏远地区度过，相信我，升级大小是一个巨大的痛苦，最糟糕的是仍然有很多人处于类似情况

steelbrain 于 2015-09-01

👍5

这意味着我们甚至不需要自动更新框架，我们只需要下载并解压一个包含几个文件的 micro-zip 压缩包。

不过我认为这不是真的，因为几乎可以肯定在某些时候你会想要更新到新版本的 Electron，然后是 kerplowie，你处于类似的状态（或者至少一个同样丑陋的)

anaisbetts 于 2015-09-01

基本应用程序现在在 30 到 50 Megs 之间，除非您的包中有大量视频。我认为对于大多数人来说，下载这些内容并不困难。我相信 youtube 视频的平均大小在 30 到 40 mb 之间...

RIAEvangelist 于 2015-09-01

👎28 👍3

我想在这里说明一下，在中国，连接速度平均约为 20kB/s（当然，我的连接速度比我所在城市的 ~92% 慢。）更新 Atom/electron 通常需要一整天的时间wget -c 'ing。除非用淘宝镜。

对于版本兼容性，电子开发进展太快而无法拥有一个包罗万象的版本，也许某种包装器/帮助器可用于在应用程序启动时使用/下载请求的主要版本？

JoshTheDerf 于 2015-09-01

👍5

20 KB/秒？你怎么能活下来？我无法想象这会让事情变得多么困难！

RIAEvangelist 于 2015-09-01

@steelbrain不是我的本意

RIAEvangelist 于 2015-09-01

@RIAEvangelist在快速的时间和大量的耐心中继续前进。速度在深夜变得非常快，因此只需在您睡觉时保持下载运行或计划。 :3

无论如何，我认为编写（基本）第三方包装器不会太多工作，有人想尝试吗？

但是，.asar 文件不能轻易声明其电子版本。也许需要另一个程序描述符系统？

JoshTheDerf 于 2015-09-01

某种运行时版本调度程序（如果需要，下载和）启动器需要您的应用程序的运行时版本怎么样？为此，我们可以在 package.json 中添加一个条目。

YurySolovyov 于 2015-09-01

@YuriSolovyov除了我们不能说默认情况下运行时处理 .json 文件。我想它可以先读取 asar 文件并查看 package.json，但这会减慢它的速度。

JoshTheDerf 于 2015-09-01

@Tribex是的，逻辑流程是这样的：

-> associate .asar with runtime
-> user launches .asar app
-> dispatcher reads package.json in .asar
-> (optional) downloads required runtime version if needed
-> launches app

YurySolovyov 于 2015-09-01

理想情况下，运行时模式应该像 Steam 或Chrome App Launcher那样工作。主要问题是当运行时升级到新版本时我们如何处理应用程序。

Electron 应用程序受到 Electron 升级的影响，尤其是节点原生模块。由于 C++ ABI 问题，每次升级 Electron 都需要重建原生模块（用户报告了几个忘记重建的崩溃问题）。

Steam 没有痛苦，因为 Steam 上的每个游戏都是一个独立的程序，实际上您可以在没有 Steam 客户端的情况下启动游戏。 Chrome App Launch 也没有，因为 Chrome 应用程序是用 HTML/JS/CSS 这些解释性语言编写的，因此在不同版本的 Chrome 中运行没有差距。

hokein 于 2015-09-01

@hokein我们有一个本地语言的轻量级“客户端”怎么样，它可以下载多种语言，每当遇到依赖于已卸载电子版本的应用程序时，它都会下载它的副本，然后使用它的特定电子运行每个应用程序。

steelbrain 于 2015-09-01

👍2

大约每周发布一次新的 Electron，因此 2 个应用程序具有完全相同版本的 Electron 的可能性很小。

为了支持运行时方法，我们可能需要开始将发布分为 LTS（长期支持）版本和前沿版本。 LTS 将用于生产，而前沿将用于开发和测试。 LTS 只会得到错误修复，并且可能会进行一些不会取代主要 io.js 和内容 shell 版本的更改，因此本机模块应该仍然可以工作。

etiktin 于 2015-09-01

👍5

鉴于@etiktin所说，除非用户在他们的系统上有许多电子应用程序，否则下载时间可能没有任何好处，因为他们仍然必须每次都下载运行时间。

在这两周里，我一直在看电子，现在我想我已经看到了 4 个版本。

RIAEvangelist 于 2015-09-01

@etiktin理想情况下，如果电子遵循 semver，那么应用程序可以声明版本 ^0.31，并且它将使用最新的 0.31.x 版本。这可能会有所帮助。

JoshTheDerf 于 2015-09-02

👍1

我们有一个正在生产的应用程序，它具有 semver 自动更新机制，它执行以下操作：

在服务器上获取一个简单的 HTTP 端点，提供应用程序的当前版本（0.3.0、0.3.1 等）和平台（darwin-x64、win32-ia32、win32-x64 等）。
如果有更新版本，服务器返回“304 Not Modified”或 JSON 清单。
JSON 清单本质上是较新版本中的文件夹、文件和符号链接的嵌套列表。
JSON 清单中的文件夹条目如下所示：[名称，子条目数组]。
JSON 清单中的文件条目如下所示：[名称、内容哈希、内容哈希数组拆分为 64KB 块、指示文件是否可执行的整数标志]。
JSON 清单中的符号链接条目如下所示：[名称，目标路径]。
这些 JSON 清单是针对每个版本在服务器上创建和缓存的。对于 JSON 清单中的每个文件，服务器运行一个简单的重复数据删除算法，使用内容相关的分块将文件拆分为可变长度的块，然后使用 SHA256 对这些块进行哈希处理。这确保了同一文件的不同版本的大多数块散列保持相同，即使内容被移动了几个字节。平均块长度约为 64KB，以获得最佳的重复数据删除 + 压缩效率。如果块较大，它们也不会进行重复数据删除，如果块较小，它们也不会压缩。对于非常大的文件，平均块长度也会增加，以避免元数据中有太多的块哈希。
当应用程序从服务器接收到新的 JSON 清单时，它会检查可用磁盘空间并创建一个具有通用唯一 ID 的新临时目录。使用其旧的本地清单作为起点，然后从本地文件复制块或从服务器下载丢失的块以重新创建新的清单。创建新版本后，它会验证所有文件内容的目录结构和签名。如果下载中有任何损坏，它会删除更新。
如果新更新通过清单验证成功，则它会在新更新路径上启动新版本的应用程序。
旧版本注意到另一个版本正在运行，并自行关闭。
新应用程序等待旧版本关闭，然后将自身复制到另一个临时目录，将旧版本重命名为存档目录，并将临时目录重命名为旧版本的位置 (/Applications/Ronomon.app)。然后它会再次自行运行，但现在从旧版本的位置 (/Applicatons/Ronomon.app) 运行，然后清理存档目录。
如果在转换过程中出现任何问题，旧版本将保留在规范路径中，直到被重命名调用切换。

总的来说，它在生产中运行良好。重复数据删除和压缩意味着典型的主要版本更新只需要下载大约 33% 的内容，而次要更新只需要 1-2 MB，具体取决于应用程序。自动更新将 Electron 和应用程序代码作为一个原子单元处理，并且在此过程中从不违反任何代码签名。

jorangreef 于 2015-11-19

+1想法
+1重命名asar

sergeysova 于 2015-11-19

我下来提出一个关于这个的问题。发现这个已经存在，所以我会把我的 + :100: 放到这个
我们完全需要 JRE 或 .NET 或 Adobe Air 之类的解决方案，因为将运行时与每个应用程序打包在一起会使它们变得非常庞大。

championswimmer 于 2015-11-23

关于将运行时与应用程序分开的任何更新？

这是因为已经开发了解决方案而关闭了吗？

PierBover 于 2016-01-18

@PierBover这个问题是开放的。

这 - https://github.com/KeitIG/museeks/issues/48 - 已关闭。在别人的存储库中。

championswimmer 于 2016-01-18

哦，谢谢@championswimmer ，很抱歉造成混乱。

那么有没有关于独立运行时的消息？这是正在处理的事情吗？

PierBover 于 2016-01-18

@PierBover由于当前版本的碎片化，它可能不会很快发生（很难找到使用相同版本的 2 个电子应用程序）。也许在 v1 发布之后。

@jorangreef你在所有平台上都使用你的差异更新机制吗？如果您可以将该代码作为独立模块发布，那就太棒了。

etiktin 于 2016-01-18

@championswimmer 是的，我已经成功地为我的应用程序创建了一个构建脚本，所以我现在可以分发我的应用程序了。但我一直在关注这个，因为它会很有趣。

martpie 于 2016-01-19

@etiktin是的，差异自动更新目前适用于所有平台。如果它还包含一个用于下载的最小安装程序，那么该安装程序可以由多个应用程序共享，并使用缓存版本的 Electron（如果已经可用）。这将使安装速度更快。如果人们有兴趣，我想开源它，并将在未来几个月内尝试发布代码。

jorangreef 于 2016-01-19

例如，假设“App 1”需要 0.30.x 并且不能在 0.31.x 上运行，而“App 2”需要相反。谁在这种情况下获胜？

然后他们应该安装两个版本，会有两个运行时，就像 VS C++ 2008 和 2005 共存一样。我非常喜欢 VS C++ 运行时的安装方式，如果没有，安装程序会安装所需的版本，其他可以依赖稍后，不同的运行时可以共存。在安装程序中执行版本要求似乎也更容易。

louy2 于 2016-02-20

@louy2 Visual C++ 示例（版本之间为 3 年）和 Electron（每月至少 3 个版本）之间存在差异

martpie 于 2016-02-20

如果大多数人在
Electron 生态系统中的应用程序不兼容 +- 0.0.1 或
0.1.0版本差异

2016 年 2 月 20 日 18:55，Pierre de la Martinière <
通知@github.com> 写道：

@louy2 https://github.com/louy2有区别
Visual C++ 示例（版本间隔 3 年）和 Electron（每个版本 3 个版本）
至少一个月）
—
直接回复此邮件或在 GitHub 上查看
https://github.com/atom/electron/issues/673#issuecomment -186595285。

championswimmer 于 2016-02-20

👍3

+1

iamtekeste 于 2016-03-19

我已经使用fpm将电子打包到 .deb 包中。这可能是 Linux 上的一个公平起点（至少基于 Debian 或 RPM）。你可以看看这里： iamale/electron-deb ；还有一个示例应用程序。（它也适用于 asar，只需要在运行时包中添加一个 MIME 条目。）

如果我们在其他平台上也有类似的东西，那就太好了！我可能会尝试为 Windows 打包它，但我不再积极使用它，并且真的没有太多使用它的经验。

（感谢@louy2向我指出这个线程！）

notpushkin 于 2016-03-22

顺便问一下，.asar 的 MIME 类型是什么？ application/x-asar会这样做吗？

notpushkin 于 2016-03-22

@iamale而不是fpm ，您是否看过AppImageKit 。您获得的主要好处是，您可以使用一个可执行文件来定位所有 Linux 发行版，而不是创建多个库和所有库。您也不必再要求用户安装任何依赖项，因为它们与可执行文件捆绑在一起。这是一个不错的项目，请看看。

关于哑剧， application/x-electron怎么样？

steelbrain 于 2016-03-23

👍2

@steelbrain这是个好主意。然而，这并不能解决最初的问题：Electron 运行时必须与每个应用程序一起打包（因为图像必须是自包含的），这正是这个问题所要解决的问题。虽然我认为从 Electron 应用程序中制作 AppImages 应该相对容易，而且我相信当不能使用传统的包管理（稀有发行版或未授权用户）时这会很棒。所以，谢谢你指出！

顺便说一句， application/x-electron听起来很棒，可能会坚持下去。

notpushkin 于 2016-03-23

添加了asar支持！尚未在存储库中，将在今天晚些时候或明天重建它。目前，您可以在 transfer.sh 上获取包（链接将在接下来的 2 周内有效）

notpushkin 于 2016-03-23

您需要在 .asar 中添加一个 asar.json，以告知：

推荐版本
兼容版本
完成后，您需要一个使用电子（任何版本）的应用程序来检查网络（1）自身的更新（检查器）和（2）计算机中的现有版本，然后如果存在兼容版本，它会解析打开的.asar的打开路径，否则下载推荐版本并再次检查。该应用程序本身可以用 Electron 或 python 编写（因为它只需要最少的 UI 或不需要 UI）。

sapioit 于 2016-05-04

这个想法是：检查是否下载了所需的电子版本的应用程序与所需的电子版本无关。

如果需要，您可以更新 default_app 的内容，以及应用程序的其余部分，但它除外。

在那里，您可以使用app.setPath("userData", __dirname + "/ElectronVersions");保存版本，然后可以将这些版本单独留在那里，并根据需要安装新版本。

sapioit 于 2016-05-04

您是否看过AppImageKit而不是 fpm。

在https://bintray.com/probono/AppImages/Atom/_latestVersion#files上有一个 Atom 的 AppImage - 只需下载chmod a+x ，并在任何不太过时的 x86_64 Linux 发行版上运行。

probonopd 于 2016-05-05

问题不只是 Linux，我们需要一种方法让它跨操作系统，这意味着我们需要能够让它在 Linux、Windows 和 Mac OSx 上运行。

sapioit 于 2016-05-05

某种特定于操作系统的启动器，用于查找运行时是否可用并且是最新的/与 asar 包兼容

YurySolovyov 于 2016-05-05

（多年后）让我总结一下讨论：

@zcbenz提出了一个管理本地 Electron 实例的运行时，因此.asar包仅被分发，并且避免了捆绑 Electron 二进制文件。运行时还管理.asar包的执行。
@YurySolovyov建议使用附加信息（例如所需的 Electron 版本）增强清单文件，以便运行时知道哪个版本将用于哪个.asar包。这里给出了这种方法的概述。
@joshuawarner32介绍了多个运行时版本、二进制打包（例如.deb ）和.asar包的自动更新的想法。此外，还考虑了分发服务器的想法。
@paulcbetts建议看一下 Steam 模型并实现类似的东西。他指出了支持不同 Electron 版本等的本地运行时概念的复杂性。
[人们讨论中国的互联网速度和他们的童年事务]
@hokein指出了升级运行时的复杂性。特别写。需要针对 Electron 头文件再次构建的本机模块。
@etiktin希望拥有 LTS 和前沿版本，因此生产就绪的应用程序使用 LTS 而不是前沿。
@Tribex说，如果我们坚持语义版本控制，我们不需要拥有 _all_ 版本的本地实例，而只需要那些不兼容的版本。
@jorangreef为他们自己的应用程序提供了一个已经在生产中的差异自动更新系统的示例。
@iamale构建了一个 Electron 的 fpm 包来执行.asar包。

_disclaimer：我试图只包括讨论的要点。如果我错过了什么，请原谅！_

yan-foto 于 2016-05-27

👍10 😄6 ❤5

我阅读了这里的讨论，试图总结要点并想解决其中的一些问题。具有“深度平台集成”的运行时概念超越了简单的本地实例。将定义一个最小可行产品，它充当系统范围的运行时。我还添加了一个不错的功能，它可能会派上用场。最后一部分描述了需要实现哪些更改/功能。

理由：

大多数开发人员正在做的事情（即捆绑电子二进制文件）就像静态链接所有共享库！这就像我们卖的每一个披萨都送烤箱一样。

最有价值球员：

环境管理器：跟踪本地可用的 Electron 实例。它可以用来决定哪个包与哪个实例兼容（使用增强的package.json [见下文]）。它还应该注意为要运行的包设置正确的环境变量。
更新管理器：已经讨论了自动更新（+通知）和差异自动更新的可能性。将它作为一个负责将本地实例更新到最新版本的守护进程会很好。

很高兴有：

包/依赖管理器：就像Atom 的apm一样，需要一个包管理器来下载.asar包（从 GitHub 或给定的 URL 等）并在本地安装它们（类似于apt-get在 Ubuntu 中或brew在 Mac 中）。

要求：

增强的清单文件： package.json还应该包含一个semver （或 semver 范围）来表示需要哪个 Electron 版本。
定义的安装/卸载程序：ATM .asar包包含运行应用程序所需的一切。但是，可以在安装时只提供源和下载依赖模块。如果我们过于勇敢，我们可以拥有某种 _global_ 目录，其中包含所有应用程序的依赖项（npm 3 的扁平结构可能会有所帮助）。然而，这可能会变得非常复杂，非常快（例如在卸载应用程序时）。
多个本地运行时：如果到目前为止已应用语义版本控制，则只有0.x和1.x两个不兼容的版本。次要版本和补丁应该是向后兼容的，所以我们只需要系统上最新版本的0.x和1.x 。

启示：

环境/依赖管理器：Python 的virtualenv ，Ruby 的rbenv ，另见ruby-build 。
包管理器：Python 的pip ，Atom 的apm 。
更新管理器： Chromium 的zygote进程对_静默、后台_更新有一种有趣的方法。
代码翻译器（以适应新的 API）：Pythons 2to3 。

yan-foto 于 2016-05-27

👍4

epm （电子包管理器）似乎已经被当作名字......
也许调用运行时elec和应用程序.tron ？ TRON 可能存在一些商标问题，但听起来很酷；）

Simran-B 于 2016-06-21

可能是uepm （通用电子包管理器），因为它意味着要在 Electron 支持的所有操作系统上运行...或epmc （电子包管理中心）和文件.epack （电子包）。至少，这个扩展听起来比.tron好，并且不能与电影混淆（“给我那个 tron 的东西，伙计”_递给你电影_）。

sapioit 于 2016-06-21

与电子有关的理论物理领域也有一大堆词

费米子
轻子
收费
库仑
保利

而且，不直接相关，但更符合包管理器的情况，

玻色子
;)
（我相信光子已经被拍摄了）

kapouer 于 2016-06-21

@kapouer +夸克？不确定它是否被采取

YurySolovyov 于 2016-06-21

夸克被拿走了，其他的我不知道。但是，当这个建议列表建议不要维持现状时，为什么我们必须保持现状呢？但既然我们在它上面，为什么不把它命名为 Hauldron 呢？从 LHC 拍摄。对撞机不是一个好主意，它给产品带来了负面影响，因为它的含义与战争紧密相关......

sapioit 于 2016-06-22

Particle(s) ? 虽然很长。
wiki中的粒子列表

虽然命名很重要，但我仍然认为我们需要首先研究运行时/更新/打包/分发语义。

YurySolovyov 于 2016-06-22

👍2

lepton看起来很完美，因为它是电子所属的粒子家族。

gunn 于 2016-06-22

👍2

有点超出范围的想法：一个更通用的运行时管理器会更棒（而且实现起来并不难）。例如，我们也可以包含@nwjs二进制文件并在相同的版本管理器中管理它（就像@asdf-vm，但用于GUI 运行时）。

notpushkin 于 2016-06-28

又快又脏： https://github.com/iamale/lepton。目前仅支持固定版本（semver 是下一步要做的事情），并且应用程序已解包（即还没有 .asar-s）。

notpushkin 于 2016-06-30

❤3

好的！

sapioit 于 2016-06-30

+1

pavankumarkatakam 于 2016-07-07

👎9

即使没有.asar， @iamale ，只要你有办法知道要打开哪个文件，我认为应该没问题。例如，你可以有一个file.something和 json 代码链接到package.json所以它知道要打开什么......

sapioit 于 2016-07-07

这是一个非常疯狂的想法，但是如何在package.json中使用electron字段来制作
任何（嗯，不像任何，但任何准备好的）npm 包可执行文件？
喜欢：

electron: {
  "main": "index.js",
  "runtime": ">= 1.2"
}

这可以通过增加electron安装 npm 包并使它们对主机系统可执行和可见的能力来实现。
就像

electron install atom

为此，我们需要拆分electron命令和实际的运行时捆绑包。

YurySolovyov 于 2016-07-07

但是将 package.json 重命名为package.electron并让它的内容像这样呢？

run:{
  "name"    : "zDillinger",
  "version" : "0.0.1-1",
  "main"    : "main.js"
},
electron: {
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

在这个例子中，它会推荐使用电子 1.2，如果没有找到它还检查 1.2.1 和 1.2.5 之间是否有任何版本，如果没有则检查 1.3.1，然后检查 1.3.0.1，如果没有，它会检查对于 1.1，如果没有，请下载 1.2。

也许有类似的东西会自动下载推荐的版本，但它不能，然后它会检查兼容的版本。并取出每一个兼容的并检查它们，如果没有工作，请询问用户是否不想使用不兼容的版本，如果他们按下no ，它将以不兼容的版本运行在 PC 上找到，如果没有找到，而不是要求使用不兼容的版本，而是显示一个错误弹出窗口，说没有检测到电子安装。

sapioit 于 2016-07-07

@sapioit拥有一个单独的清单对我来说听起来是个好主意。拥有自定义文件扩展名会大大简化事情。（虽然 .electron 似乎有点长。）

也许根据@iamale的轻子，.lept？

JoshTheDerf 于 2016-07-07

我没有看到不使用package.json的任何好处，电子场做了隔离部分。 Babel 和 ESlint 使用这种技术并且做得很好。
这使得将应用程序直接发布到/通过 npm 变得更加容易。

YurySolovyov 于 2016-07-07

是的，我第二个@YurySolovyov - 我认为把它放在package.json更合适

lenovouser 于 2016-07-07

@YurySolovyov附加文件的优点是运行时可以为附加文件的扩展名注册一个处理程序并作为文件的默认打开器自动运行。而使用 package.json 执行此操作需要为每个 JSON 文件注册处理程序，这对用户来说会很痛苦。

JoshTheDerf 于 2016-07-07

@Tribex公平点。
也许 package.electron 可能只是某种告诉运行时"Hey, take a look at package.json, it should contain the info on how to launch it"的链接。这是一个“疯狂”的想法，所以是的，我可以调整它。

YurySolovyov 于 2016-07-07

我同意@tribex ，我们确实需要一个单独的文件，或者重命名 package.json。到别的东西。

sapioit 于 2016-07-07

@wurysolovoyov你不能那样做。您可以打开文件的唯一方法是附加扩展名，在这种情况下，每个扩展名都将使用相同的软件打开。因此，除非您对无法使用electron以外的任何其他内容打开.json感到满意（除非打开了适当的电子应用程序，否则只会出错），您仍然可以这样做，但是让我们，那些希望能够打开.json文件的人，能够使用我们想要打开它们的程序来打开它们。

sapioit 于 2016-07-07

否则，您将无法编辑文件，除非先打开编辑器，或者每隔一分钟左右更改打开.json的内容。

sapioit 于 2016-07-07

我的意思是@YurySolovyov不是@wurysolovoyov

sapioit 于 2016-07-07

也许我没有说清楚： package.electron的目的只是作为该目录是应用程序的标记，以便运行时可以引用同一文件夹中的package.json ，并启动应用程序。如果您直接打开package.json ，它将在您的操作系统中与.json关联的任何内容中打开。

有点像快捷系统。

YurySolovyov 于 2016-07-07

@YurySolovyov在这种情况下，我们是否在 package.json 或 package.electron 中定义该信息只是一个品味问题。我个人会把它分开，因为它对我来说看起来更干净。不过，也许 package.json 中的引擎属性就足够了。

JoshTheDerf 于 2016-07-07

@Tribex这也是将应用程序发布到 npm 的要求 - 具有有效的package.json

YurySolovyov 于 2016-07-07

@YurySolovyov对。如果我们使用 package.electron package.json 仍然存在。 .electron 仅用于定义运行时信息，或者根据您的建议，仅用作标记。

JoshTheDerf 于 2016-07-07

🎉1

基本上， package.electron只会作为可启动的_marker_存在，因此 package.json 仍将与它自己的数据一起存在，但这就是需要单独文件的原因： _双击打开应用程序_。我仍然希望能够将package.electron重命名为my-app.electron或my-app.electron 。

sapioit 于 2016-07-07

@sapioit当然，这就是拥有.electron文件的全部意义，您可以随意命名它，只要它具有.electron扩展名。

YurySolovyov 于 2016-07-07

让运行时处理程序必须查看 *.electron，然后查看 package.json 以确定要运行的电子版本，然后再次读取 package.json，对我来说似乎仍然不是很干净。

JoshTheDerf 于 2016-07-07

@Tribex为什么你认为 package.json 会被读取两次？

如果我们将运行时信息放入.electron文件中，运行时将使用package.json启动应用程序，假设一切都正确，否则会快速失败。
如果我们将运行时直接放入package.json或在electron部分下，那也只需要 1 次读取。这样，我不确定将什么放入.electron文件（想法？），即使它是空的我也可以。

YurySolovyov 于 2016-07-07

@tribex .electron可以指向package.json ，以防万一，由于某些原因， package.json 被重命名。这样，您可以为NPM使用 $# package.json #$ 为 Electron 使用不同的package.json （可能是electron.json ）。为什么？也许您希望您的应用程序具有 package.json 以了解要使用包管理器导入哪些内容，但是一旦导入，您希望在不需要移动或重命名文件的情况下运行它。

_ app.electron _

{
  "package": "package.json",
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

要么

_ myapp.electron _

{
  "package": "electron.json",
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

sapioit 于 2016-07-07

👍1

或者，如果我们将所有内容都放入package.json ，我们可以将.electron仅链接到我们想要用来打开应用程序的.json ，因此：

_ app.electron _

{
  "package": "package.json"
}

要么

_ myapp.electron _

{
  "package": "electron.json"
}

sapioit 于 2016-07-07

👍1

此外，也许您希望在同一目录中有两个启动器，一个用于客户端，一个用于服务器，客户端使用服务器的文件来启动只有一个播放器的本地服务器。这样，您不需要复制所有 99% 的文件（假设您有一个使用 500+ MB 文件的游戏）和 5-6 个不同的文件，并将它们放在两个单独的目录中，但只需要一个额外的文件以便能够自行启动服务器。 从字面上看，与在同一目录中具有多个可执行文件相同。

sapioit 于 2016-07-07

单独的package.electron应命名为package.electron.json或具有扩展名.json的名称，以便编辑器和 IDE 正确确定语法。

StreetStrider 于 2016-07-07

@StreetStrider我宁愿教IDE .electron实际上是有效的.json 。
这也让我们指出我们与@sapioit讨论过的关于.json关联的问题。我认为任何流行的操作系统都不支持双重扩展关联。 ( .foo.bar )

YurySolovyov 于 2016-07-07

👍1

您可以在编辑时添加 .json 扩展名。或右键单击并使用编辑器打开，但就像 Adobe Air 一样，默认情况下，它会使用启动器打开文件，允许用户使用编辑器打开文件，这不会导致任何问题。

sapioit 于 2016-07-07

@sapioit公平点，我想我同意你关于指向 package.json 的观点。

JoshTheDerf 于 2016-07-07

对我来说，运行时和播放器是两个不同的东西。现在，这更像是一名球员。而且它似乎不会在习惯于包管理器概念的技术倾向社区之外得到任何广泛使用。

手头的问题是创建一个运行时。有点像 JRE 和 .Net。不是玩家。

baconbrad 于 2016-07-07

👍2

@baconface也许你可以详细说明？目前尚不清楚您在这里所做的区分是什么。

JoshTheDerf 于 2016-07-07

@baconface是的，但是 JRE 和 .Net 也都可以安装。
没有 JRE， .jar文件与没有electron运行时的包一样无用。

YurySolovyov 于 2016-07-07

理想情况下，该工具将与安装电子的主要方法一起分发或作为安装电子的主要方法，理想地缓解传播问题。

JoshTheDerf 于 2016-07-07

为此，您只需要一个小工具来制作可执行文件，该可执行文件将启动某个文件，即.electron估算。就那么简单。

sapioit 于 2016-07-08

.lept看起来很棒，谢谢！

我个人认为没有必要发明任何新的配置， pkg.engines在这里对我来说看起来很简单（它应该允许一些复杂的 semver 表达式，比如来自npm's docs 的1.x || >=2.5.0 || 5.0.0 - 7.2.3 ，所以不需要{ recommended, compatible, etc } -我相信@sapioit的示例中的结构）。（不过，我添加了一个lepton字段，因为scripts.run通常由npm start调用，并且轻子通过添加自己的$VARIABLES有点破坏了它的语义.)

notpushkin 于 2016-07-08

或者，如果我们将所有内容都放入 package.json，我们可以将 .electron 链接到我们想要用来打开应用程序的 .json

在我看来也不是一个好主意。如果我们有一个包含多个入口点的包，我们仍然可以将它们全部放在一个 package.json 中，就像我们现在有一个scripts映射一样。我在想这样的事情：

// package.json
{
  "engines": {
    "node": "4.x",
    "electron": "1.x"
  },
  "lepton": {
    "run": "$ELECTRON .",
    "server": "$NODE ./server.js",
    "server-debug": "$NODE ./server.js --debug"
  }
}

# lepton-run [DIR OR TARBALL] [CONFIGURATION]
$ lepton-run . # the default configuration is `run`
$ lepton-run . server
$ lepton-run . server-debug

然后，如果你真的想要它作为可执行文件，在 Linux / macOS 上你可以使用简单的 shell 脚本（包括 #!shebang 在内的 3 行），在 Windows 上......好吧......¯_(ツ)_/¯

notpushkin 于 2016-07-08

首先，您可能想看看这篇文章，它提供了一个更好的 semver 替代方案，同时仍然与几乎所有的东西兼容： Release.Breaking.Feature.Fix或者为什么语义版本应该被显式版本控制替换为尽快

其次，问题是如何真正区分它们。我的意思是，如果server.js已经接受了--debug参数，为什么还要为此烦恼，并且不允许人们拥有自己的文件配置。也许服务器需要与客户端不同的配置，例如客户端在2.2-2.4上工作，而服务器只在1.4-1.9.2.1上工作......
按照你的建议去做，我们只会受到更多的限制。

另外，如何使用更多变量，而不仅仅是--debug ？我将如何使用更多类似的变量来运行它？这样做安全吗？毕竟，如果我想要一个文件来执行此操作，我什至可以使用单独的文件来完成它，但是这样会混淆运行带有参数的.lept文件的可能结果。

如果我想使用调试参数运行服务器，我不会简单地使用--debug参数启动 .lept 吗？或者我可以创建另一个文件以使用--debug参数启动该文件。不是那么简单吗？
我希望我是有道理的...

sapioit 于 2016-07-08

首先，您可能想看看这篇文章，它提供了一个更好的替代 semver

我认为这是一个很棒的点子！不过，我认为 Electron 不会切换到这种版本控制方案。我还相信，虽然它对最终用户产品非常有用，但对于库、引擎、运行时和其他东西，我们并不真正需要它。 理想情况下，用户甚至不应该知道他们正在运行哪个版本的 Electron （除非他们想知道）。

也许服务器需要与客户端不同的配置

这可能是个问题，但我无法想象一个需要多个运行时版本的项目。

如果我想使用 debug 参数运行服务器，我不会简单地使用 --debug 参数启动 .lept 吗？

是的，为什么不：

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug --myoption=5
# resolves to:
$ path/to/node ./server.js --debug --myoption=5

这个双重配置 package.json 非常适合服务器 a) 与客户端共享大量代码库，并且 b) 旨在由最终用户运行的情况。在其他情况下，将它们全部分成两个 repos/packages 是有意义的，每个 repos/packages 都有自己的 package.json。

notpushkin 于 2016-07-08

它不是针对 Electron，而是针对您构建的项目。 Electron 很可能拥有从语义版本控制衍生而来的自己的系统来满足他们的需求，而且他们不太可能改变它，但是对于 Lepton 和其他尚未在_ development hell中到目前为止的项目_，完全跳过语义版本控制可能是个好主意。

如果我想使用 debug 参数运行服务器，我不会简单地使用 --debug 参数启动 .lept 吗？
是的，为什么不：
# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug --myoption=5
# resolves to:
$ path/to/node ./server.js --debug --myoption=5

不，我不是指在配置中，而是通过启动器。所以这：

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug

但是使用--myoption=5参数启动.lept而不接触文件（除了打开它们）。由于我很确定您可以通过启动器“_push_”参数，因此您也可以删除对--debug的需求，因为如果您愿意，您将使用自定义参数启动它。

sapioit 于 2016-07-08

但有一件事我认为我们可以同意：用户确实希望使用他们正在获得支持的稳定版本。这就是为什么我将“ Release ”设为自己的号码，因为人们不太可能记住很多号码，但他们通常会记住第一个。

sapioit 于 2016-07-08

@sapioit如果"Release"字段用于最终用户，那么其他字段用于什么？对于最终用户来说，这根本不重要，如果新版本可用并且需要更新运行时（通过 package.json 中的碰撞），那么运行时也应该更新。

YurySolovyov 于 2016-07-08

以下是问题：

用户想知道他们正在为哪个版本提供支持。
他们不想记住很多_无用的数字_，所以如果他们选择记住版本，他们更有可能记住版本13而不是版本1.7 （例如）。
有些人在某些事情发生之前不想更新，比如有很多nVidia 驱动程序没有更新，因为自从添加了 Thunderbolt 兼容性后，他们的显卡会随机弹出（取决于用户/案例，无论是在启动计算机后、打开游戏后还是玩游戏几分钟后）。这是一个很好的例子（但还有许多其他原因，例如KMPlayer 的广告或locked on自动更新），这些原因使用户无法使用最新版本的产品。通过消除其中的复杂性，这使得查看变更日志变得更容易。

这些只是其中的一些原因……如果您可以详细说明，我还可以详细说明并更好地向您解释做出这些选择的原因。

sapioit 于 2016-07-08

@sapioit像>= 12.1这样的 semver 范围还不够灵活，无法声明支持吗？
如果有新版本的运行时可用，并且它满足版本范围，则应用程序的所有下一次启动都应使用最新的可能运行时。

YurySolovyov 于 2016-07-08

他们应该吗？但是如果他们决定不这样做，由于技术限制（比如 KMPlayer 的广告和 nVidia 驱动程序的问题）？

sapioit 于 2016-07-08

@sapioit然后确保您正确说明了您的运行时间范围

YurySolovyov 于 2016-07-08

@sapioit @YurySolovyov这个讨论在这里相关吗？运行时管理器必须遵循电子使用的任何版本控制系统。我相信关于电子应该使用什么版本控制系统的讨论属于另一个问题。

JoshTheDerf 于 2016-07-08

@Tribex有点。我想说的是，我们不应该把已经基本解决的事情过度复杂化。但我同意运行时管理器在这方面应该做最简单的事情。

YurySolovyov 于 2016-07-08

@yurysolovyov那么，为什么不简单地在版本号中允许玩家想要的尽可能多的部分呢？

sapioit 于 2016-07-08

@sapioit

它不是针对 Electron，而是针对您构建的项目。

Lepton（还）没有分配版本控制方案，并且包（应用程序）可以使用他们想要的任何版本控制方案。我们需要处理这个问题（例如，如果我们想支持通过 Lepton 本身更新应用程序）。

理想情况下，运行时应该使用 semver，因为它们不是产品，但同样，现在支持任何 3 位数的版本控制（尽管开发人员需要小心指定范围）。如果我们需要支持超过 3 个数字（例如您的 Explicit Versioning 提案），我们需要扩展解析器（对于 Python，我建议分叉k-bx/python-semver或podhmo/python-semver — 前者最近更新了，而前者更紧密地遵循 node-semver API 并且是我目前使用的）。

notpushkin 于 2016-07-08

我只能说为 nodejs 项目使用 python 编写的运行时包管理器只是一个坏主意。
只是让我们不要这样做。不管它叫什么，轻子什么的。让我们将它写在节点中，或者使用其他东西。并且让我们不要用不必要的邮件向这个问题发送垃圾邮件，说明您认为自己比经过深思熟虑的语义版本控制方案更了解

championswimmer 于 2016-07-08

👍6

@championswimmer使用与它打包的电子版本构建运行时管理器以及显示何时下载其他版本的 UI 会很有趣。

JoshTheDerf 于 2016-07-08

👍2

@championswimmer iamale/lepton是一种一次性的参考实现：我只是把它放在测试这个线程周围的各种想法，仅此而已。

notpushkin 于 2016-07-08

👍1

@iamale也许您应该在自述文件中说明以避免混淆？

YurySolovyov 于 2016-07-08

@YurySolovyov完成！

至于真正的实现，我们有两个选择：要么使用 node.js，要么使用 C/++ 或 Go 之类的编译语言；对于 node，我们必须将 node.js 与它捆绑在一起（或者可能只是在下载的电子实例之一上运行它？不过，我们需要确保它在_any_ sane electron 版本上运行）。

notpushkin 于 2016-07-09

@iamale不是真的，我们只需要运行一个默认安装的版本。之后，更新可以将其就地切换到较新的版本。

JoshTheDerf 于 2016-07-09

我宁愿选择使用某个版本，因为如果需要，一切都可以更新......

sapioit 于 2016-07-09

Lepton现在可能不是一个好名字，因为它是一种图像格式。

enlight 于 2016-07-15

那么……我们现在怎么称呼它？ Hadron ?

sapioit 于 2016-07-15

夸克？如果有人想取名为“Muon”，我可以重命名我的一个项目。

JoshTheDerf 于 2016-07-15

命名实际上不是这里最不重要的部分吗？
我们是否就安装/更新/运行时语义达成一致？

YurySolovyov 于 2016-07-15

👍6

为什么不只是electron ...

7 月 15 日。 2016 年 1 月 13 日 22 分，Joshua Bemenderfer通知@github.com het volgende geschreven：
夸克？如果有人想取名为“Muon”，我可以重命名我的一个项目。
—
您收到此消息是因为您订阅了此线程。
直接回复此电子邮件，在 GitHub 上查看它，或将线程静音。

jobukkit 于 2016-07-15

@yurisolovyov我认为我们同意...或多或少。
@job-v 这就是我一直在建议的。让我们选择一个并坚持下去。

sapioit 于 2016-07-15

@zcbenz你在观察这个线程吗？
如果是这样，最好对这应该如何工作有一些远见，以便在这里获得一些指导。

YurySolovyov 于 2016-07-15

👍2

你好
关于这个电子运行时的任何更新？
@zcbenz你对所有关于以下的讨论有什么看法：

选择电子版
安装合适的版本
准备好在 win、linux、mac 上工作
用什么工具来构建它（python、node、go、c++）？
@YurySolovyov @sapioit谢谢你的好主意
@iamale是基于 debian 的 destros 'ubuntu ...' 的解决方案

ghost 于 2016-12-27

@alnour-altegani
是的，它适用于任何基于 dpkg 的发行版，因为我们不依赖外部包。 RPM包可以用类似的方式生成，为什么不呢？

我正在考虑为所有 Electron 东西启动一个中央仓库，所以你可以运行：

sudo sh -c "echo 'deb https://epkg.example.org/ /' > /etc/apt/sources.list.d/epkg.list"
sudo apt-get update
sudo apt-get install min-browser  # or whatever

notpushkin 于 2016-12-27

@iamale我认为将电子作为 deb 包并将其用作应用程序中的依赖项，以便手动安装或从中心存储库安装许多电子版本的 deb 包。
然后在安装后使用这个包来运行用户应用程序

ghost 于 2016-12-27

如果有人开始为此做一些事情，也许在这里链接到它......

sapioit 于 2016-12-27

@sapioit我已经开始研究 Linux (APT/RPM) 解决方案。您将 .asar 上传到的简单服务，它会被转换为包并添加到存储库中。也应该可以扩展到 Windows 和 macOS，但目前还没有任何承诺。

notpushkin 于 2017-02-01

👍3

@iamale酷！当你让它在 Windows 上运行时让我知道。

sapioit 于 2017-02-01

为 Linux 制作 Flatpak 运行时怎么样？这样，运行时可以在多个应用程序之间共享，并且您也可以获得沙盒。

随着 Flatpak 消除了它对systemd的依赖，它可能会在 Linux 上普遍用于上游打包。

moosingin3space 于 2017-02-06

👍5

运行时可以在多个应用程序之间共享

我认为使用 Flatpak 是不可能的？

notpushkin 于 2017-02-06

@iamale Flatpak 旨在共享运行时 - 应用程序开发人员选择一个运行时，为该运行时安装 SDK，然后使用flatpak-builder或类似的方式构建一个应用程序。然后，当用户安装应用程序时，Flatpak 会安装关联的运行时。

moosingin3space 于 2017-02-06

👍2

@moosingin3space感谢您的解释！那时绝对值得考虑。

notpushkin 于 2017-02-06

我喜欢 Flatpak 的另一件事是，它是围绕用户添加由运行时开发人员和应用程序开发人员（透明地）运行的存储库的用例设计的，这使得更新自动进行。

我能看到的唯一问题与安全性有关 - 需要修改系统库以使用 Flatpak 中的“门户”界面以允许安全退出沙箱。

moosingin3space 于 2017-02-06

👍1

这里似乎有关于 Flatpak 的工作： https ://github.com/endlessm/electron-installer-flatpak

moosingin3space 于 2017-02-06

👍1

附带说明一下，Flatpak 基于OSTree项目，该项目为文件系统树进行内容寻址。这意味着具有相同校验和的文件会自动在磁盘上进行重复数据删除，并且使用静态增量执行更新。这意味着不仅 Electron 可以提供可以独立更新和跨应用程序共享的共享运行时，而且构建在相同文件上的应用程序将自动在磁盘上共享它们，并且一旦安装了应用程序和/或运行时，更新不需要完整下载。

ebassi 于 2017-02-06

👍1

如果这有点幼稚，请原谅我，我想知道是否考虑过构建桌面环境作为运行时环境的自然逻辑进展的可能性。这个想法是有一个启动应用程序，它在启动时加载电子（而不是说，原子），它能够通过生成渲染器的新实例或者甚至重用它来启动其他电子应用程序（给定不断增长的库）并拥有应用程序在新标签页中打开。

我理解的操作系统中的 Chrome 似乎正是这样（但仅限于 webapps）。通过 nodejs（与 chromeAPI 的限制相反）使用电子作为 Linux 之上的运行时环境（或者甚至替换或至少在 Windows 中的开头 explorer.exe 中增加）拥有具有完全 fs 访问权限的桌面应用程序将是非常令人兴奋的恕我直言。我认为这是一个比 ChromeOS 更干净的解决方案，ChromeOS 加载有效的运行时，然后是浏览器引擎，然后托管应用程序 - 这里将直接在运行时加载应用程序，而浏览器本身将只是另一个应用程序（并且有许多创新的电子浏览器项目在野外）。

同样，我想知道是否已经考虑过这一点，或者是否有一些项目已经这样做了。不然的话，说不定哪位小仙女能在 Github 管理层耳中说一句带头？？？？

PS：我在这里不建议的一件事是将 OS.js（这本身就是一个可爱的小项目）移植到电子，但为电子应用程序创建一个环境（尽管我不反对从 OS.js 重用代码）。
PPS：如果它被认为足够有价值，或者它会分散运行时环境问题的注意力，我将创建一个单独的问题。

CxRes 于 2017-02-08

我确实认为内置的运行时环境会使 Electron 应用程序变得更好。我认为打包它们应该只是压缩文件并将扩展名重命名为asar ，但是该存档应该有两个文件夹，一个名为asar ，其中包含默认运行时文件夹的内容，另一个使用应该覆盖默认配置的文件调用enviroment 。

例如，运行一个新应用程序会将所需版本的 Electron 复制到临时文件夹中，并将运行时（ asar文件夹的内容）移动到默认文件位置，而可选的enviroment文件夹（有 3 个子文件夹， windows ， linux ， macosx ）应该包含将粘贴在默认文件夹上的文件，覆盖它的内容。

这样，我们只需要一个应用程序或其他东西来评估应用程序的.asar扩展名，并让该应用程序访问包含下载的 Electron 版本（存档）的文件夹，将它们复制（提取）到临时文件夹中, 并使用.asar的内容来修改需要的内容，然后从该临时文件夹运行 Electron 实例并等待它终止以强制删除临时文件夹。对于初学者来说，即使只在所有受支持的操作系统上使用具有自定义扩展名的存档来使用默认配置，也将比我们已经拥有的更多。之后，我们可以担心有第三个文件夹config ，在哪里保存当前配置设置，可能还有一个_config文件夹，用于默认配置设置（如果我们需要它们）。

sapioit 于 2017-02-09

随着 Chrome 打包应用程序即将被淘汰，人们将寻找替代品。对于那些并不总是有可用的构建/发布的小项目来说，运行时会很棒。由于应用程序与 Chrome 应用程序一样是使用网络技术制作的，因此用户只需从源代码运行应用程序就很有价值。如果用户可以运行它们的唯一方法是为每个单独的脚本或应用程序下载一个大型二进制版本，并且用户不能在不构建或下载 Electron 的情况下运行最新提交，我无法证明将无数次要项目移植到 Electron 是合理的IDE 自己。

bryc 于 2017-03-18

👍6

大家好，即使我不在以 JS 为中心的世界，我最近也有一个与 _Electron_ 非常相似的想法（我碰巧知道，但不用于开发），但受众更广泛；用一种非常简单的方式说：_只是将 Web 技术限制在 GUI 上并提供 API。_

因此，继续使用语义版本化的共享库/运行时（建立在 _Blink_、_Skia_ 等之上；也许在 – “现代” – _C++_ 中）并让开发人员通过使用绑定来选择语言……
例如你想要_JS_，使用_Node.JS_；你想要_C++_，没问题；你想要 _Python_，用标准的 _CPython_ 应该是可能的；还要别的吗？也许 _SWIG_ 可以提供帮助。在（几乎）任何情况下，我们都赢了。

一旦我们有了共享的（依赖于操作系统的）库/运行时，您就可以解决主要问题，并可以详细说明您认为最好的方式来交付其余部分（除了为我们其他人彻底改变/现代化 GUI 编程方法；a向前迈出了一大步！）。

所以起点应该是_Electron_项目的“分裂”（甚至应该有一个与物理相关的名称，因为你似乎真的很关心它）...... :)

dezzeus 于 2017-04-07

👍2

我们甚至无法完成 Electron 的插件，但我认为这不会有那么大的成功，除非有大量的广告。

sapioit 于 2017-04-08

@dezzeus在这条线上进行了一些努力，但最终失败了。查看旨在托管破坏浏览器的推力运行时。

CxRes 于 2017-04-09

👍2

我读了两遍这个又长又引人入胜的帖子，因为我很想看到这个方向的更多动力。这是@zcbenz的最后一句话，我相信仍然相关：

实现这一点没有技术障碍，整个事情可以只是一个 Electron 应用程序本身。但问题是实现起来也不容易，考虑到所有细节，我认为_它需要一个小团队全职工作_，我不确定它是否会发生。

（特别强调）——我对此的解释是，如果要构建解决方案，它将取决于社区努力和/或 GitHub 和其他与其有利益关系的组织的业务需求。

@yan-foto 的简明概述看起来像是一个明智的方法计划，具有明确的目标/要求。 @iamale有一个名为 lepton 的参考实现/原型，提出了一个针对 Electron 的“通用运行时版本管理器”。 @jorangreef的评论很有趣，因为他描述了“具有 semver 自动更新机制的生产应用程序”，具有差异更新、重复数据删除（不确定这两者是否相同）和压缩。他描述的许多功能似乎非常适合适应/采用。

这些是探索和进步的明确步骤，它让我希望在这个过程中产生具有生产价值的通用解决方案。

eliot-akira 于 2017-05-03

很高兴看到仍有人对人类充满信心。

唯一阻止它成为产品的原因是缺乏制造该产品（概念）所带来的直接商业机会。

sapioit 于 2017-05-04

@eliot-akira 是的，就是这样。我编写的代码在文件中执行基于每个文件内容的重复数据删除（可变大小的块），以在文件中只有几个字节更改时最小化下载。它还只更新那些在版本之间发生变化的文件，并且对整个应用程序的更新在面对任何错误时都是原子的。新版本将启动或旧版本将保持不变。

我想开源代码，我仍然需要为整体想法编写一些代码。如果多个 Electron 应用程序可以共享一个自动更新管理器进程（具有本地共享的不可变缓存，用于跨多个独立的 Electron 应用程序的重复数据删除），那就太好了。

整个方法的目标是最小化安装和更新 Electron 应用程序所需的总体下载带宽，同时保持 Electron 应用程序彼此完全隔离（多个应用程序将拥有自己的 Electron 二进制文件）。一个非目标是最小化磁盘占用空间。

第一个 Electron 应用程序安装需要完整下载，但后续的 Electron 应用程序安装将受益于本地共享的不可变缓存。

jorangreef 于 2017-05-04

👍1

由于涉及到自动更新，我不得不引入版本控制问题，以及多个版本控制系统似乎使用不同位数进行版本控制的事实。一方面，我正在使用Explicit Versioning 。

sapioit 于 2017-05-04

我们有两种类型的东西需要在这里更新：

Electron 本身，它使用Electron 版本控制和
应用程序，我们并不真正需要关心 SemVer 或任何东西，因为它们通常没有 API（除非它们可能使用某种插件系统）。

虽然如果我们确实需要支持多个版本控制系统，也许我们可以在package.json中进行一些设置，例如用于 semver 的 $# "breakingVersionComponents": 1和用于显式版本控制或电子版本控制的2 ？

（另一种选择是在版本中添加另一个分隔符，例如1.3:3.7它将分隔中断和非中断部分。Semver 然后变为x:y.z和电子版本控制x.y:z 。这将不过，我相信，打破每一个工具。）

notpushkin 于 2017-05-04

@jorangreef如果每个应用程序仍然有自己的 Electron 二进制文件，这将无法解决打开多个 Electron 应用程序时内存使用过多的问题。

jobukkit 于 2017-05-04

👍3

我注意到@joshuawarner32的一条较旧的评论，我忽略了它。他提到了一个已经工作的例子，还不是通用解决方案，但总结是：

- Deploy .asar.gz files for several different apps on a server
- Distribute a single build of atom-shell to users, which doesn't bundle any code for specific apps
- On app startup, download the appropriate .asar.gz file (if it's not there, or there's a more recent one on the server). Extract it and run the contained app.
- Our atom-shell build accepts a --app argument to specify which app to download/run

除了@jorangreef的示例（感谢您的进一步解释 - 编辑：哦，我没有意识到每个应用程序都有自己的 Electron 二进制文件，这与我想象的模型不同），我看到人们已经在构建他们的自己针对共享运行时问题的特定解决方案 - 它还提供某种应用程序启动器/管理器的功能。很高兴看到一些融合，将提到的一些功能分解为通用模块。

我想知道是否存在可以利用的非电子特定模块，例如下载机制：运行时服务器、版本控制、差异更新。如果其他人已经“解决”了其中一些领域，那么从头开始构建它似乎有点令人生畏。 @iamale ，感谢您在Lepton上所做的工作，在我看来，这是朝着解决方案方向的具体实施。

eliot-akira 于 2017-05-04

另一个想法：只需在 npm 中发布应用程序，并制作一个可以安装和运行它们的特殊 npm 包装器。那时它真的很容易部署并且可能也很容易使用（尽管取决于包装器的质量）。你们觉得怎么样？

notpushkin 于 2017-05-04

对于 oss 项目，我们可以使用 npm 作为托管，对于闭源项目，我们需要能够将包管理器指向 .asar 文件以进行下载，也许还有更多元数据。问题是，这种经理会是什么样子（并被称为）

另外，我想知道我们是否真的需要一个单独的命令来安装应用程序，也许只是
electron install atom就够了吗？

YurySolovyov 于 2017-05-04

👍1

刚刚在 Node Weekly 上看到了这个：

Electrino 是流行且强大的 Electron 的实验性轻量级替代品。它实现了 Electron 中可用 API 的一小部分，但输出应用程序的大小要小得多。

https://medium.com/@pauli/put -your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297

https://github.com/pojala/electrino

zeke 于 2017-05-04

❤3

@YurySolovyov闭源项目在 npm 中发布也应该没有问题——已经有一些 Node.js 项目，即enclose 。（从技术上讲，它不在 npm 中，只是一个加载器，但无论如何我看不出侧载 .asar 有什么帮助，因为它们仍然可以被解包。）

notpushkin 于 2017-05-04

我只是想想想我们如何尽可能多地重用现有的生态系统。

YurySolovyov 于 2017-05-04

不确定我们想...

sapioit 于 2017-05-04

@jorangreef如果每个应用程序仍然有自己的 Electron 二进制文件，这将无法解决打开多个 Electron 应用程序时内存使用过多的问题。

@Jop-V 不，不会。我不想把事情混为一谈，最终变成一个怪物。这个想法是有一个伟大的安装程序/自动更新程序来解决打开这个问题的评论中的大部分问题： https ://github.com/electron/electron/issues/673#issue -44580957

问题不在于磁盘上有多个二进制文件，而是网络影响用户必须下载和自动更新同一二进制文件的多个副本。

不过，解决内存使用问题绝对值得。我认为有多种方法可以做到这一点，但它们不一定需要与重复数据删除安装程序/自动更新程序捆绑在一起。

jorangreef 于 2017-05-05

如果磁盘占用也是一个问题，可以通过支持它的系统上的硬链接来解决，尽管这会开始违反应用程序之间隔离的想法（例如，如果一个应用程序决定写入与其他东西共享的硬链接）。

或者，至少在中期的 macOS 上，APFS 将通过引用复制文件，并在后台进行透明的重复数据删除，从而最大限度地减少磁盘占用。这会比硬链接更好，因为它会保持隔离完好（写时复制）。

jorangreef 于 2017-05-05

@jorangreef为应用程序使用单独的电子二进制文件有什么意义？你说的是哪种隔离？对不起，如果这是一个愚蠢的问题，但我就是不明白。

notpushkin 于 2017-05-05

@iamale一些应用程序可能针对不同的官方版本的 Electron，或者可能分发从修改后的源编译的预构建 Electron。这种方法适用于所有人。即使二进制文件存在重大差异（相对于 JS 和资产更改），重复数据删除将消除 70% 或更多的下载需求，因此针对不同二进制文件的应用程序仍然会受益。

使用这种方法，甚至可以发布任何类型的包（由 JSON 清单定义的任何文件和目录集），而不仅限于 Electron 应用程序。它也可能是一个 Python 应用程序。对于开发人员想要对他们如何构建或打包他们的应用程序（文件与 asar 等）做出的任何选择，它都是不可知的。

主要思想是生态系统受益于非常小的安装/更新增量，因为越来越多的应用程序使用相同的安装程序/自动更新程序。如今，每个应用程序都在运行自己的监督自动更新程序，这是不必要的。

jorangreef 于 2017-05-05

@jorangreef谢谢！我想它很像经典的 APT/RPM 存储库，只是更“智能”（无需声明依赖项或其他任何内容）。

notpushkin 于 2017-05-05

问题是，这种经理会是什么样子（并被称为）

Minifitron （缩小的电子）呢？

我认为归档文件（即.asar ）应包含电子二进制文件所在文件夹的内容，因此我们可以添加或替换偏离标准的文件。我们将每个版本都放在一个文件夹或存档中，并在运行时将其复制到一个新的临时文件夹中。

并且应该有一个选项来安装或缩小应用程序，安装会将它们保留为电子的新实例，而缩小的将使用 md5 删除未因.asar的取消归档而更改的文件

sapioit 于 2017-05-05

只是提出另一个想法：如果每个 Electron 应用程序确实包含他们自己的运行时副本，但在启动时，他们可以检查是否有一个已经运行的 Electron 实例（及其版本） - 如果它兼容（在 semver 范围内等），应用程序可以与其通信并使用相同的实例；如果不兼容，则应用程序可以启动自己的 Electron 实例。这似乎解决了减少内存占用的问题。

（再一次，当应用程序启动时，我猜无论如何已经有多个运行时实例了..所以可能不合逻辑..）

eliot-akira 于 2017-05-05

❤2 👍1

@eliot-akira 在阅读这个帖子时有一个非常相似的想法。

（再一次，当应用程序启动时，我猜无论如何已经有多个运行时实例了..所以可能不合逻辑..）

好吧，它可以加载刚好足以检查这一点，并且在它发现没有可用的“电子伴侣”来共享运行时之后，加载其余部分。

但是，这会产生很多安全问题。一个邪恶的应用程序可以向其他人提供运行时的修改版本，并访问他们的数据。可能它可以使用共享内存段，使其只读，并且“用户”应用程序（使用先前启动的应用程序的运行时）可以校验运行时，但是为所有目标操作系统开发这些可能是一场噩梦（我什至不知道这是否存在于 Windows 中；我认为它必须）。

如果只是出于好奇，这是荒谬的吗？它会与单独的共享运行时一样多，还是可能比单独的共享运行时多得多？它是否会产生其他额外的问题？

稍后添加：这可能是一个遥远的镜头，但存在对 RAM 上相同页面进行重复数据删除的技术；它们主要用于虚拟化环境和管理程序。这是我想到并跑去检查今天的操作系统是否使用它的第一件事，然后可能会有一种方法来设置电子，以便可以利用此功能，但显然不是。

jkurei 于 2017-05-08

👍1

@jorangreef如果开发人员修改了电子二进制文件，他们不应该只创建一个拉取请求吗？

jobukkit 于 2017-05-08

@Jop-V 他们可以，但他们也可以维护自己的分叉。如果他们不想要，他们甚至可能不会发布资源——MIT 许可证对他们没有任何义务。

notpushkin 于 2017-05-08

@jkurei为了进一步探索这个想法，我想出了几种可行的方法：

1) 围绕 Electron 或应用程序本身的薄原生包装器，即“启动器”。它检查已经运行的 Electron 实例及其版本：如果兼容，则将启动过程的其余部分移交给该实例并退出；如果没有，继续启动它自己的 Electron 实例。

2) 应用程序本身可以作为启动器导入主进程的 JavaScript 库。它可以实现类似于上面的协议：广播 Electron 实例的存在，以及其他应用程序（使用相同的库）找到并与之通信的方式 - 也许通过网络端口..？

eliot-akira 于 2017-05-08

@eliot-akira 顺便说一句，我认为您正在谈论某种原始的“协议”；这是app.makeSingleInstance背后的东西，它以某种方式检测已经运行的 Electron 进程以及它们是否是同一个应用程序（可能是通过获取完整的可执行路径）。

notpushkin 于 2017-05-08

@iamale我明白了，该方法使用 Chromium 的原生ProcessSingleton类来注册当前的应用程序目录（作为唯一标识符？）。是的，我正在想象这样的事情，要在app.on('ready')之前初始化。因此，它不仅可以检查该特定应用程序的现有实例，还可以检查任何 Electron 实例——然后“移交启动过程”（如果兼容）。

从另一个角度，我发现了一个名为node-ipc的模块，它可以在不同的 Node.js 进程之间进行通信。也许这可以用于纯粹在 JS 层上管理启动过程。

eliot-akira 于 2017-05-09

这是一个在多个应用程序之间共享单个 Electron 实例的基本示例，使用node-ipc进行进程间通信： https://github.com/eliot-akira/singletron-example。

IPC 集线器是它自己的模块，是一个围绕node-ipc的薄包装器。它的初始化在主进程中， main.js在底部。

启动时，应用程序将首先尝试连接现有的 Electron 实例。如果没有，它将启动一个“服务器”来侦听进程间请求。该应用程序的任何后续实例都将与第一个实例连接，接收其“配置”（Chrome、Node、Electron 的版本），并能够交换消息，例如，为其自身请求一个新窗口。

这是一个幼稚的实现，但我喜欢这种方法的是，由应用程序来处理服务器/客户端应该如何协商：检查兼容性、是否打开新窗口、传递其他配置等。

eliot-akira 于 2017-05-09

👍2 🎉1

@eliot-akira 我认为在这一点上指定默认服务器 ID 是一个 _really-really-bad_ 想法：如果有人出于自己的目的开始使用它，他们可能会根据自己的需要修改您的示例代码并破坏协议（从而破坏了其他依赖于此的应用程序）。

除此之外，看起来又好又干净，谢谢！

回复：安全问题：Electron 应用程序已经以用户权限运行，如果我们将它们放在一个进程树中，它们确实可以（或能够获得）访问其他 Electron 实例。然而，我认为如果我们要减轻这种情况，每个人都能够提供一个打过补丁的 Electron 实例肯定无济于事。

notpushkin 于 2017-05-09

@iamale感谢您的反馈。我公开了设置服务器 ID 的选项，以防某些应用程序想要实现自己的协议，而不是所有 Electron 应用程序的通用协议。事实上，目前还没有这样的通用协议——因此，在这一点上，对于未知的应用程序连接并移交启动过程来说，这并不实用。它本来是一个概念验证，所以我将更新文档以提及这一点。我会继续探索如何让它更实用。

eliot-akira 于 2017-05-09

我认为对于新来的人来说，再次进行一些总结会有所帮助，类似于半年前有人做过的总结。

另外，最终用户做什么？

如果我是最终用户（部分我是 ofc），我想要一个类似于portableapps.net 安装程序的单个.exe/.app/.deb 包。该 exe 文件应该很小，如果没有安装，它会自动与运行时一起下载该软件的最新上游版本。在一个简单的设置过程中，我应该能够手动设置“运行时位置”（使用高级选项复选框）以及用于创建系统链接（桌面、开始菜单等）的复选框。

当我下载下一个软件时，如果可能的话，之前的运行时（不管它看起来像什么，idc）应该被重用。

作为一名开发人员，我希望能够（最多）一键创建这样一个可下载的包。这一次单击应该将我的代码上传到某个存储库（类似于 play/web/app 商店）并为我创建一个可以与世界共享的 .exe/.app/.deb 包。

我还没有参与 Electron，因为我只是使用 Electron 和 Electron-Edge 为 C# 创建了一个小型 mod 安装程序。

我可能很天真，但是 afaik，唯一的“真正”原因，为什么事情不兼容 +-0.1 版本是必须为每个版本的 Electron 重建 .node 文件。这些 .node 文件不能在设置期间使用某种云解决方案构建吗？

另外，每半年左右创建一个大型 Electron LTS 真的有那么大吗？我怀疑开发人员实际上是否在使用每个新 Electron 版本的所有前沿特性，所以如果我们（有点）强迫他们更长时间地坚持一个版本，那真的会让事情变得容易得多。

Imo，唯一的问题是没有准备好让每个人都依赖的 LTS 版本的 Electron。

使用该 lts 版本，构建自动更新、重复数据删除、版本管理和所有其他内容应该是小菜一碟。

我提出的安装程序解决方案还有一个额外的好处，即用户并没有真正看到软件的文件夹，因此我们不必将其打包为 .whatever 并告诉他将其移动到安全的地方。此外，可以在安装过程中添加多个“子可执行文件”（例如，用于多人游戏、多个“配置文件”等）。这些可执行文件应该只称为 somelaunchername.electron，但采用 Json 格式，包含有关如何启动软件的信息（例如要加载的 index.html 和类似的东西）。 node_modules 应该在可执行文件之间共享（除非开发人员需要为每个可执行文件使用不同版本的模块）。这可以通过拥有三个 node_modules 文件夹来实现。每个可执行文件一个，两个都一个。在 package.json 中只有一般信息。每个 .electron 文件应该（imo）能够覆盖 package.json 中的值。

然后可以使用“runtime --appname”或像 steam 这样的自定义协议将这些 .electron 文件添加到开始菜单和其他位置。不知道哪一个更好，但蒸汽那个在过去让我生气了好几次。

现在，如果开发人员真的想发布修改后的运行时，他仍然可以按照目前的方式对其进行打包。

总结：
在我看来，下一步是创建一个稳定的 lts 版本，并通过为开发人员提供简单的打包解决方案来吸引他们。安装过程可以稍后改进，目前下载这些 .electron 文件的运行时和启动器就足够了。

你们有什么感想？

CiriousJoker 于 2017-07-24

👍3

@CiriousJoker electron-builder 可以创建便携式应用程序和网络安装程序。据我所知，在 windows 上共享 DLL是一种解决方案。共享 DLL 还支持引用计数，以自动删除未使用的电子运行时。目前，windows 上的电子运行时是一个大的 exe（node.dll 除外）。如果可以拆分成dll，那么electron-builder方面的解决方案就很容易实现。它还将节省内存，而不仅仅是磁盘空间。

@zcbenz @paulcbetts你考虑过使用共享 dll 吗？是否可以减小 exe 的大小并将所有电子代码移动到 dll 中（因此，在 exe 中只保留最少的代码）？很酷，因为电子 1.7.5 共享 C 运行时已从 node.dll 和 exe 中删除。现在，30 MB 的代码已经在 DLL 文件中（但 exe 仍然很大——80 MB），所以，我可以开始试验它了。

develar 于 2017-07-25

@develar imo，真正的问题不是我们如何共享 dll，而是我们如何获得电子的 lts 版本

CiriousJoker 于 2017-07-25

Chromium 甚至会为旧版本做安全修复吗？我有一种强烈的感觉，他们的政策是“升级到最新版本以确保安全”。如果没有来自 Chromium 的安全更新，Electron 的 LTS 似乎还有很长的路要走。

sedwards2009 于 2017-07-25

👍2

@sedwards2009但是真的有那么多威胁吗？当然，我在这里可能很天真，但我们并没有保护用户免受开放互联网的影响，而是（主要是）本地应用程序。当我的合法电子应用程序的安装程序被 AVG 称为病毒时，运行任何 .exe 文件的危险性增加 10000 倍，编写 .exe 病毒也容易 10000 倍。

所以对我来说，每 6 个月左右“更新”一次安全性就足够了。此外，让每个开发人员使用他们自己的 chromium 打包版本更加不安全，无论如何我们无法阻止（使用共享运行时或其他方式），他们可能会做更多的坏事

CiriousJoker 于 2017-07-25

是的，安全性在应用程序获得对 fs 和网络的原始访问时结束。
您要么信任应用程序的供应商，要么远离。 <- 这适用于闭源应用程序。
对于 OSS 来说，更好，它们中的大多数至少没有恶意，但可能包含错误。

YurySolovyov 于 2017-07-25

好的，那么获得 lts 版本有多容易？我们不能只选择当前版本并将其声明为 lts 版本吗？

当我们试图说服开发人员为这个特定版本构建他们的应用程序时，更大的问题可能会在以后出现，但无论如何这是最后一步。为了构建一个共享运行时，我们只需要先选择一个运行时

CiriousJoker 于 2017-07-25

我想说这应该是开发人员的决定 - 找出应用程序应该在哪些运行时版本上运行。
有点像npm引擎字段。
Runtime 在这里的工作是获取所需的 dll 或其他任何内容并允许应用程序运行。

YurySolovyov 于 2017-07-25

但是，如果我们允许他们从几十个几乎相同但不兼容的运行时中选择一个，我们就会完全错过重点，不是吗？我们试图避免拥有多个运行时，而不仅仅是对它们进行重复数据删除。正如有人在一开始的某个地方提到的那样，当在同一个系统上再次使用同一个运行时的可能性是 20 分之一时，重复数据删除运行时没有多大意义。

或者你的意思是我们共享了大部分运行时，只是根据需要切换不同的部分？这是有道理的，但我想这很难实施

CiriousJoker 于 2017-07-25

我看不出如何共享运行时，主要大小消费者是 Chromium 和 Node，它们紧密集成，我怀疑它们可以与多个版本一起工作。

我认为节点有类似的东西：

一些开发人员想要最新的 v8，并且可以容忍破损
大公司需要稳定和长期的支持。

我不确定电子团队是否有足够的资源来支持两者，但我可能错了。
无论如何，这与版本范围不冲突，只需要指出哪些版本是“LTS”

YurySolovyov 于 2017-07-25

好吧，如果每个电子应用程序都使用相同的运行时，并且只附带专门为该运行时构建的 .asar 包，那么事情就会成功，不是吗？

CiriousJoker 于 2017-07-25

是的，但你偶尔会想要更新的 Chrome 和 Node，对吧？

YurySolovyov 于 2017-07-25

是的，但我可以忍受使用相同的节点/chrome 6 个月 np。无论如何，Node 都有一个 LTS 版本，并且 chrome 与我所注意到的相比并没有太大变化。 Imo，每次安装应用程序节省 100mb 的好处弥补了新版本的 Chromium / Electron 发布后不时提升的速度。此外，一旦我们让开发人员参与进来，减少新版本运行时之间的时间应该不会太难。然后我们可以支持最新版本的运行时和一个或两个旧版本。

我猜每 6 个月重建 .node 文件也不应该太难

CiriousJoker 于 2017-07-25

Electron-builder 将支持所有 nsis 目标的新选项 - useSharedElectronRuntime。目前，所有现有的 dll 都将是，我认为可以减少 exe 的大小并将代码移动到 dll，但可以稍后完成，节省 30Mb 已经是一个很好的目标。

为所有电子 dll 创建签名程序集并发布到 GitHub 版本（bintray 不是一个选项，因为不可靠）。
如果尚未安装，Nsis 安装程序将下载并安装程序集。安全性——程序集已签名。 Electron-builder 还支持每台机器的安装。如果在每台机器上安装程序集，Windows 会提供额外的安全级别，因此，如果需要，您可以启用它。在任何情况下，将添加附加选项以在每台机器上安装组件。尚不清楚 - 默认情况下应该是 true 还是 false。我认为是错误的，以确保默认情况下可以在没有管理员的情况下安装电子应用程序。
无需担心未使用的电子运行时——共享 dll 支持引用计数。在应用程序卸载时，程序集将被删除，如果没有其他应用程序使用它，Windows 将删除它。

develar 于 2017-07-25

👍7

@CiriousJoker回复：安全。我没有想到应用程序本身是恶意的安全问题。我正在考虑吸收和使用不受信任的内容的电子应用程序。即任何时候电子应用程序以webview或类似的形式显示来自开放网络的网页。

许多应用程序不会将自己暴露在开放的网络中，它们可以在较旧的电子设备上运行。但另一个极端是像 Brave 这样的网络浏览器，它除了暴露自己之外什么也不做。 :-)

sedwards2009 于 2017-07-25

@sedwards2009是的，但是如果我们开始关心每个人和他们的妈妈，我们将不会取得任何进展。总有理由不做某事。没有让 100% 的开发人员参与进来只是我们必须做出的牺牲。如果他们真的需要/想要安全性，他们可以手动获得。

CiriousJoker 于 2017-07-25

👍2

至于选择 LTS，恕我直言，最明智的选择是将自己绑定到 Nodejs LTS，即与节点 LTS 对应的电子版本实际上就是电子 LTS。这可以带来一些和谐和一致，以便我们可以集体前进并获得一些保证，而不是将其作为自由选择（这否定了这个社区）或争论（这使我们无处可去）。

CxRes 于 2017-07-25

@CxRes但是我们支持什么版本的 Electron？在我的项目中，主要问题是针对特定版本的 Electron（不是 Node）重建 .node 文件。

我们可以将最新的 Electron 版本设置为 lts，或者使用最广泛使用的版本。

我在这里错过了什么吗？ Imo，问题是电子，而不是节点

CiriousJoker 于 2017-07-25

好的，让我试着用一个例子来解释一下：

Node LTS 目前在 6.11.1
因此，我们希望使用满足条件 <=6.11.1 >=6.0.0 的最高版本的 node 正式构建的最高版本的电子
使用节点 6 构建的最高版本电子是使用节点 6.5.0 构建的电子 1.4.15
所以电子 1.4.15 是我们为电子 LTS 分叉的地方，我们用 6.11.1 重建它（依此类推，直到有新的 Node v6 版本）

当 Node LTS 迁移到 v8（LTS 仅为偶数）时，我们将一起迁移到尚未发布的电子版本，该电子版本将使用 Node v8 构建或保留在当前的 LTS 分叉上，直到发布这样的电子版本。

CxRes 于 2017-07-25

想要最新最好的开发人员呢？

YurySolovyov 于 2017-07-25

@CxRes @CiriousJoker让我们在这里避免离题。没有任何技术原因阻止使用不同的 Electron 版本。无论如何都会出现碎片化（开发人员一年前发布了应用程序并忘记了，另一个开发人员的其他应用程序最近发布并使用了另一个版本）。

develar 于 2017-07-25

@YurySolovyov LTS 的整个想法是它不是最新的和最伟大的——它是稳定的。如果我们不能同意专注于一个解决方案——我们注定要遭受没有任何运行时的帕累托次优性，因为没有一个团队有时间和能力重建每个版本并筛选它们的错误。

另请参阅上面的@CiriousJoker评论：

是的，但是如果我们开始关心每个人和他们的妈妈，我们就不会取得任何进展。

CxRes 于 2017-07-25

@develar好的。但是正如您所指出的，这不是技术问题，而是政治问题（就始终适用于大多数人的构建达成一致，从而分担负担）。

CxRes 于 2017-07-25

那么，我们现在该怎么办？我们是选择一个 lts 版本并开始使用，还是尝试通过尝试使用模块化 dll 构建一个万能的运行时来找到一个解决方案以使其适用于所有人（如果我理解正确的话，正如@develar所建议的那样）

CiriousJoker 于 2017-07-25

@CiriousJoker特定电子版本的并排组装。例如ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 。

develar 于 2017-07-26

@develar我在谷歌上找不到那个electronruntineassembly，你能提供一个链接或smth吗？

CiriousJoker 于 2017-07-26

Imo，为了加快速度，我们应该选择一个随机的 Electron 版本作为 lts 版本并开始使用。我们可以在以后的任何时候更改版本。
@develar我仍然不知道您对并排组装的意思，但它必须跨平台工作，我想，我们也可以稍后实现它。

我们（或者实际上是你们）多年来一直在谈论这个问题，但如果没有人开始，一切都不会改变，我们将在这里再坐 3 年讨论想法并寻找不开始的方法。

CiriousJoker 于 2017-07-27

👍10 ❤5

希望electron开发者能尽快解决运行环境与应用分离的问题，对electron应用的推动将大有裨益，我会看到光明的未来。

cat998 于 2017-08-14

他们在我看来似乎好几年都没有解决这个问题，所以我对此有点悲观。当然，这会很棒，但他们是否还在积极努力？

CiriousJoker 于 2017-08-14

👎1

@CiriousJoker如上所述，我正在为电子构建器中的窗口提供共享电子运行时支持。我已提交https://github.com/electron-userland/electron-builder/issues/1942以跟踪进度。我希望它可以在 1 个月内使用。

develar 于 2017-08-14

👍7

@develar我的错，一定是忽略了它。在这种情况下，祝你好运，如果你能成功，那就太棒了！

CiriousJoker 于 2017-08-14

如果有人对https://github.com/electron/electron/issues/673#issuecomment -157980607 线程中前面提到的子文件内容定义分块重复数据删除感兴趣，我已经开源了它： https:// github.com/ronomon/deduplication

jorangreef 于 2017-08-30

🎉1 👍1

这个长线程在过去几个月一直处于休眠状态，但我认为它解决的问题仍然值得研究。在周末，我制作了一个小型的、最小的单页实用程序来批量重命名文件。包含电子生成器，最终的 Mac .app 文件为 121mb ...

pistacchio 于 2017-11-22

最近一直在思考这个问题。然后我看了看我的智能手机：Facebook 应用程序有 600MB 大。 Chrome 有 325MB 大，Messenger 有 300MB 大......所以桌面上的 120MB 应用程序，我真的不在乎......

今天大小不是问题。 RAM和功耗是。

_edit：如果您不同意，请随时分享原因_

martpie 于 2017-11-22

👎35 👍5

对于 Windows 平台， @develar与 electron-builder (electron-userland/electron-builder#1942) 的努力看起来接近实现共享运行时。

还注意到应用程序 webcatalog 将 web 应用程序打包为独立的 Electron 应用程序，解决了使用共享运行时的问题，从而大大减少了应用程序的大小：webcatalog/webcatalog/issues/171。这是在他们的打包程序中通过符号链接应用程序之间的共享资源来完成的。

eliot-akira 于 2017-11-22

渐进式 Web 应用程序 (PWA) 是该问题的部分解决方案。在 Android 上，您可以将 PWA 添加到主屏幕，它就像真正的 apk 一样。 Chrome 团队现在正致力于在桌面上安装 PWA (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/)，Microsoft还表现出对支持 PWA 的兴趣 (https://www.windowscentral.com/faq-progressive-web-apps-windows-10)，我希望 Firefox 和 Safari 能尽快赶上。如果开发人员表现出兴趣，将添加缺少的 API（例如本机文件系统访问）。
大多数基于 Web 的 Electron 应用程序都可以轻松转换为 PWA，但我不确定 Atom、VSCode 之类的应用程序——本机代码可能需要在 WebAssembly 中重写。

joshas 于 2018-01-08

@develar关于这个想法有什么进展吗？

sergeysova 于 2018-05-22

👍1

我会在发布时使用！

jtoy 于 2018-05-26

最近遇到这个，我只是想发表我的看法。虽然我还没有阅读整个问题，所以我可能会在不知不觉中重复一些事情。

我认为这样的事情非常重要，因为虽然 Electron 程序的大小现在看起来可能没什么大不了的，但是当你分发一个非常简单的小程序时，你真的开始看到它——比如，一个自定义计算器。在这种情况下，5-10MB 这样的大小是合理的。不过，60MB 或更多会很荒谬。对于一个更大的程序，Electron 本身的大小变得更加可忽略，但它仍然很烦人。

但是，考虑到当前的发布速度，这种运行时模式需要某种类型的 LTS 发布系统。然后可以鼓励开发人员依赖 LTS 版本，甚至可以在应用程序目录中显示最常用版本的列表，鼓励他们使用最常用的版本，除非它缺少所需的功能。

运行时模式本身应该，IMO，有一个内置系统来安装其他版本的电子库，所以如果用户请求安装需要不同版本的应用程序，运行时程序可以自动下载它作为一个简单的安装过程中的步骤。

我认为还应该注意的是，Electron 应用程序的 RAM 使用量也可以在此帮助下得到改善，尽管使其生效所需的更改要大得多。通过共享运行时，使用相同版本的 Electron 应用程序可以共享内存中的一些资源。

无论如何，无论如何，我对 Electron 项目的整个来源都很陌生，如果有任何不清楚的地方，或者我不必要地重复了一些事情，我很抱歉。然而，我真的希望这能够实现，因为它确实会让 Electron 成为一个更有前途的平台，适用于更多类型的程序。 :+1:

octacian 于 2018-07-11

👍3

@octacian我开始认为 PWA 是更好的选择。虽然不是通用的——你不能用 PWA 做任何事情——但对于自定义计算器之类的东西来说，它们应该绰绰有余。

现在我们只需要等待桌面上的 PWA 支持出现。

notpushkin 于 2018-07-11

👍4

我还认为，有了这样的系统，1- 将更容易运送到嵌入式/更小的系统，2- 未来可以为移动设备创建类似电子的操作系统基础。

yasinaydinnet 于 2018-07-11

👎1 👍1

@yasinaydin已经有 LG WebOS。（曾经也有 Firefox OS，但已停产）

jobukkit 于 2018-07-14

👎1

@KeitIG我的先生，如果 Electron 的唯一问题是它的大小，那么您的论点绝对是不错的。拥有一个稍微大一点的程序，但为开发人员简化复杂性和失败的可能性（我们不能否认 Electron 在为开发人员提供一种构建应用程序的标准化方式而没有太多空间来搞砸方面非常棒）将是很棒的。唉，为每个应用程序使用单独版本的库也意味着 RAM 使用量增加，以及分布式（并且更难修复）安全问题。我已经在我的重复问题中更好地解释了这一点，但简而言之，我真的认为一个共享运行时库你可以自己更新并在不同的 Electron 应用程序之间共享（它也会以“精简”版本发布，有点像当一些开发人员曾经分发 Java 文件以在您的 JVM 上使用并捆绑.exe s) 真的会破坏 Electron 的交易，虽然我知道这可能是大量的工作，但让我感到难过它还没有在开发者的计划中。让我们希望他们在未来这样做。

adalvigi 于 2018-07-15

👍4

@dre-hh 虽然我承认您的提议的善意，但除其他外，它过于严格。例如，我为我的雇主开发了一个商业电子应用程序，它用于高度监管的环境（无互联网连接、可追溯性/审计要求等）。我们的客户不允许我们做诸如自动更新软件之类的事情。这是一个与典型的大众网络应用程序截然不同的世界。在我看来，常青浏览器和操作系统安全更新的自动安装在大多数情况下对大多数人来说是一个好主意，但我的观点是它们并不适合所有地方。有时，由软件更改引起的中断风险远大于与运行过时软件版本相关的风险，尤其是在采用其他安全缓解技术的受控环境中。因此，采取极端措施，例如阻止使用过时版本的电子（或实际上是任何库）执行应用程序，即使是一个解决方案，也不是一个理想的解决方案。（此外，管理员已经有很多控制来限制可以执行的程序，因此他们可以在没有任何新的操作系统功能的情况下实现这一点。）

此外，与大多数安全问题一样，大部分问题源于开发人员要么不了解风险，要么出于任何原因（例如缺乏时间）选择不遵循他们正在使用的工具的安全指南。（例如安全性、本机功能和您的责任）作为开发人员，我们都需要尽自己的一份力量对我们工作的质量（包括安全性）负责。

最后，我认为寻求像微软这样的商业软件实体来解决这些问题是错误的。这部分是因为，正如刚才所指出的，我们不能指望通过没有安全意识的开发人员来生产安全的应用程序。更重要的是，至少在我看来，Electron 的优点之一是它的开源和多平台特性，这通常不是商业软件供应商的优先考虑事项。深思熟虑和成功的进展很可能需要整个开发人员社区的某种程度的共识和努力。当然，来自商业实体的贡献当然是值得赞赏的。

jacobq 于 2018-07-17

👍2

@jacobq如果您不知道，Microsoft 是 Electron 的所有者。

jobukkit 于 2018-07-18

👎11 👍1

如果你不知道，微软是 Electron 的所有者。

@Jop-V 请为此添加引用；我不认为这是正确的。 electronjs.com 的首页说：

Electron 是一个由 GitHub 维护的开源项目，也是一个活跃的贡献者社区。

微软是 Electron 的消费者（在 Visual Studio Code 等产品中使用它）并且（我认为）也是贡献者，但他们没有所有权。许可证文件没有提到微软，维基百科的文章也没有暗示他们拥有所有权。

jacobq 于 2018-07-18

@jacobq微软将收购 GitHub，所以如果 Electron 目前由 GitHub 维护，据我所知，它将很快由微软维护。

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

https://blog.github.com/2018-06-04-github-microsoft/

styfle 于 2018-07-18

👍4 👎3

微软收购 Github 对 Electron 没有任何意义。 Github 是/将仍然是一家独立的公司，拥有自己的产品和项目。我没有看到微软获得了 Electron 的所有权，就像我没有看到微软获得了 Atom 的所有权一样。

我认为这场辩论并没有真正帮助问题的初始点。

martpie 于 2018-07-18

👍10

https://github.com/GoogleChromeLabs/carlo

gaui 于 2018-11-11

👍10

卡罗看起来很有趣。我试了一下，它非常直观。有没有人尝试过pkg呢？

zeke 于 2018-11-11

为什么所有减少最终用户硬盘和内存膨胀的建议都没有实施？这是一个很棒的想法，已经有 4 年历史了，但仍然只是一个想法。我不明白为什么这类事情不在项目优先级的首位

danielo515 于 2019-01-17

👍7

@danielo515因为不是创建另一个勤奋的项目，而是https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

kapouer 于 2019-01-17

你在说什么？这已经是一个巨大的工程了。它也是最广泛和使用最广泛的，因此将人们指向不同的项目以获得应该是该项目一部分的功能对我来说似乎不正确。
此外，Carlo 这是一种不同的方法，他们使用您安装的 Chrome，所以它不像 Electron 的守护程序版本。

danielo515 于 2019-01-18

👍1

我不明白为什么这类事情不在项目优先级的首位

因为让它成为现实很难（就像“真的”很难）。

如果您不满意（这是完全可以理解的），请随时 fork Electron 并提交 PR。

不要误会我的意思，如果这个问题有一个简单的解决方案，我相信它已经实现了。

martpie 于 2019-01-18

👍1

@danielo515

...将人们指向一个不同的项目以获取应该是该功能的一部分的功能对我来说似乎不正确。

我认为关键是每个项目都有其优点和缺点，而 Carlo 非常适合空间受限的情况。对于我的用例，一个 100MB 的应用程序大小是非常好的，所以虽然我很想看到这个功能，但其他电子功能对我来说更重要。

jacobq 于 2019-01-18

@jacobq是的，你是对的——不同的用例需要不同的工具。

如果其他人有兴趣，我创建了一个用于在桌面上开发 js 应用程序的类似工具列表。

https://github.com/styfle/awesome-desktop-js

styfle 于 2019-01-18

👍8

我只是不使用 Electron，因为我负担不起更新数十个 100MB 应用程序的费用——而且您知道应用程序需要如何更新（我对此有其他意见，但分享它们无济于事）。
我真正喜欢 carlo 的方法是使用已安装的浏览器的想法。
更好的是，carlo 可以使用任何可用的浏览器，不仅是 chromium，因为 puppeteer 也可以管理其他浏览器。在 OSX 上，你会生成 Safari，在 linux Epiphany(webkitgtk) 或 firefox 等...
所以真的要获得一个应用程序，你只需要安装 nodejs 和你的应用程序。
现在的问题是：pkg 在使用系统安装的库和本机插件方面有多好？
例如，如果我必须打包我目前正在开发的应用程序，我需要 postgresql、sharp（和 vips）、webkitgtk 和 exiftool。我希望能够仅将应用程序分发给 linux debian、fedora 或 ubuntu 用户。我想摆脱“疯狂的捆绑”，而是免费利用这些发行版所做的辛勤工作。

kapouer 于 2019-01-18

@kapouer ...使用已安装的浏览器...

虽然理论上这是一个好主意，但它确实会增加在 Web 端编写应用程序的难度，因为您现在必须专注于对多个浏览器的支持，并且它们所依赖的浏览器可能会限制您希望做的事情，因为它们不完全支持您在 Chromium 中可以找到的内容。您还依赖用户来确保他们的浏览器是最新的，并且多个浏览器供应商不会因更新而破坏您的应用程序。

许多用户通过切换到增量更新或让程序包管理器仅更新 .asar 文件或资源文件夹来获得 50 Mb 的大规模更新。并且仅在需要时进行大型电子更新。这就是我们在公司所做的，而且效果很好。

baconbrad 于 2019-02-04

从一个天真的用户的角度来看，使用 Electron app-shell 作为共享运行时将使它非常容易分发和使用。例如。在一个系统中有 5 个电子应用程序，你有 5 个 app-shell 实例，大约 300MB，对吧？

我坚信电子是桌面 UX 的未来，这将是一大步（看看 .NET 运行时——可能是一个不好的比较，但是，它很酷，对吧？）使网络技术更强大。

anandhumanoj 于 2019-02-05

👍6

Electron 已经有一个供开发使用的运行时，不是吗？ “电子”。命令，我的意思是。为什么不为用户端重用它呢？

要根据不同版本的 Electron 处理多个应用程序，您可以使用 .NET core 使用的方法。只需并行安装多个版本的运行时，并让应用程序声明它们所需的最小（或最大）版本。

ashelleyPurdue 于 2019-03-03

👍5

我制作了一个概念验证启动器： https ://github.com/ProPuke/electron-shared

单个可执行文件，大小小于 1MB。向它传递一个应用程序目录或 asar 包，它会检查你的 package.json devDependencies 中的电子版本要求，并使用正确的版本下载/运行。

Electron 运行时存储在AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac) 中，因此它们可以在应用程序之间共享。

如果没有指定路径，它将自动运行app目录或app.asar （如果存在）；因此，您可以仅使用此文件和app.asar分发您的应用程序。或者这可能与 .asar 文件相关联，并且可以仅分发 asar。

它还有一些命令行参数，包括--downloadOnly和--silent ，因此可以在安装过程中从安装程序中调用它。

它不处理自动更新（它仅在您的机器上没有兼容版本的 Electron 时才下载），但这可以在启动时定期完成，或者由后台服务完成（只要将运行时放置在当应用程序启动时，它将找到并使用最新的正确位置）。

知道何时删除运行时的旧副本可能很棘手。随着时间的推移，它们可能会堆积起来。我们要么需要跟踪哪些已安装的应用程序使用了哪些版本（因此不再需要哪些版本），或者可能只存储每个运行时版本的最后使用日期，如果它们没有被使用则自动删除它们等一下。

无论如何，概念/建议的证明。这样的事情能解决问题吗？我错过了什么明显的东西吗？

ProPuke 于 2019-03-09

👍31 🎉15 🚀4 ❤3 👀1

我尝试了@ProPuke的电子共享，并且能够运行电子快速启动演示。但是我无法运行electronjs网站中描述的任何应用程序（因为据我所知，大多数应用程序都使用一些 shell 脚本来启动应用程序，而不仅仅是 package.json）。但我相信这个_概念证明/提案_可能是指向下一次重大升级的指针。

anandhumanoj 于 2019-04-05

🚀1 👍1

I have an idea. Because electron currently supports the command "electron.exe path". I think you can open it by calling multiple asars from the command line. At present, I'm just an idea. I hope someone can do it, because I've just touched on this software.
_____________中文翻译版本__________
我有一个想法。因为目前electron支持命令“electron.exe path”。我觉得可以通过使用命令行去调用多个asar实现打开。目前我只是一个想法，我希望有谁可以去做一下看看，因为我目前刚刚涉及这个软件。

nwdxlgzs 于 2019-05-18

粗略的看了看全部对话（和其他的讨论，如Multiple "apps"），我总结一下——原生调用多个asar而不是靠多个二进制文件启动，这个已经有很久的历史了，但是未支持。但是electron的default_app就是一个利用命令行实现的（可能，我暂时不清楚）。我想通过electron调用cmd（好像可以）应该可以实现这个功能兼容吧。
Taking a cursory look at all the conversations (and other discussions, such as Multiple "apps"), I conclude that native calls to multiple Asar instead of multiple binaries start, which has a long history, but is not supported. But Electron's default_app is an implementation that takes advantage of the command line (and, perhaps, I don't know for a while). I want to call cmd through electron (as if I can) should be able to achieve this feature compatibility bar.

nwdxlgzs 于 2019-05-18

在最坏的情况下，您必须为非 Windows 操作系统制作一个 .bat 文件或等效文件，然后从 Electron 运行它。

sapioit 于 2019-07-04

可能有用的链接：

https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
https://www.freecodecamp.org/news/node-js-child-processes-everything-you-need-to-know-e69498fe970a/

9718

https://stackoverflow.com/questions/50491092/execute-a-cmd-line-with-electron-angular
https://github.com/martinjackson/electron-run-shell-example

sapioit 于 2019-07-04

似乎只有在没有 app.asar 或 app 文件夹的情况下才是命令电子。 exe路径有效

nwdxlgzs 于 2019-07-04

哦，所以你需要一个电子来运行用于设置所有这些的电子内部的 exe 路径。仍然比使用的每个应用程序的电子安装更好。对于您的应用所需的每个电子版本，您只需要一个电子安装。您可能需要创建一个单独的扩展，它是一个重命名的 zip 存档，其中包含我们尝试运行的应用程序和具有推荐版本的文件（将立即运行）、兼容版本（会询问是否运行或安装推荐的版本，并在后台下载推荐的 Electron 版本），或者只是显示一个下载进度条，以便下载推荐的版本。

sapioit 于 2019-07-09

或者我误解了什么。

sapioit 于 2019-07-09

这个思路大概是一样的：既然bat目前说起来容易，就拿它来说吧，内容是electron.exe app1.asar，执行后electron打开app1.asar的内容。大概是这样的，但是当你在bat中写下一句electron.exe app2.asar的时候，只能在app1.asar的electron结束时才可以这样做。而当 bat 关闭时，电子也会关闭。但是我写的是electron.exe app3.asar|electron.exe -v 或者electron.exe app3.asar|start等等。当我关闭蝙蝠时，电子可以存活，但我不能继续打开其他asar。我认为这个独立的程序可能比这个更好，因为 bat 仍然有些限制。

nwdxlgzs 于 2019-07-09

如果您使用临时文件夹，则不会。

您在 electron_versions 文件夹中有（存档或未存档）版本，您可以从中使用推荐版本或下载的最新兼容版本，方法是将您正在使用的版本复制到临时文件夹，完成后，您删除文件夹。

本地保存文件的路径可能在电子文件夹中或您正在使用的文件旁边。如果您从包含我在过去 24 小时内提到的内容的存档中使用它，那么您必须将保存的数据文件移回存档，或者在删除该临时电子实例文件夹之前根本不移动它。

sapioit 于 2019-07-09

固态硬盘？

nwdxlgzs 于 2019-07-09

？？？

删除临时电子文件夹的原因是因为该应用程序理论上可以更改它们正在运行的电子安装文件，并且是设计使然。我的意思是，存档可以包含需要在临时电子安装中写入或覆盖的文件和文件夹。

sapioit 于 2019-07-09

所以安装使用后，它可以被它运行的应用程序视为已损坏，因此无法回收，因此必须删除。但是，当时已损坏的安装用作基础的版本仍然完好无损，在我们尝试制作的运行时电子应用程序的 electron_versions 文件夹中。

实际上，如果我之前提到的具有不同扩展名的存档是只读的，那么它使用的数据理论上可以移动到 %appdata%。因此，在我们尝试创建的运行时模式电子中运行的应用程序实际上是可移植的（自包含的），因此复制该文件就足以让您随身携带该应用程序的配置。

但是我们可能还需要为该文件类型添加一个更新功能，这将是另一个电子安装，它将文件从新安装文件复制并覆盖到旧安装文件的副本，并返回新安装文件和它拥有的数据。如果我们尝试制作的 runtime-mode-electron 使用的文件中有下载链接，那么整个事情都可以自动完成。

sapioit 于 2019-07-09

一旦准备好，如果你想加倍努力，你甚至可以添加一个 git 客户端来更新应用程序，尽管这可能需要使用 github 和 bitbucket 来托管存档编译文件。

sapioit 于 2019-07-10

你可以使用“curl,wget,aria2c”下载文件，用户可以不需要安装git，哦，你需要使用“gzip,7z”解压zip。

nwdxlgzs 于 2019-07-10

我正在制作一个与electron-builder类似的工具electron-runtime #$ 。它仅将app.asar文件与一个简单的sh脚本捆绑在一起（稍后这将是一个显示 Electron 下载进度的 UI）。目前它仅适用于 macOS。

当运行使用electron-runtime打包的应用程序时，它基本上会下载对应的 Electron 主版本，但在次要和补丁的情况下是最新的，因为 Electron 的重大更改仅在主版本增量中发生。

electron-quick-start应用程序只有 62 KB，截图：

如果您对此感兴趣，请留下星标、PR 或问题。

sentialx 于 2019-08-15

👍17

我已经稍微更新了软件包，它可以使用electron-builder构建（这里描述了它的工作原理）。所以现在你甚至可以用它来构建 Visual Studio Code！（但仍然只在 macOS 上）。

sentialx 于 2019-08-16

我成功发布了electron-global的第一个版本！（我更改了它，因为electron-runtime已被占用）。您可以使用我的带有electron-builder的 npm 包构建您的应用程序。我还添加了一个带有进度条的 UI，以显示 Electron 下载的进度。我希望让 Electron 变得更好更受欢迎。

sentialx 于 2019-08-24

👍16

对不起，我用的是Windows系统，没钱用MacOS。但我相信你的项目会很成功的。

nwdxlgzs 于 2019-08-24

@nwdxlgzs它支持 Windows、macOS 和 Linux...

sentialx 于 2019-08-24

我以为这个项目只支持 MAC。
我将花时间尝试这个伟大的项目。

nwdxlgzs 于 2019-08-24

感谢您制作它并让我们保持最新状态！
我也在使用Windows。
当我得到更改时，我会看一下代码。

sapioit 于 2019-08-24

那么，如何在上游整合electron-global并使其成为新的默认值😏

eMPee584 于 2020-09-15

👍5 🚀2 ❤1

Electron: 运行时模式的想法

最有用的评论

所有259条评论

理由：

最有价值球员：

很高兴有：

要求：

启示：

9718

相关问题