+100、それはアプリのサイズを減らすのに非常に役立ちます。

.asar拡張子を変更できますか？ ハンガリー語では本当に奇妙に聞こえます。 基本的に、それは悪い意味the shitを意味します（リンク）。

.apak?真面目な話ですが、言語はたくさんあるので、ほとんどすべての拡張機能が奇妙に聞こえる場合があります。

IMOランタイムのインストールと更新は、可能な限り簡単にする必要があります。 多くのランタイムには、非常に迷惑な通知があります。 また、これを行う場合は、新しいアプリのバージョンが古いランタイムで機能しない可能性があるため、追加のマニフェストメタデータを提供する必要があります。そのため、現在のランタイムバージョンをアプリマニフェストのバージョンと比較する必要があります（ノードのバージョンの範囲でさえある可能性があります）パッケージ）、ランタイムを更新する必要がある場合は、このプロセスをできるだけ簡単にします。 ほとんどの人にとって簡単なことはわかりませんが、私にとっては、プログレスバーまたはステータスメッセージ（「ダウンロード中... 57％」、「更新中...」）が表示されたウィンドウです。
よくわかりませんが、バックグラウンドアップデートも検討される可能性があります。 これは、更新サービスの場合もあれば、アプリの実行中のランタイムダウンロードであり、アプリの終了時に更新される場合もあります。

このために+1。 私はMacとWindows用に配信しなければならないアプリケーションに取り組んでいます。これにより配信が大幅に簡素化されます。

これは素晴らしいでしょう！

いくつかの考え：

• @YuriSolovyovが言ったように、特定のasarが互換性のあるアトムランタイムのバージョンを宣言する方法が必要です。 asarベースのアプリをリリースする際のQAの負担が軽減されるため、正確なバージョンを指定できるようにすることをお勧めします。
  
  
  
  • これをサポートするには、アトムランタイムの複数のバージョンを並べてインストールできるようにする必要があります。これは、ユーザーには見えない可能性があります。
  
  
  • これは、ダウンロードサイズを制限するという理想とは多少相容れないことに注意してください。 ただし、複数のasarベースの製品を製造している会社は、社内で標準化できるため、すべてのアプリで同じバージョンが使用されます。
  
  
• Macでのアトムランタイムの自動更新のサポートについては言及していませんが、それは_非常に_便利です。
• Linuxにソースのみをインストールするのではなく、.deb / .rpmパッケージと、インストールにsudo権限を必要としない方法（ユーザーごと）の両方を介して、バイナリのインストール/更新をサポートすることをお勧めします。 ユーザーごとにインストールされたランタイムの場合、自動更新も非常に便利です。
• インストールされたasarファイルを最新の状態に保つためのサポートはありますか？それとも、各アプリに個別に実装する必要があるものですか？

最後に、この取り組みのタイムラインは何ですか？ これの一部の実装を開始したい場合、開始するための最良の方法は何でしょうか？ 私は貢献することにオープンです。

@ joshuawarner32現在、これは大まかなアイデアです。アトムシェルのいくつかの主要な問題を解決した後で作業する予定ですが、数か月後になる可能性があります。

また、既存のランタイムと、それらがどのように機能/更新されているか、それらがどれほど邪魔であるか、その他の長所と短所を確認することも価値があると思います。

現在、これは大まかなアイデアです。アトムシェルのいくつかの主要な問題を解決した後で取り組む予定ですが、数か月後になる可能性があります。

約5〜6か月経ちました。 これを実装しておくと便利です。

特定のユースケースに非常によく適合するこれの内部実装を構築しており、それをアップストリームできる可能性があります。 危険なのは、それが実際には私たちのユースケースにあまりにも具体的であり、他の誰もその余分な複雑さに興味がないということです。

これが私たちのデザインのハイライトです：

• サーバー上のいくつかの異なるアプリの.asar.gzファイルをデプロイします
• アトムシェルの単一ビルドをユーザーに配布します。これには、特定のアプリのコードはバンドルされていません。
• アプリの起動時に、適切な.asar.gzファイルをダウンロードします（ファイルがない場合、またはサーバーに新しいファイルがある場合）。 それを抽出し、含まれているアプリを実行します。
• アトムシェルビルドは、ダウンロード/実行するアプリを指定するために--app引数を受け入れます

そのようなものは、原子殻の人々が念頭に置いていたものですか？ そのようなものは他の人に役立つでしょうか？

JREと同様に、.eappファイル（electron app）を備えたERE（electronランタイム環境）である可能性があります。

.eappの場合は-1

+1必要です！

Windowsでは、atom-runtimeのインストーラーと自動アップデーターを提供し、それで開く.asarファイルタイプを登録できます。

WindowsにSteamをインストールして、ゲームのショートカットを作成する方法を確認してください。実際にはプロトコルハンドラーを使用しており、比較的賢いです。

：+1：Steamモデル。

これを実装する上で技術的な障害はありません。すべてがElectronアプリ自体である可能性があります。 しかし、問題は、すべての詳細を考慮に入れて、どちらも実装するのは簡単ではないということです。小さなチームがフルタイムで作業する必要があると思います。それが起こるかどうかはわかりません。

しかし、問題は、すべての詳細を考慮に入れて、どちらも実装するのは簡単ではないということです。小さなチームがフルタイムで作業する必要があると思います。それが起こるかどうかはわかりません。

確かに乗り越えられないわけではありませんが、この計画を難しくしているという質問がたくさんあります。 たとえば、「アプリ1」には0.30.xが必要であり、0.31.xで実行することはできません。また、「アプリ2」にはその逆が必要です。 このシナリオで誰が勝ちますか？

開発者の複雑さを犠牲にして、ディスクスペースと帯域幅など、私たちの最大の問題ではないものを最適化するための多くの努力とインフラストラクチャ/トリッキーのようです（つまり、開発者は最初にインストールするためにこのクレイジーなチェーンインストーラーを作成する必要があります/ Electronを確認してから、アプリをインストールします）

私はアイデアに嫌悪感を抱くつもりはありません！ これを行うのにかかる時間で、代わりに大きな問題に費やすことができると思います。新しい開発者が、コードの最初の行からユーザーへの発送

@paulcbettsでもねえ、それはそれだけの価値があるメリットですね。 アプリを更新する場合、ユーザーは70MBではなく1MB未満をダウンロードする必要があります。 つまり、自動更新フレームワークも必要ありません。いくつかのファイルを含むマイクロzipアーカイブをダウンロードして抽出するだけです。

私は過去3か月間、速度が128kbps未満の遠隔地で過ごしましたが、信頼できます。アップグレードサイズは非常に苦痛です。最悪の部分は、同様の状況にある人がまだたくさんいることです。

つまり、自動更新フレームワークも必要ありません。いくつかのファイルを含むマイクロzipアーカイブをダウンロードして抽出するだけです。

しかし、それは真実ではないと思います。ほぼ確実に、ある時点で、Electronの新しいバージョンにアップデートしてから、kerplowieに移行したいと思うでしょう。あなたは、同じような状況にあります（または、少なくとも1つは同様に醜いです）。 ）。

パッケージ内に大量のビデオが含まれていない限り、基本的なアプリは30〜50メガバイトになりました。 ほとんどの人がダウンロードするのはそれほど難しいことではないと思います。 私は平均的なYouTubeビデオが30から40メガバイトの間であると信じています...

ここでメモしたいのですが、中国では、接続速度は平均で約20kB / sです（接続速度が都市の約92％より遅い場合）。通常、Atom / electronの更新には1日かかります。 wget -c 'ing。 淘宝網ミラーを使用しない限り。

バージョンの互換性のために、electron開発は速すぎてキャッチオールバージョンを作成できません。おそらく、アプリの起動時に、ある種のラッパー/ヘルパーを使用して、要求されたメジャーバージョンを使用/ダウンロードできますか？

20 kb / s？ どうやって生き残ることができますか？ それが物事をいかに難しくしなければならないか想像できません！

@steelbrainは私の意図ではありません

@RIAEvangelist速い時間と多くの忍耐で乗ります。 速度は深夜に非常に速くなるので、寝ている間にダウンロードを実行またはスケジュールしたままにしておきます。 ：3

とにかく、（基本的な）サードパーティのラッパーを作成するのはそれほど手間がかからないと思います。誰かが試してみたいですか？

ただし、.asarファイルは電子バージョンを簡単に宣言できません。 おそらく、別のプログラム記述子システムが必要になるでしょうか？

（必要に応じてダウンロードし、）ランチャーがアプリのランタイムのバージョンを必要とする、ある種のランタイムバージョンのディスパッチャーはどうですか？ そのためにpackage.jsonにエントリを追加できます。

@YuriSolovyovデフォルトでランタイムが.jsonファイルを処理するように指定できないことを除いて。 最初にasarファイルを読み取ってpackage.jsonを表示できると思いますが、それでは少し遅くなります。

@Tribexはい、ロジックフローは次のようになります。

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

理想的には、ランタイムモードはSteamやChromeアプリランチャーのように機能する必要があります。 主な問題は、ランタイムが新しいバージョンにアップグレードするときにアプリをどのように処理するかです。

Electronアプリは、Electron、特にノードネイティブモジュールのアップグレードに悩まされています。 C ++ ABIの問題により、Electronのアップグレードごとにネイティブモジュールを再構築する必要があります（ユーザーから報告された、再構築を忘れたクラッシュの問題がいくつかあります）。

Steamのすべてのゲームはスタンドアロンプ​​ログラムであるため、Steamは苦痛に悩まされることはありません。実際には、Steamクライアントなしでゲームを起動できます。 Chromeアプリの起動も同様です。Chromeアプリは解釈された言語の一種であるHTML / JS / CSSで記述されているため、異なるバージョンのChromeで実行されるギャップはありません。

@hokeinは、母国語で軽量の「クライアント」を用意しています。これは、複数の言語をダウンロードします。アンインストールされたバージョンの電子に依存するアプリに遭遇すると、そのコピーをダウンロードして、特定の電子で各アプリを実行します。

週に1回程度の新しいElectronリリースがあるので、2つのアプリがまったく同じバージョンのElectronを持っている可能性はわずかです。

ランタイムアプローチをサポートするには、リリースをLTS（長期サポート）バージョンと最先端バージョンに分け始める必要があります。 LTSは本番用であり、最先端は開発とテスト用です。 LTSはバグ修正と、おそらくio.jsとコンテンツシェルの主要バージョンを置き換えないいくつかの変更のみを取得するため、ネイティブモジュールは引き続き機能するはずです。

@etiktinが言ったことを考えると、ユーザーがシステムに多くの電子アプリを持っていない限り、ほとんどの場合実行時間をダウンロードする必要があるため、ダウンロード時間のメリットはないでしょう。

2週間で私は電子を見てきましたが、今では4つのリリースを見たと思います。

@etiktin理想的には、electronがsemverに続く場合、アプリはバージョン^ 0.31を宣言でき、最新の0.31.xリリースを使用します。 それは物事を少し助けるかもしれません。

次のことを行うsemver自動更新メカニズムを備えたアプリが本番環境にあります。

1. アプリの現在のバージョン（0.3.0、0.3.1など）とプラットフォーム（darwin-x64、win32-ia32、win32-x64など）を提供するサーバー上の単純なHTTPエンドポイントを取得します。
2. サーバーは「304NotModified」を返します。新しいバージョンがある場合はJSONマニフェストを返します。
3. JSONマニフェストは、基本的に、新しいバージョンのフォルダー、ファイル、およびシンボリックリンクのネストされたリストです。
4. JSONマニフェストのフォルダーエントリは次のようになります：[名前、子エントリの配列]。
5. JSONマニフェストのファイルエントリは次のようになります：[名前、コンテンツのハッシュ、64KBのチャンクに分割されたコンテンツのハッシュの配列、ファイルが実行可能かどうかを示す整数フラグ]。
6. JSONマニフェストのシンボリックリンクエントリは次のようになります：[名前、宛先パス]。
7. これらのJSONマニフェストは、バージョンごとに作成され、サーバーにキャッシュされます。 サーバーは、JSONマニフェストのファイルごとに、単純な重複排除アルゴリズムを実行して、コンテンツに依存するチャンクを使用してファイルを可変長のチャンクに分割し、SHA256を使用してチャンクをハッシュします。 これにより、コンテンツが数バイトシフトされた場合でも、同じファイルの異なるバージョンのほとんどのチャンクハッシュが同じままになります。 最適な重複排除+圧縮効率のための平均チャンク長は約64KBです。 チャンクが大きい場合は重複排除も行われず、チャンクが小さい場合は圧縮も行われません。 メタデータにチャンクハッシュが多すぎるのを避けるために、非常に大きなファイルの平均チャンク長も長くなります。
8. アプリがサーバーから新しいJSONマニフェストを受信すると、使用可能な空きディスク領域を確認し、ユニバーサル一意IDを使用して新しい一時ディレクトリを作成します。 次に、古いローカルマニフェストを開始点として使用して、ローカルファイルからチャンクをコピーするか、サーバーから欠落しているチャンクをダウンロードして、新しいマニフェストを再作成します。 新しいバージョンを作成した後、すべてのファイルコンテンツのディレクトリ構造と署名を確認します。 ダウンロード中に破損したものがある場合は、更新が削除されます。
9. 新しいアップデートがマニフェストに対して正常に検証されると、新しいアップデートパスでアプリの新しいバージョンが起動されます。
10. 古いバージョンは、別のバージョンが実行されていることに気づき、自動的にシャットダウンします。
11. 新しいアプリは、古いバージョンがシャットダウンするのを待ってから、自分自身を別の一時ディレクトリにコピーし、古いバージョンの名前をアーカイブディレクトリに変更し、一時ディレクトリの名前を古いバージョンの場所（/Applications/Ronomon.app）に変更します。 その後、再び実行されますが、現在は古いバージョンの場所（/Applicatons/Ronomon.app）から実行され、アーカイブディレクトリがクリーンアップされます。
12. 移行中に問題が発生した場合、rename呼び出しによって切り替えられるまで、古いバージョンは正規のパスのままになります。

全体として、本番環境では非常にうまく機能しています。 重複排除と圧縮により、通常のメジャーバージョンアップデートでは約33％しかダウンロードする必要がなく、アプリによってはマイナーアップデートに必要なのは1〜2MBだけです。 自動更新は、Electronとアプリのコードを1つのアトミックユニットとして処理し、プロセス内のコード署名に違反することはありません。

+1アイデアへ
+1名前を変更するにasar

私はこれに関して問題を起こすために降りてきました。 これはすでに存在していることがわかったので、+：100：をこれに追加します
各アプリでランタイムをパックすると非常にかさばるので、JRE、.NET、またはAdobeAirのようなソリューションが完全に必要です。

ランタイムをアプリから分離することに関する更新はありますか？

ソリューションが開発されたため、これは閉じられていますか？

@PierBoverこの問題は未解決です。

これ--https：//github.com/KeitIG/museeks/issues/48-閉鎖されました。 他の誰かのリポジトリにあります。

@championswimmerに感謝し、混乱してすみません。

では、独立したランタイムに関するニュースはありますか？ これは現在取り組んでいるものですか？

@PierBoverは、現在のバージョンの断片化のため、おそらくすぐには発生しないでしょう（同じ正確なバージョンを使用している2つの電子アプリを見つけるのは難しいです）。 たぶんv1がリリースされた後。

@jorangreefすべてのプラットフォームで差分更新メカニズムを使用していますか？ そのコードをスタンドアロンモジュールとしてリリースできれば素晴らしいと思います。

@championswimmerはい、アプリのビルドスクリプトを作成できたので、今すぐアプリを配布しても大丈夫です。 でも面白いので注目しています。

@etiktinはい、現在、差分自動更新はすべてのプラットフォームで機能します。 ダウンロードを行う最小限のインストーラーも含まれている場合、インストーラーは複数のアプリで共有でき、既に利用可能な場合はキャッシュバージョンのElectronを使用できます。 これにより、インストールがはるかに高速になります。 興味があればオープンソースにしたいと思います。数か月以内にコードをリリースする予定です。

たとえば、「アプリ1」には0.30.xが必要であり、0.31.xで実行することはできません。また、「アプリ2」にはその逆が必要です。 このシナリオで誰が勝ちますか？

次に、2つのバージョンをインストールする必要があります。VSC++ 2008が2005と共存するのと同じように、2つのランタイムがあります。VSC++ランタイムのインストール方法が本当に気に入っています。必要なバージョンがない場合はインストーラーがインストールし、他のバージョンは後で、異なるランタイムが共存できます。 バージョン要件の適用も、インストーラーでより簡単に実行できるようです。

@ louy2 Visual C ++の例（リリース間で3年）とElectron（少なくとも月に3回のリリース）には違いがあります

大多数の場合、ここで「これは壊れたシステムです」という引用を付け加えます
Electronエコシステムのアプリは+ -0.0.1または
0.1.0バージョンの違い

2016年2月20日18：55、PierredelaMartinière<
[email protected]>は次のように書いています：

@ louy2https ：//github.com/louy2との間に違いがあります
Visual C ++の例（リリース間の3年）、およびElectron（リリースごとに3つのリリース）
少なくとも1か月）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/atom/electron/issues/673#issuecomment-186595285 。

+1

fpmを使用してelectronを.debパッケージにパッケージ化しました。 これは、Linux（少なくともDebianベースまたはRPMベース）の公正な出発点となる可能性があります。 あなたはここで見ることができます： iamale / electronic-deb ; サンプルアプリもあります。 （これはasarでも機能し、ランタイムパッケージにMIMEエントリを追加する必要があります。）

他のプラットフォームでもそのようなものがあれば本当に素晴らしいです！ おそらくWindows用にパッケージ化することもできますが、もう積極的に使用することはなく、実際には多くの経験がありません。

（このスレッドを私に指摘してくれた@ louy2に感謝します！）

ちなみに、.asarのMIMEタイプは何ですか？ application/x-asarはしますか？

@iamale fpmの代わりに、$＃$ 1 AppImageKit ＃$をご覧になりましたか。 取得する主な利点は、複数のライブラリとすべてを作成する代わりに、1つの実行可能ファイルですべてのLinuxディストリビューションをターゲットにできることです。 また、実行可能ファイルにバンドルされているため、依存関係をインストールするようにユーザーに依頼する必要もありません。 いいプロジェクトですので、ご覧ください。

そしてmimeについては、 application/x-electronどうですか？

@steelbrainそれはいい考えです。 ただし、これでは元の問題は解決されません。Electronランタイムを各アプリにパッケージ化する必要があります（画像は自己完結型である必要があるため）。これがまさにこの問題の原因です。 ElectronアプリからAppImagesを作成するのは比較的簡単なはずですが、これは従来のパッケージ管理を使用できない場合（まれなディストリビューションや非特権ユーザー）に最適だと思います。 それで、それを指摘してくれてありがとう！

ちなみに、 application/x-electronは素晴らしいサウンドですが、おそらくそれに固執するでしょう。

asarサポートが追加されました！ まだリポジトリにありませんが、今日または明日遅くに再構築します。 今のところ、 transfer.shでパッケージを入手できます（リンクは今後2週間有効になります）

次のように、.asar内にasar.jsonが必要です。

• 推奨バージョン
• 互換性のあるバージョン
  それが完了したら、electron（その任意のバージョン）を使用して、（1）それ自体（チェッカー）の更新と（2）コンピューター内の既存のバージョンをチェックするために、1つのアプリが必要です。互換性のあるバージョンが存在する場合は、解析します。開いた.asarへの開始パス。それ以外の場合は、推奨バージョンをダウンロードして、もう一度確認してください。 アプリ自体は、Electronまたはpythonで記述できます（UIが最小限であるか、まったく必要ないため）。

アイデアは次のとおりです。必要な電子バージョンがダウンロードされているかどうかをチェックするアプリは、必要な電子バージョンとは何の関係もありません。

必要に応じて、default_appのコンテンツと、それを除くアプリの残りの部分を更新できます。

そこで、 app.setPath("userData", __dirname + "/ElectronVersions");でバージョンを保存して、それらのバージョンをそのままにして、必要に応じて新しいバージョンをインストールすることができます。

fpmの代わりに、AppImageKitをご覧になりましたか。

https://bintray.com/probono/AppImages/Atom/_latestVersion#filesにAtomのAppImageがあります。 chmod a+xをダウンロードして、古すぎないx86_64Linuxディストリビューションで実行してください。

問題はLinuxだけではなく、クロスOSにする方法が必要です。つまり、Linux、Windows、MacOSxで実行できるようにする必要があります。

ランタイムが利用可能であり、最新/ asarパッケージと互換性があるかどうかを検索するOS固有のランチャーの一種

（数年後）議論を要約しましょう：

1. @zcbenzは、ローカルのElectronインスタンスを管理するランタイムを提案しているため、 .asarパッケージのみが配布され、Electronバイナリのバンドルは回避されます。 ランタイムは、 .asarパッケージの実行も管理します。
2. @YurySolovyovは、追加情報（たとえば、必要なElectronバージョン）を使用してマニフェストファイルを拡張することを提案しているため、ランタイムは、どのバージョンがどの.asarパッケージに使用されるかを認識します。 このアプローチの概要をここに示します。
3. @ joshuawarner32は、複数のランタイムバージョン、バイナリパッケージ（たとえば.deb ）、および.asarパッケージの自動更新のアイデアを紹介します。 さらに、配布サーバーのアイデアが考慮されます。
4. @paulcbettsは、Steamモデルとして見て、同様のものを実装することを提案しています。 彼は、さまざまなElectronバージョンなどをサポートするローカルランタイムのアイデアに伴う複雑さを指摘しています。
5. [人々は中国のインターネット速度と彼らの子供時代の事柄について話し合う]
6. @hokeinは、ランタイムがアップグレードされたときの複雑さを指摘しています。 特にwrt。 Electronヘッダーに対して再構築する必要があるネイティブモジュール。
7. @etiktinは、LTSと最先端のバージョンを必要としているため、本番環境に対応したアプリは最先端ではなくLTSを使用します。
8. @Tribexによると、セマンティックバージョニングに固執する場合、_all_バージョンのローカルインスタンスは必要ありませんが、互換性のないバージョンのみが必要です。
9. @jorangreefは、独自のアプリケーション用にすでに本番環境にある差分自動更新システムの例を示しています。
10. @iamaleは、 .asarパッケージを実行するためにElectronのfpmパッケージを構築しました。

_免責事項：私は議論の主要なポイントだけを含めるようにしました。 何か見落としたら失礼します！_

私はここまでの議論を読み、要点を要約しようとし、それらのいくつかに取り組みたいと思いました。 「深いプラットフォーム統合」を備えたランタイムのアイデアは、単純なローカルインスタンスを超えています。 システム全体のランタイムとして機能する、実行可能な最小限の製品を定義する必要があります。 また、便利な便利な機能も追加しました。 最後のセクションでは、実装する必要のある変更/機能について説明します。

理論的根拠：

ほとんどの開発者が行っていること（つまり、Electronバイナリのバンドル）は、すべての共有ライブラリを静的にリンクするようなものです。 それは、私たちが販売するすべてのピザにオーブンを届けるようなものです。

MVP：

• 環境マネージャー：ローカルで利用可能なElectronインスタンスを追跡します。 これを使用して、どのパッケージがどのインスタンスと互換性があるかを判断できます（拡張されたpackage.json [以下を参照]を使用）。 また、パッケージを実行するための正しい環境変数の設定にも注意を払う必要があります。
• 更新マネージャー：自動更新（+通知）と差分自動更新の可能性について説明しました。 ローカルインスタンスを最新バージョンに更新するデーモンとしてそれを持っているといいでしょう。

あった方がよい：

• パッケージ/依存関係マネージャー： Atomのapmと同様に、パッケージマネージャーは.asarパッケージを（GitHubまたは特定のURLなどから）ダウンロードしてローカルにインストールする必要があります（ apt-getと比較して） Ubuntuの場合はbrew ）。

要件：

• 拡張マニフェストファイル： package.jsonには、必要なElectronバージョンを示すsemver （またはsemver範囲）も含まれている必要があります。
• 定義されたインストール/アンインストール手順：ATM .asarパッケージには、アプリケーションの実行に必要なすべてのものが含まれています。 ただし、インストール時にソースとダウンロードの依存関係モジュールのみを配信することは可能です。 勇気が出すぎる場合は、すべてのアプリケーションの依存関係を含むある種の_global_ディレクトリを作成できます（npm 3のフラットな構造が役立つ場合があります）。 ただし、これは非常に複雑になり、非常に高速になる可能性があります（たとえば、アプリをアンインストールする場合）。
• 複数のローカルランタイム：これまでセマンティックバージョニングが適用されていた場合、互換性のないバージョンは0.xと1.xの2つだけです。 マイナーバージョンとパッチには下位互換性があるはずなので、システムに必要なのは最新バージョンの0.xと1.xだけです。

インスピレーション：

• 環境/依存関係マネージャー：Pythonのvirtualenv 、Rubyのrbenv 、およびruby-buildも参照してください。
• パッケージマネージャー：Pythonのpip 、Atomのapm 。
• 更新マネージャー： Chromiumのzygoteプロセスには、_サイレント、バックグラウンド_更新に対する興味深いアプローチがあります。
• コードトランスレータ（新しいAPIに適応するため）：Python 2to3 。

epm （エレクトロンパッケージマネージャー）はすでに名前になっているようです...
たぶん、ランタイムelec 、アプリ.tronと呼びますか？ TRONにはおそらく商標の問題がいくつかありますが、クールに聞こえます;）

たぶんuepm （ユニバーサル電子パッケージマネージャー）、それは-ElectronでサポートされているすべてのOSで実行されることを意図しているからです...またはepmc （電子パッケージ管理センター）とファイル.epack （電子パッケージ）。 拡張機能は、少なくとも.tronよりも優れており、映画と混同することはできません（「あのトロンのことを言ってください」_映画を手渡します_）。

電子に関連する理論物理学の分野にも多くの言葉があります

• フェルミオン
• レプトン
• 充電
• クーロン
• パウリ

そして、直接関係はありませんが、パッケージマネージャーで何が起こっているかにより一致しています。

• ボソン
  ;）
  （私は光子がすでに取られていると信じています）

@kapouer +クォーク？ それが取られているかどうかはわかりませんが

クォークが取られ、残りは私にはわかりません。 しかし、この提案リストが現状を維持しないことを示唆しているのに、なぜ現状を維持しなければならないのでしょうか。 しかし、私たちはそれに取り組んでいるので、それをHauldronと名付けてみませんか？ LHCから撮影。 コライダーは良い考えではありません、それはその意味が戦争と密接に関連しているので、製品にネガティブな色合いを与えています...

Particle(s) ？ でもかなり長いです。
ウィキの粒子のリスト

名前付けは重要ですが、それでも、最初にランタイム/更新/パッケージング/配布のセマンティクスを調査する必要があると思います。

leptonは、電子が属する粒子のファミリーであるため、完璧に見えます。

少し範囲外のアイデア：より一般的なランタイムマネージャーはさらに素晴らしいでしょう（そして実装するのはそれほど難しくありません）。 たとえば、 @ nwjsバイナリも含めて、同じversion-manager-thingyで管理することもできます（@ asdf-vmと同様ですが、GUIランタイム用です）。

迅速で汚い： https：//github.com/iamale/lepton。 今のところ修正バージョンのみをサポートし（semverが次に行うことです）、アプリは解凍されます（つまり、.asar-sはまだありません）。

良い！

+1

.asar、 @ iamaleがなくても、どのファイルを開くかを知る方法があれば、問題ないと思います。 たとえば、 file.somethingとjsonコードをpackage.jsonにリンクして、何を開くかを認識できるようにすることができます...

これは非常にクレイジーなアイデアですが、 package.jsonのelectronフィールドを使用して作成するのはどうでしょうか。
（まあ、ANYとは異なりますが、準備された）npmパッケージの実行可能ファイルはありますか？
お気に入り：

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

これは、 electronにnpmパッケージをインストールする機能を追加し、それらを実行可能にしてホストシステムで表示できるようにすることで実現できます。
と同じように

electron install atom

これを機能させるには、 electronコマンドと実際のランタイムバンドルを分割する必要があります。

しかし、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"
  ]
}

この例では、electron 1.2を使用することをお勧めします。見つからない場合は、1.2.1と1.2.5の間にバージョンがあるかどうかもチェックし、ない場合は1.3.1をチェックし、そうでない場合は1.3.0.1をチェックします。 1.1の場合、そうでない場合は1.2をダウンロードします。

推奨バージョンを自動的にダウンロードするようなものがあるかもしれませんが、ダウンロードできない場合は、互換性のあるバージョンをチェックします。 そして、互換性のあるものをすべて取り、それらをチェックし、何も機能しない場合は、互換性のないバージョンを使用しないかどうかをユーザーに尋ね、 noを押すと、互換性のないバージョンで実行されますPCで検出され、何も検出されない場合は、互換性のないバージョンを使用するように要求する代わりに、電子のインストールが検出されなかったことを示すエラーポップアップを表示します。

@sapioit別のマニフェストを持つことは、私には良い考えのように思えます。 カスタムファイル拡張子を使用すると、作業がかなり簡素化されます。 （.electronは少し長いようですが。）

たぶん@iamaleのレプトンによると、.lept？

package.jsonを使用しないことによるメリットは見当たりません。電子フィールドが分​​離部分を行います。 BabelとESlintはこの手法を使用しており、問題なく動作しています。
これにより、npmに直接/経由してアプリを公開するのがはるかに簡単になります。

ええ、私は2番目の@YurySolovyovです- package.jsonに入れる方が適切だと思います

@YurySolovyov追加ファイルの利点は、ランタイムが追加ファイルの拡張子のハンドラーを登録し、ファイルのデフォルトのオープナーとして自動的に実行できることです。 package.jsonでこれを行うには、すべてのJSONファイルのハンドラーを登録する必要があります。これはユーザーにとって苦痛です。

@Tribexフェアポイント。
たぶんpackage.electronは、ランタイム"Hey, take a look at package.json, it should contain the info on how to launch it"を伝えるある種のリンクである可能性があります。 これは「クレイジー」なアイデアだったので、ええ、私はそれを微調整しても大丈夫です。

@tribexに同意します。別のファイルを使用するか、package.jsonの名前を変更する必要があります。 他の何かに。

@wurysolovoyovあなたはそれを行うことはできません。 ファイルを開くことができるのは、拡張子を付けることだけです。この場合、すべての拡張子が同じソフトウェアで開きます。 したがって、 electron以外で.jsonを開くことができないことに問題がない限り（適切なelectronアプリを開かない限り、エラーが発生します）、それを行うことができます。しかし、 .jsonファイルを開くことができるようにしたい人は、それらを開きたいプログラムでそれらを開くことができるようにしましょう。

そうしないと、最初にエディタを操作するか、1分ごとに.jsonを開く内容を変更しない限り、ファイルを編集できません。

@wurysolovoyovではなく@YurySolovyovを意味します

明確に述べていないかもしれませんが、 package.electronの目的は、このディレクトリがアプリであることを示すマーカーとして機能することだけです。そのため、ランタイムは同じフォルダーにあるpackage.jsonを参照できます。 、アプリを起動します。 package.jsonを直接開くと、OSの.jsonに関連付けられているものすべてで開きます。

ショートカットシステムのようなものです。

@YurySolovyovその場合、その情報をpackage.jsonまたはpackage.electronで定義するかどうかは好みの問題です。 私はそれが私にとってよりきれいに見えるという理由だけでそれを個人的に分離しておくでしょう。 おそらく、package.jsonのenginesプロパティで十分でしょう。

@Tribexアプリをnpmに公開するための要件でもあります-有効なpackage.jsonを持っている

@YurySolovyovそうですね。 package.electronを使用した場合、package.jsonは引き続き存在します。 .electronは、実行時情報を定義するためにのみ使用されます。または、提案の場合は、単なるマーカーになります。

基本的に、 package.electronは起動可能な_marker_としてのみ存在するため、package.jsonには独自のデータが引き続き存在しますが、それが別のファイルが必要になる理由です。_doubleclickはアプリを開きます_。 package.electronの名前をmy-app.electronまたはmy-app.electronに変更できるようにしたいのですが。

@sapioit確かに、それが.electronファイルを持つことの要点です。 .electron拡張子が付いている限り、任意の名前を付けることができます。

ランタイムハンドラーが* .electronを調べ、次にpackage.jsonを調べて、実行する電子のバージョンを決定し、次にpackage.jsonを再度読み取る必要があることは、私にはまだあまりきれいではないようです。

@Tribexなぜpackage.jsonが2回読み取られると思いますか？

• ランタイム情報を.electronファイルに入れると、ランタイムはすべてが正しいと仮定してpackage.jsonを使用してアプリを起動し、正しくない場合はフェイルファストします。
• ランタイムをpackage.jsonに直接、またはelectronセクションの下に置くと、1回の読み取りのみが必要になります。 このように、 .electronファイル（アイデア？）に何を入れるべきかわからないので、空でも問題ありません。

@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"
  ]
}

または、すべてをpackage.jsonに入れると、アプリを開くために使用する.jsonへの.electronのみのリンクを持つことができます。

_ app.electron _

{
  "package": "package.json"
}

また

_ myapp.electron _

{
  "package": "electron.json"
}

また、同じディレクトリに2つのランチャー（1つはクライアント用、もう1つはサーバー用）を配置し、クライアントがサーバーのファイルを使用して1人のプレーヤーのみでローカルサーバーを起動する場合もあります。 このように、99％のファイルすべて（500 MB以上のファイルを使用するゲームがあると仮定）と5〜6個のファイルを複製し、それらを2つの別々のディレクトリに配置する必要はありませんが、1つ余分に追加するだけです。独自にサーバーを起動できるようにするファイル。 文字通り、同じディレクトリに複数の実行可能ファイルがあるのと同じです。

構文を正しく判別するために、エディターとIDEのために、個別のpackage.electronにpackage.electron.jsonまたは拡張子.jsonの名前を付ける必要があります。

@StreetStrider私はむしろIDEに.electronが実際に有効な.jsonであることを教えたいと思います。
また、これにより、 @ sapioitと.jsonの関連付けについて話し合ったことがわかります。 人気のあるOSは二重拡張機能の関連付けをサポートしていないと思います。 （ .foo.bar ）

編集時に.json拡張子を追加することができます。 または、右クリックしてエディターで開きますが、Adobe Airと同様に、デフォルトではランチャーでファイルを開き、ユーザーがエディターでファイルを開くことができるため、問題は発生しません。

@sapioitフェアポイント、package.jsonを指すことについてはあなたに同意すると思います。

私にとって、ランタイムとプレーヤーは2つの別個のものです。 これは今、プレイヤーとしてより多くのことをやってのけています。 そして、パッケージマネージャーの概念に慣れている技術的に傾倒したコミュニティの外で広く使用されることはないようです。

当面の問題は、ランタイムを作成することです。 JREや.Netのようなものです。 プレイヤーではありません。

@baconfaceおそらくあなたは詳しく説明できますか？ ここで何を区別しているのかは不明です。

@baconfaceええ、でもJREと.Netの両方をインストールすることもできます。
JREがないと、 .jarファイルはelectronランタイムのないパッケージと同じくらい役に立たなくなります。

理想的には、このツールは、電子をインストールする主要な方法と一緒に、または電子をインストールする主要な方法として配布され、理想的には拡散の問題を軽減します。

このために必要なのは、特定のファイルを起動する実行可能ファイル、つまり.electronを入力するための小さなツールだけです。 そのような単純な。

.leptはすごいですね、ありがとう！

個人的には、新しい構成を発明する必要はないと思います。 pkg.enginesは、ここでは非常に簡単に見えます（ただし、 npmのドキュメントの1.x || >=2.5.0 || 5.0.0 - 7.2.3のように、複雑なsemver式を使用できるはずなので、 { recommended, compatible, etc } @ sapioitの例のような構造だと思います）。 （ただし、 leptonフィールドを追加しました。これは、 scripts.runは通常npm startによって呼び出され、レプトンは独自の$VARIABLESを追加することでそのセマンティクスをいくらか壊すためです。 。）

または、すべてをpackage.jsonに入れると、アプリを開くために使用する.jsonへの.electronのみのリンクを持つことができます。

私にも素晴らしいアイデアは好きではないようです。 複数のエントリポイントを持つパッケージがある場合でも、現在scriptsマップがあるように、それらすべてを1つのpackage.jsonに含めることができます。 私はそのようなことを考えています：

// 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では単純なシェルスクリプト（＃！shebangを含む3行）を使用でき、Windowsでは...まあ...¯_（ツ）_ /¯

まず、この記事をご覧ください。これは、semverのより優れた代替手段でありながら、そこにあるほとんどすべてのものと互換性があります。 Release.Breaking.Feature.Fixまたはセマンティックバージョンを明示的バージョニングに置き換える必要がある理由出来るだけ早く

第二に、問題は実際にそれらをどのように区別するかです。 つまり、 server.jsがすでに--debug引数を受け入れているのなら、なぜそれを気にせず、人々が独自のファイル構成を持つことを許可しないのですか。 クライアントが2.2-2.4で動作し、サーバーが1.4-1.9.2.1でのみ動作するなど、サーバーにはクライアントとは異なる構成が必要な場合があります...
あなたが推測したようにやって、私たちはもっと制限されるでしょう。

また、 --debugだけでなく、より多くの変数を使用するのはどうですか？ それのようなより多くの変数でそれをどのように実行するつもりですか？ それをしても安全ですか？ 結局のところ、1つのファイルでそれを実行したい場合は、別々のファイルを使用することもできますが、この方法では、パラメーターを使用して.leptファイルを実行した場合に発生する可能性のある結果が台無しになります。

デバッグパラメータを使用してサーバーを実行したい場合は、 --debug引数を指定して.leptを起動するだけではないでしょうか。 または、別のファイルを作成して、 --debug引数を使用してそのファイルを起動することもできます。 そんなに簡単じゃないですか？
私は理にかなっていると思います...

まず、semverのより良い代替手段を提供するこの記事をご覧ください。

これは素晴らしいアイデアだと思います！ ただし、Electronがこのバージョン管理スキームに切り替えることはないと思います。 また、エンドユーザー製品には最適ですが、ライブラリやエンジン、ランタイムなどには実際には必要ないと思います。 理想的には、ユーザーは実行しているElectronのバージョンを知らないようにする必要があります（必要な場合を除く）。

たぶん、サーバーはクライアントとは異なる構成を必要とします

これは問題になる可能性がありますが、ランタイムの複数のバージョンを必要とするプロジェクトを想像することはできません。

デバッグパラメータを使用してサーバーを実行したい場合は、-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

このdual-configpackage.jsonは、サーバーがa）クライアントと多くのコードベースを共有し、b）エンドユーザーが実行することを目的としている場合に最適です。 それ以外の場合は、すべてを2つのリポジトリ/パッケージに分割し、それぞれに独自のpackage.jsonを設定するのが理にかなっています。

これはElectron用ではなく、作成するプロジェクト用です。 Electronは、おそらく、セマンティックバージョニングから派生した独自のシステムを持っており、ニーズに合わせて変更する可能性は低いですが、レプトンやその他のプロジェクトでは、 _ development hell _、セマンティックバージョン管理を完全にスキップすることをお勧めします。

デバッグパラメータを使用してサーバーを実行したい場合は、-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の必要性も削除できます。

しかし、私たちが同意できることの1つは、ユーザーがサポートを受けている安定したバージョンを使用したいということです。 だから私は「リリース」を自分の番号にしました。人々は多くの番号を覚えている可能性が低いのですが、通常は最初の番号を覚えています。

@sapioit "Release"フィールドがエンドユーザー用の場合、他のフィールドは何のためにありますか？ エンドユーザーにとって、これはまったく問題ではありません。新しいバージョンが利用可能で、ランタイムを更新する必要がある場合（package.jsonのバンプを介して）、ランタイムも更新する必要があります。

ここに問題があります：

1. ユーザーは、サポートが提供されているバージョンを知りたいと考えています。
2. 彼らは多くの_役に立たない数字_を覚えたくないので、バージョンを覚えることを選択した場合、バージョン1.7 13を覚えている可能性が高くなります（たとえば）。
3. Thunderbolt互換性が追加されたため、グラフィックカードがランダムに排出されるため（ユーザー/ケースに応じて）、 nVidiaドライバーのかなりの部分が更新されないなど、特定のことが発生するまで更新したくない人もいます。 、コンピュータを起動した後、ゲームを開いた後、またはゲームをプレイしてから数分後）。 これは、ユーザーが最新バージョンの製品を使用できない理由の良い例です（ただし、KMPlayerの広告やlocked on自動更新など、他にも多くの理由があります）。 これにより、変更ログから複雑さを取り除くことで、変更ログを簡単に確認できます。

これらは理由のほんの一部です...あなたがより詳細に入ることができれば、私はまたより多くの詳細に行き、それらの選択がなされた理由をよりよく説明することができます。

@sapioit >= 12.1のようなsemver範囲は、サポートを宣言するのに十分な柔軟性がありませんか？
利用可能なランタイムの新しいバージョンがあり、それがバージョン範囲を満たしている場合、アプリの次回の起動はすべて、可能な限り最新のランタイムを使用する必要があります。

彼らはすべきですか？ しかし、技術的な制限（KMPlayerの広告やnVidiaドライバーの場合など）のために、そうしないと決めた場合はどうなりますか？

@sapioit次に、実行時の範囲を正しく指定したことを確認してください

@sapioit @YurySolovyovこの議論はここに関連していますか？ ランタイムマネージャは、electronが使用しているバージョン管理システムに従わなければなりません。 電子が使用すべきバージョン管理システムについての議論は、別の問題に属していると思います。

@Tribexやや。 私は、すでに基本的に解決されていることを過度に複雑にすべきではないと言いたかったのです。 しかし、私は、ランタイムマネージャがこの点で可能な限り単純なことを行うべきであることに同意します。

@yurysolovyovでは、プレーヤーが必要とするだけのバージョン番号のセクションを単純に許可しないのはなぜですか？

@sapioit

これはElectron用ではなく、作成するプロジェクト用です。

Leptonには（まだ）バージョン管理スキームが割り当てられておらず、パッケージ（アプリ）は任意のバージョン管理スキームを使用できます。 これを処理する必要があります（たとえば、Lepton自体を介したアプリの更新をサポートする場合）。

ランタイムは、製品ではないため、理想的にはsemverを使用する必要がありますが、現在は3つの数値のバージョン管理がサポートされています（ただし、開発者は範囲の指定に注意する必要があります）。 （明示的なバージョン管理の提案のように）3つを超える数値をサポートする必要がある場合は、パーサーを拡張する必要があります（Pythonの場合、 k-bx / python-semverまたはpodhmo / python-semverをフォークすることをお勧めします—前者は最近更新されましたが、前者はnode-semver APIに厳密に従い、現在使用しているものです）。

nodejsプロジェクト用にPythonでランタイムパッケージマネージャーを作成するのは悪い考えだと言ってもいいですか。
やめましょう。 それが何と呼ばれるか、レプトン、または何でも。 ノードに書き込むか、他のものを使用してみましょう。 そして、よく考えられたセマンティックバージョニングスキームよりもあなたがよく知っていると思う方法についての不必要なメールでこの問題をスパムしないようにしましょう

@championswimmerエレクトロンのバージョンがパッケージ化されたランタイムマネージャーと、他のバージョンがダウンロードされていることを示すUIを構築するのは興味深いことです。

@championswimmer iamale / leptonは、一種の使い捨てリファレンス実装です。このスレッドの周りに浮かぶさまざまなアイデアをテストするために、それ以上のものはありません。

@iamale混乱を避けるために、readmeでそれを述べる必要がありますか？

@YurySolovyov完了！

実際の実装に関しては、2つのオプションがあります。node.jsを使用するか、C / ++やGoなどのコンパイル言語を使用します。 また、ノードの場合、node.jsをバンドルする必要があります（または、ダウンロードした電子インスタンスの1つで実行するだけですか？ただし、正常な電子バージョンで実行されるようにする必要があります）。

@iamaleそうではありませんが、デフォルトでインストールされているバージョンを実行する必要があります。 その後、アップデートにより、インプレースで新しいバージョンに切り替えることができます。

必要に応じてすべてを更新できるため、特定のバージョンを使用することを選択します...

レプトンは画像形式になっているので、それほど素晴らしい名前ではないかもしれません。

それで...私たちは今それを何と呼びますか？ Hadron ？

クォーク？ 誰かが「ミューオン」という名前を付けたい場合は、プロジェクトの1つに名前を変更できます。

ここでは、名前を付けることが実際に最も重要でない部分ではありませんか？
インストール/更新/実行時のセマンティクスに同意しましたか？

なぜelectronだけではないのですか...

Op 157月。 2016 om 13:22 heeft Joshua [email protected] het volgende geschreven：

クォーク？ 誰かが「ミューオン」という名前を付けたい場合は、プロジェクトの1つに名前を変更できます。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

@yurisolovyov私たちは同意したと思います...多かれ少なかれ。
@ job-vそれは私がずっと提案してきたことです。 一つ選んでそれを使い続けましょう。

@zcbenzはこのスレッドを観察していますか？
もしそうなら、ここでいくつかの方向性を得るためにこれがどのように機能するかについてのビジョンを持っているといいでしょう。

やあ
この電子ランタイムに関する更新はありますか？
@zcbenzについてのすべての議論についてどう思いますか：

• 電子バージョンの選択
• 適切なバージョンをインストールする
• win、linux、macで動作するように準備します
• それを使って構築するためにどのツールを使用しますか（python、node、go、c ++）？
  @ YurySolovyov @ sapioit素晴らしいアイデアをありがとう
  @iamaleは、Debianベースのdestros'ubuntu ... 'のソリューションワークです。

@ 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

@iamale私はelectronをdebパッケージとして作成し、それをアプリケーションの依存関係として使用して、手動で、または多くのelectronバージョンのdebパッケージの中央リポジトリからインストールすると思います。
インストール後にこのパッケージを使用して、ユーザーアプリケーションを実行します

誰かがこれのために何かに取り組み始めたら、多分ここにそれにリンクしてください...

@sapioit Linux（APT / RPM）ソリューションの開発を始めました。 .asarをアップロードすると、パッケージに変換されてリポジトリに追加される単純なサービス。 WindowsとmacOSにも拡張可能である必要がありますが、現時点ではその約束はありません。

@iamaleかっこいい！ Windowsで動作するようになったら教えてください。

Linux用のFlatpakランタイムを作成するのはどうですか？ このようにして、ランタイムを複数のアプリ間で共有でき、サンドボックス化も可能になります。

Flatpakがsystemdへの依存を取り除くことで、おそらくLinuxでアップストリームパッケージングのためにユニバーサルになるでしょう。

ランタイムは複数のアプリ間で共有できます

Flatpakでは不可能だと思いましたか？..

@iamale Flatpakは、ランタイムを共有するように設計されています。アプリ開発者はランタイムを選択し、そのランタイム用のSDKをインストールしてから、 flatpak-builderなどでアプリを構築します。 次に、ユーザーがアプリをインストールすると、Flatpakは関連するランタイムをインストールします。

@ moosingin3space説明ありがとうございます！ その時は間違いなく検討する価値があります。

Flatpakについて私が気に入っているもう1つの点は、ユーザーがランタイム開発者とアプリ開発者によって実行されるリポジトリを（透過的に）追加するユースケースを中心に設計されていることです。これにより、更新が自動的に行われます。

問題であることがわかるのはセキュリティだけです。サンドボックスを安全に終了できるように、Flatpakの「ポータル」インターフェイスを使用するようにシステムライブラリを変更する必要があります。

ここでFlatpakに関する作業が行われているようです： https ：//github.com/endlessm/electron-installer-flatpak

ちなみに、FlatpakはOSTreeプロジェクトに基づいており、ファイルシステムツリーのコンテンツアドレス指定を行います。 これは、同一のチェックサムを持つファイルがディスク上で自動的に重複排除され、更新が静的デルタを使用して実行されることを意味します。 つまり、Electronは、アプリケーション間で個別に更新および共有できる共有ランタイムを提供できるだけでなく、同一ファイル上に構築されたアプリケーションがそれらをディスク上で自動的に共有し、アプリケーションやランタイムがインストールされると、更新が行われることを意味します。完全なダウンロードは必要ありません。

これが少しナイーブであるかどうかを許してください。ランタイム環境の自然な論理的進行としてデスクトップ環境を構築する可能性が考慮されているかどうか疑問に思います。 レンダラーの新しいインスタンスを生成するか、場合によってはそれを再利用して、他の電子アプリを起動する機能を備えた起動アプリ（たとえば、アトムではなく）が存在するという考えです。アプリは新しいタブで開きます。

私の理解では、OSのようにChromeはまさにこれのようです（ただし、Webアプリに限定されています）。 Linux上でランタイム環境としてelectronを使用して（chromeAPIの制限とは対照的に）nodejsを介して完全なfsアクセスを備えたデスクトップアプリを持つこと（またはWindowsの最初のexplorer.exeを置き換えるか、少なくとも拡張することさえ）は非常にエキサイティングな私見です。 これは、実質的にランタイムであるものをロードし、次にブラウザーエンジンをロードしてからアプリをホストする、ChromeOSよりもクリーンなソリューションだと思います。ここでは、ランタイムに直接アプリをロードし、ブラウザー自体は単なる別のアプリになります（多くの革新的な電子ブラウザプロジェクトが実際に出回っています）。

繰り返しになりますが、これが検討されているのか、それともすでにこれを行っているプロジェクトがあるのか​​疑問に思います。 そうでない場合は、おそらく妖精がGithubの経営陣の耳に一言言って主導権を握ることができますか????

PS：ここで私が提案していないことの1つは、OS.js（それ自体はかわいい小さなプロジェクトです）をelectronに移植することですが、electronアプリの環境を作成することです（OS.jsからのコードの再利用を嫌うことはありませんが）。
PPS：十分に価値があると見なされる場合、またはランタイム環境の問題の邪魔になる場合は、別の問題を作成します。

組み込みのランタイム環境がElectronアプリをはるかに良くするだろうと私は思います。 それらをパックするには、ファイルを圧縮して拡張子をasarに変更するだけでよいと思いますが、そのアーカイブには2つのフォルダーが必要です。1つはasarと呼ばれ、デフォルトのランタイムフォルダーのコンテンツが含まれています。デフォルトの設定を上書きするファイルでenviromentと呼ばれます。

たとえば、新しいアプリを実行すると、必要なバージョンのElectronがtempフォルダーにコピーされ、ランタイム（ asarフォルダーのコンテンツ）がデフォルトのファイルの場所に移動され、オプションのenviromentフォルダーが移動されます。 （3つのサブフォルダー、 windows 、 linux 、 macosx ）には、デフォルトフォルダーに貼り付けられ、その内容が上書きされるファイルが含まれている必要があります。

このように、アプリまたはアプリの.asar拡張子を評価するための何かが必要なだけで、そのアプリにダウンロードされたバージョンのElectron（アーカイブ）のあるフォルダーにアクセスさせ、それらを一時フォルダーにコピー（抽出）します、および.asarの内容を使用して必要なものを変更し、その一時フォルダーからElectronインスタンスを実行し、一時フォルダーを強制的に削除するために終了するのを待ちます。 手始めに、サポートされているすべてのオペレーティングシステムでカスタム拡張機能を備えたアーカイブで動作するようにデフォルト構成を取得するだけでも、私たちがすでに持っているよりも飛躍的に進歩します。 その後、デフォルトの構成設定用に、現在の構成設定を保持する3番目のフォルダーconfigと、その中に_configフォルダーがあることを心配できます（必要な場合） ）。

Chromeパッケージのアプリは間もなく段階的に廃止されるため、人々は代替アプリを探しています。 ランタイムは、ビルド/リリースが常に利用可能になるとは限らないマイナープロジェクトに最適です。 アプリはChromeアプリと同じようにウェブ技術で作成されているため、ユーザーがソースからアプリを実行するだけでよい場合があります。 ユーザーが実行できる唯一の方法が個々のスクリプトまたはアプリごとに大きなバイナリリリースをダウンロードすることであり、ユーザーが最新のコミットをビルドまたはダウンロードせずに実行することを利用できない場合、無数のマイナープロジェクトをElectronに移植することを正当化することはできません。 IDE自体。

みなさん、こんにちは。私はJS中心の世界にいなくても、最近_Electron_（たまたま知っていましたが、開発には使用していません）と非常によく似たアイデアを思いつきましたが、より多くの聴衆がいます。 非常に簡単に言えば、_ WebテクノロジーをGUIに限定し、APIを提供するだけです。_

したがって、セマンティックバージョンの共有ライブラリ/ランタイム（_Blink _、_ Skia_などの上に構築されています。おそらく– "modern" – _C ++ _）を使い続け、開発者がバインディングを使用して言語を選択できるようにします…
たとえば、_JS_が必要な場合は、_Node.JS_を使用します。 _C ++ _が必要です、問題ありません。 _Python_が必要ですが、標準の_CPython_が可能である必要があります。 他に何か ？ 多分_SWIG_が役立つでしょう。 （ほとんど）いずれの場合でも、私たちは勝ちます。

共有（OS依存）ライブラリ/ランタイムができたら、主要な問題を解決し、残りを提供するのが最善だと思う方法で詳しく説明できます（残りの部分のGUIプログラミングアプローチに革命/近代化する以外）。大きな前進です！）。

したがって、開始点は、_Electron_プロジェクトの「分割」（物理に関連する名前である必要があります）である必要があります…:)

Electronのアドオンを完成させることすらできませんが、多くの広告がなければ、それほど成功しないと思います。

@dezzeusこの行には努力があり、その前に失敗しました。 ブリーチブラウザをホストすることを目的としたスラストランタイムを見てください。

この方向にもっと勢いをつけたいので、私はこの長くて魅力的なスレッドを2回読みました。 これが@zcbenzによる最後の声明です、私はまだ関連があると信じています：

これを実装する上で技術的な障害はありません。すべてがElectronアプリ自体である可能性があります。 しかし、問題はどちらも実装するのが簡単ではないということです。すべての詳細を考慮に入れると、_小さなチームがフルタイムで作業する必要がある_と思います。それが起こるかどうかはわかりません。

（強調を追加）-これをどのように解釈すると、ソリューションが構築される場合、それはコミュニティの取り組みやGitHubやその他の組織のビジネスニーズに依存します。

@ yan-fotoによる簡潔な概要は、明確な目標/要件を備えた、賢明なアプローチ計画のように見えます。 @iamaleによるleptonと呼ばれるリファレンス実装/プロトタイプがあり、Electronを対象とした「ユニバーサルランタイムバージョンマネージャー」を提案しています。 @jorangreefによるコメントは、差分更新、重複排除（これら2つが同じかどうかは不明）、および圧縮を備えた「semver自動更新メカニズムを備えた本番環境のアプリ」について説明しているため、興味をそそられました。 彼が説明した機能の多くは、適応/採用に最適のようでした。

これらは探求と進歩の明確なステップであり、このプロセスから生産に値する一般的なソリューションが生まれることを期待しています。

人類を信じる人々がまだいるのを見るのはうれしいです。

これが製品にならないようにする唯一のことは、この製品の製造によって開かれる即時のビジネスチャンスの欠如です（コンセプト）。

@ eliot-akiraはい、そうです。 私が書いたコードは、ファイル内の数バイトだけが変更された場合のダウンロードを最小限に抑えるために、ファイル内のファイルごとのコンテンツベースの重複排除（可変サイズのチャンク）を実行します。 また、バージョン間で変更されるファイルのみを更新し、アプリケーション全体の更新は、エラーが発生した場合にアトミックです。 新しいバージョンが起動するか、古いバージョンがそのまま残ります。

コードをオープンソースにしたいと思いますが、全体的なアイデアのためにまだコーディングする必要があることがいくつかあります。 複数のElectronアプリが単一の自動アップデータースーパーバイザープロセスを共有できれば素晴らしいと思います（複数の独立したElectronアプリ間で重複排除するためのローカル共有不変キャッシュを使用）。

このアプローチ全体の目標は、Electronアプリを相互に完全に分離したまま、Electronアプリのインストールと更新に必要な全体的なダウンロード帯域幅を最小限に抑えることです（複数のアプリには独自のElectronバイナリがあります）。 目標ではないのは、ディスクのフットプリントを最小限に抑えることです。

最初のElectronアプリのインストールは完全にダウンロードする必要がありますが、その後のElectronアプリのインストールは、ローカルの共有不変キャッシュの恩恵を受けます。

自動更新になるので、バージョン管理の問題を持ち込む必要があります。また、複数のバージョン管理システムがバージョン管理に異なる桁数を使用しているように見えるという事実もあります。 私は、たとえば、明示的なバージョン管理を使用しています。

ここで更新する必要があるものは2種類あります。

• 電子バージョン管理を使用する電子自体と
• アプリには、通常APIがないため、SemVerなどを気にする必要はありません（何らかのアドオンシステムを利用している場合を除く）。

複数のバージョニングシステムをサポートする必要がある場合でも、semverの"breakingVersionComponents": 1や明示的バージョニングまたはElectronバージョニングの2など、 package.jsonに設定を設定できますか？

（別のオプションは、バージョンに別の区切り文字を追加することです。たとえば、 1.3:3.7は、壊れている部分と壊れていない部分を分離します。Semverはx:y.zになり、Electron Versioning x.y:zなります。ただし、すべてのツールを壊してください。）

@jorangreefすべてのアプリがまだ独自のElectronバイナリを持っている場合、複数のElectronアプリを開いているときにRAMが過剰に使用されるという問題は修正されません。

@ 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 、レプトンでの作業に感謝します。私の目には、これは解決策の方向への具体的な実装です。

別のアイデア：アプリをnpmで公開し、それらをインストールして実行できる特別なnpmラッパーを作成するだけです。 その場合、デプロイは非常に簡単で、おそらく使用も簡単です（ただし、ラッパーの品質によって異なります）。 みんなどう思いますか？

ossプロジェクトの場合、ホスティングとしてnpmを使用できます。クローズドソースのプロジェクトの場合、パッケージマネージャーがダウンロードする.asarファイルと、場合によってはさらにいくつかのメタデータを指定できる必要があります。 問題は、この親切なマネージャーがどのように見えるか（そして呼ばれるか）です

また、アプリをインストールするために別のコマンドが本当に必要なのだろうか、たぶん
electron install atomで十分ですか？

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

@YurySolovyovクローズドソースプロジェクトは、npmでの公開にも問題はありません。Node.jsプロジェクトはすでにいくつかあります。つまり、 encloseです。 （技術的には、npmにはなく、単なるローダーですが、.asarをサイドローディングすることで、まだ解凍できるため、どのように役立つかわかりません。）

どうすれば既存の生態系を可能な限り再利用できるかを考えようとしていました。

したいのかわからない...

@jorangreefすべてのアプリがまだ独自のElectronバイナリを持っている場合、複数のElectronアプリを開いているときにRAMが過剰に使用されるという問題は修正されません。

@ Jop-Vいいえ、そうではありません。 私は物事を混同してモンスターになってしまうことを望んでいません。 アイデアは、この問題を開いたコメントの問題のほとんどを解決する優れたインストーラー/自動アップデーターを持つことです： https ：//github.com/electron/electron/issues/673#issue -44580957

問題は、ディスク上に複数のバイナリがあることではありませんが、同じバイナリの複数のコピーをダウンロードして自動更新する必要があるユーザーに対するネットワークの影響です。

ただし、メモリ使用量を解決することは間違いなく価値があります。 これを行うにはさまざまな方法があると思いますが、必ずしも重複排除インストーラー/自動アップデーターにバンドルする必要はありません。

ディスクフットプリントも問題である場合、それをサポートするシステムのハードリンクを介して対処できますが、アプリ間の分離の概念を侵害し始めます（たとえば、あるアプリが他のアプリと共有されているハードリンクに書き込むことを決定した場合）。

あるいは、少なくとも中期的にはmacOSでは、APFSは参照によってファイルをコピーし、内部で透過的な重複排除を行い、ディスクのフットプリントを最小限に抑えます。 これは、分離をそのまま維持するため、ハードリンクよりも優れています（コピーオンライト）。

@jorangreefアプリに個別のElectronバイナリを使用する意味は何ですか？ どんな孤立について話しているのですか？ それがばかげた質問なら申し訳ありませんが、私はそれを理解していません。

@iamale一部のアプリは、Electronのさまざまな公式バージョンを対象にしている場合や、変更されたソースからコンパイルされたビルド済みのElectronを配布している場合があります。 このアプローチは、それらすべてで機能します。 （JSやアセットの変更とは対照的に）バイナリに大きな違いがある場合でも、重複排除によりダウンロード要件の70％以上が排除されるため、異なるバイナリを対象とするアプリにはメリットがあります。

このアプローチでは、必ずしもElectronアプリだけでなく、あらゆる種類のパッケージ（JSONマニフェストによって定義されたファイルとディレクトリのセット）を出荷することも可能です。 Pythonアプリかもしれません。 開発者がアプリの構造やパッケージ化の方法（ファイルとasarなど）に対してどのような選択をしたいかは関係ありません。

主なアイデアは、同じインストーラー/自動アップデーターを使用するアプリが増えるにつれて、エコシステムは非常に小さなインストール/更新デルタの恩恵を受けるということです。 最近では、すべてのアプリが独自の監視自動アップデーターを実行しており、それは不要です。

@jorangreefありがとうございます！ 従来のAPT / RPMリポジトリによく似ていると思いますが、より「スマート」です（依存関係などを宣言する必要はありません）。

問題は、この親切なマネージャーがどのように見えるか（そして呼ばれるか）です

Minifitron （縮小された電子）はどうですか？

アーカイブファイル（つまり.asar ）には、electronのバイナリが存在するフォルダの内容が含まれていると思います。そのため、標準から逸脱したファイルを追加または置換できます。 各バージョンをフォルダまたはアーカイブに保存し、実行中は新しい一時フォルダにコピーします。

また、アプリをインストールまたは縮小するオプションがあるはずです。インストールすると、アプリは新しい電子インスタンスとして残りますが、縮小化されたアプリはmd5を使用して、 .asarのアーカイブ解除によって変更されていないファイルを削除します。

別のアイデアを投げかけるだけです。各Electronアプリにランタイムの独自のコピーが含まれていても、起動時に、Electron（およびそのバージョン）の実行中のインスタンスがあるかどうかを確認できます-互換性があるかどうか（semverの範囲内）など）、アプリはそれと通信し、同じインスタンスを使用できます。 互換性がない場合、アプリは独自のElectronインスタンスを起動できます。 これは、メモリーフットプリントの削減の問題に対処しているように思われます。

（その後、アプリが起動するまでに、とにかくランタイムの複数のインスタンスがすでに存在することになると思います。したがって、論理的ではない可能性があります。）

@ eliot-akiraこのスレッドを読んでいる間、非常によく似た考えを持っていました。

（その後、アプリが起動するまでに、とにかくランタイムの複数のインスタンスがすでに存在することになると思います。したがって、論理的ではない可能性があります。）

さて、これをチェックするのに十分なだけロードすることができ、ランタイムを共有するために利用可能な「エレクトロンメイト」がないことを確認した後、残りをロードします。

ただし、これにより多くのセキュリティ上の懸念が生じます。 邪悪なアプリは、ランタイムの変更バージョンを他の人に提供し、そのデータにアクセスする可能性があります。 共有メモリセグメントを使用して読み取り専用にし、「ユーザー」アプリ（以前に起動したアプリのランタイムを使用する）がランタイムをチェックサムする可能性がありますが、対象となるすべてのOS用にこれらを開発することは悪夢かもしれません（これがWindowsに存在するかどうかさえわかりませんが、存在する必要があると思います）。

好奇心のためだけなら、これは無意味ですか？ 個別の共有ランタイムと同じくらいの作業になるのでしょうか、それともはるかに多くの作業になるのでしょうか。 それは他の追加の問題を引き起こしますか？

後で追加：これは遠い話かもしれませんが、RAM上の同一のページを重複排除するテクノロジーが存在します。 これらは主に仮想化環境とハイパーバイザーで使用されます。 これは私が最初に考えて実行したもので、今日のOSがこれを使用しているかどうかを確認しました。次に、この機能を利用できるように電子を設定する方法があるかもしれませんが、明らかにそうではありません。

@jorangreef開発者がElectronバイナリを変更した場合、プルリクエストを作成するだけではいけませんか？

@ Jop-Vできますが、独自のフォークを維持することもできます。 彼らが望まない場合、彼らは情報源を公開しないかもしれません—MITライセンスは彼らに義務を負わせません。

@jkureiアイデアをさらに探求するために、私はうまくいくかもしれないいくつかの方法を想像します：

1）Electronまたはアプリ自体の薄いネイティブラッパー。これが「ランチャー」になります。 Electronのすでに実行されているインスタンスとそのバージョンをチェックします。互換性がある場合は、残りの起動プロセスをそのインスタンスに渡して終了します。 そうでない場合は、Electronの独自のインスタンスを起動し続けます。

2）アプリ自体がランチャーとしてメインプロセスにインポートできるJavaScriptライブラリ。 上記と同様のプロトコルを実装できます。Electronインスタンスの存在をブロードキャストし、他のアプリ（同じライブラリを使用）がそれを見つけて通信する方法（おそらくネットワークポート経由）。

@ eliot-akiraちなみに、あなたが話している原始的な「プロトコル」はすでにあると思います。 app.makeSingleInstanceの背後にあるのは、すでに実行中のElectronプロセスを何らかの形で検出し、それらが同じアプリであるかどうかを検出することです（おそらく、完全な実行可能パスを取得することによって）。

@iamaleなるほど、このメソッドはChromiumのネイティブProcessSingletonクラスを使用して、現在のアプリディレクトリを（一意の識別子として？）登録します。 はい、 app.on('ready')の前に初期化されるこのようなものを描いていました。 そのため、その特定のアプリの既存のインスタンスをチェックするだけでなく、Electronのインスタンスをチェックし、互換性がある場合は「起動プロセスを引き渡す」ことができます。

別の角度から、別々のNode.jsプロセス間で通信できるnode-ipcというモジュールを見つけました。 たぶん、それは純粋にJSレイヤーで起動プロセスを管理するために使用できます。

プロセス間通信にnode-ipcを使用して、複数のアプリ間で単一のElectronインスタンスを共有する基本的な例を次に示します： https：//github.com/eliot-akira/singletron-example。

IPCハブは独自のモジュールであり、 node-ipcを囲む薄いラッパーです。 その初期化はメインプロセスにあり、下部にmain.jsがあります。

起動すると、アプリは最初に既存のElectronインスタンスへの接続を試みます。 存在しない場合は、プロセス間要求をリッスンする「サーバー」を起動します。 アプリの後続のインスタンスはすべて最初のインスタンスに接続し、その「構成」（Chrome、Node、Electronのバージョン）を受信し、メッセージを交換して、たとえば、それ自体の新しいウィンドウを要求することができます。

最初は単純な実装ですが、このアプローチで私が気に入っているのは、サーバー/クライアントがどのようにネゴシエートするか（互換性の確認、新しいウィンドウを開くかどうか、他の構成を渡すかどうかなど）を処理するのはアプリ次第です。

@ eliot-akira現時点では、デフォルトのサーバーIDを指定することは_本当に-本当に悪い_アイデアだと思います。誰かがこれを自分の目的で使い始めた場合、自分のニーズに合わせてサンプルコードを変更し、プロトコルを破る可能性があります（したがって、これに依存している他のアプリを壊します）。

それとは別に、きれいに見えます、ありがとう！

Re：セキュリティ上の懸念：Electronアプリはすでにユーザーの権限で実行されており、1つのプロセスツリーに配置すると、他のElectronインスタンスに実際にアクセスできるようになります。 ただし、それを軽減する場合は、パッチを適用したElectronインスタンスを提供できるすべての人が確実に役立つことはないと思います。

@iamaleフィードバックありがとうございます。 一部のアプリがすべてのElectronアプリに共通のプロトコルではなく、独自のプロトコルを実装したい場合に備えて、サーバーIDを設定するオプションを公開しました。 実際、そのような一般的なプロトコルはまだありません。したがって、現時点では、未知のアプリが接続して起動プロセスを引き渡すことは、その目的には実用的ではありません。 これは概念実証を目的としていたため、ドキュメントを更新してそのことを説明します。 私はそれをより実用的にする方法を探求し続けます。

半年前に誰かがやったのと同じように、新しく来る人々が再びある種の要約を持っていることは有益だと思います。

また、エンドユーザーは何をしますか？

私がエンドユーザーである場合（そして部分的に私はofcです）、portableapps.netインストーラーのように機能する単一の.exe / .app /.debパッケージが必要です。 そのexeファイルは小さく、インストールされていない場合は、ランタイムと一緒にソフトウェアの最新のアップストリームバージョンを自動的にダウンロードする必要があります。 簡単なセットアッププロセスで、システムリンク（デスクトップ、スタートメニューなど）を作成するためのチェックボックスと一緒に（詳細オプションのチェックボックスを使用して）「ランタイムの場所」を手動で設定できるはずです。

次のソフトウェアをダウンロードするとき、可能であれば前のランタイム（idcのように見えるものは何でも）を再利用する必要があります。

開発者として、私はそのようなダウンロード可能なパッケージを（せいぜい）ワンクリックで作成できるようにしたいと思っています。 このワンクリックで、コードをリポジトリ（play / web / appストアと同様）にアップロードし、世界と共有できる.exe / .app /.debパッケージを作成する必要があります。

私はまだElectronに関与していません。これは、ElectronとElectron-Edge for C＃を使用して小さなmodインストーラーを作成しているだけだからです。

私は素朴かもしれませんが、唯一の「本当の」理由であるafaikは、互換性がない+ -0.1バージョンであるため、Electronのバージョンごとに.nodeファイルを再構築する必要があります。 これらの.nodeファイルは、ある種のクラウドソリューションを使用してセットアップ中に構築できませんでしたか？

また、半年かそこらごとに1つの大きなElectron LTSを作成することは本当に大きな取引でしょうか？ 開発者が実際にすべての新しいElectronリリースの最先端の機能をすべて使用しているとは思えないので、（一種の）1つのバージョンを長く使用するように強制すると、作業が非常に簡単になります。

Imo、唯一の問題は、誰もが信頼できるLTSバージョンのElectronを用意していないことです。

そのltsバージョンでは、自動更新、重複排除、バージョン管理など、その他すべてのものを簡単に作成できます。

私が提案したインストーラーソリューションには、ユーザーがソフトウェアのフォルダーを実際に表示しないという追加の利点もあります。そのため、.whateverとしてパッケージ化して、安全な場所に移動するように指示する必要はありません。 また、インストール中に複数の「サブ実行可能ファイル」を追加することもできます（たとえば、マルチプレイヤーゲーム、複数の「プロファイル」など）。 これらの実行可能ファイルは、somelaunchername.electronと呼ばれる必要がありますが、ソフトウェアの起動方法に関する情報（ロードするindex.htmlなど）を含むJson形式です。 node_modulesは実行可能ファイル間で共有する必要があります（開発者が実行可能ファイルごとに異なるバージョンのモジュールを使用する必要がある場合を除く）。 これは、node_modulesフォルダーを3つ持つことで実現できます。 実行可能ファイルごとに1つ、両方に1つ。 package.jsonには、一般的な情報が含まれています。 各.electronファイルは（imo）package.jsonの値を上書きできる必要があります。

これらの.electronファイルは、「ru​​ntime --appname」またはsteamなどのカスタムプロトコルを使用して、スタートメニューやその他の場所に追加できます。 どちらが良いかはわかりませんが、蒸気の方が過去に何度も私を怒らせました。

これで、開発者が本当に変更されたランタイムを出荷したい場合でも、現在の方法でパッケージ化できます。

結論として：
私の意見では、次のステップは、安定したltsバージョンを作成し、開発者に簡単なパッケージソリューションを提供することで開発者を参加させることです。 インストールプロセスは後で改善される可能性があります。現在、これらの.electronファイルのランタイムとランチャーをダウンロードするだけで十分です。

皆さんはどう思いますか？

@CiriousJokerのelectron-builderは、ポータブルアプリとWebインストーラーを作成できます。 私が見る限り、Windowsでは共有DLLが解決策です。 共有DLLは、未使用の電子ランタイムを自動的に削除するための参照カウントもサポートしています。 現在、1つの大きな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 imo 、本当の問題はdllを共有する方法ではなく、ltsバージョンのelectronを取得する方法です。

Chromiumは古いバージョンのセキュリティ修正も行いますか？ 彼らの方針は「安全のために最新バージョンにアップグレードする」ことだと強く感じています。 Chromiumからのセキュリティ更新がなければ、ElectronのLTSは遠い道のりのようです。

@ sedwards2009しかし、本当に多くの脅威がありますか？ 確かに、私はここではナイーブかもしれませんが、オープンインターネットからではなく、（ほとんど）ローカルアプリからユーザーを保護しています。 私の合法的なelectronアプリのインストーラーでさえAVGによってウイルスと呼ばれた場合、.exeファイルの実行は10000倍危険であり、.exeウイルスの作成も10000倍簡単です。

だから私にとっては、6か月ごとにそのセキュリティを「更新」するだけで十分です。 また、すべての開発者が独自のパッケージバージョンのクロムを使用できるようにすることは、はるかに安全ではありません。とにかく、（共有ランタイムなどで）防ぐことのできない悪を行う可能性があります。

ええ、セキュリティはアプリがfsとネットワークへの生のアクセスを取得するところで終了します。
アプリのベンダーを信頼するか、近づかないでください。 <-これはクローズドソースアプリ用です。
OSSの場合は、それが優れています。ほとんどの場合、少なくとも悪い意図はありませんが、バグが含まれている可能性があります。

さて、ltsバージョンを入手するのはどれくらい簡単ですか？ 現在のバージョンを選択して、それをltsバージョンとして宣言することはできませんか？

より大きな問題は、開発者にこの特定のバージョン用のアプリを構築するように説得しようとしているときにおそらく発生しますが、それはとにかく最後のステップです。 共有ランタイムを構築するには、最初にランタイムを選択する必要があります

これは開発者の決定であると思います-どのランタイムバージョンのアプリが動作するべきかを理解することです。
npmエンジンフィールドのようなものです。
ここでのランタイムの仕事は、必要なdllなどをフェッチして、アプリを実行できるようにすることです。

しかし、互換性のないほぼ同じランタイムの数十の1つを選択できるようにすると、要点を完全に見逃してしまいますね。 重複排除だけでなく、複数のランタイムを使用しないようにしています。 誰かが最初にどこかで述べたように、同じランタイムが同じシステムで再び使用される可能性が20分の1の場合、ランタイムの重複排除はあまり意味がありません。

それとも、ランタイムのほとんどを共有し、必要に応じてさまざまな部分を切り替えるだけだということですか？ それは理にかなっていますが、実装するのは難しいと思います

ランタイムをどのように共有できるかわかりません。主なサイズのコンシューマーはChromiumとNodeであり、これらは緊密に統合されており、相互に複数のバージョンで動作させることができるとは思えません。

ノードには次のようなものがあったと思います。

• 一部の開発者は最新のv8を望んでおり、破損を許容しても問題ありませんでした
• 大企業は安定性と長期的なサポートを望んでいました。

電子チームが両方をサポートするのに十分なリソースを持っているかどうかはわかりませんが、間違っている可能性があります。
とにかく、これはバージョン管理範囲と競合しません。どのバージョンが「LTS」であるかを示す必要があります。

すべてのelectronアプリが同じランタイムを使用し、そのランタイム用に特別に構築された.asarパッケージが付属している場合、問題は解決しますね。

ええ、でもあなたはたまに新しいChromeとNodeが欲しいですよね？

ええ、でも私は同じノード/クロームを6か月間使用して生きることができました。 NodeにはとにかくLTSバージョンがあり、chromeは私が気付いたものからそれほど変わっていません。 Imo、アプリのインストールごとに100 MBを節約できるという利点は、Chromium / Electronの新しいバージョンがリリースされるたびに、わずかな速度の向上を補います。 また、開発者を参加させたら、ランタイムの新しいバージョン間の時間を短縮するのはそれほど難しいことではありません。 その後、ランタイムの最新バージョンと1つまたは2つの古いバージョンをサポートできます。

6か月ごとに.nodeファイルを再構築するのもそれほど難しいことではないはずです。

Electron-builderは、すべてのnsisターゲットの新しいオプションであるuseSharedElectronRuntimeをサポートします。 今のところ、既存のdllはすべてそうなるでしょう。exeのサイズを減らしてコードをdllに移動することは可能だと思いますが、後で行うこともできます。30Mbを節約することはすでに良い目標です。

1. すべてのelectrondllの署名付きアセンブリを作成し、GitHubリリースに公開します（信頼性が低いため、bintrayはオプションではありません）。
2. Nsisインストーラーは、まだインストールされていない場合、アセンブリをダウンロードしてインストールします。 セキュリティ—アセンブリは署名されています。 Electron-builderは、マシンごとのインストールもサポートしています。 また、Windowsは、マシンごとにアセンブリがインストールされている場合、追加レベルのセキュリティを提供するため、必要に応じて、それを有効にすることができます。 いずれの場合も、マシンごとにアセンブリをインストールするための追加オプションが追加されます。 まだ明確ではありません—デフォルトでtrueまたはfalseである必要があります。 デフォルトでelectronアプリを管理者なしでインストールできるようにするために、私は間違っていると思います。
3. 未使用の電子ランタイムについて心配する必要はありません—共有dllは参照カウントをサポートしています。 アプリをアンインストールすると、アセンブリは削除され、他のアプリがそれを使用しなくなった場合、Windowsはそれを削除します。

@CiriousJoker Re：セキュリティ。 アプリケーション自体が悪意のあるセキュリティの問題については考えていませんでした。 信頼できないコンテンツを吸い込んで使用する電子アプリを考えていました。 つまり、電子アプリが開いているWebのWebページをwebviewなどで表示するときはいつでも。

多くのアプリはオープンウェブに公開されておらず、古い電子で問題なく実行できます。 しかし、もう1つの極端な例は、Webブラウザーとしてそれ自体を公開する以外に何もしないBraveのようなものです。 :-)

@ sedwards2009はい、でも私たちがみんなとその母親の世話を始めたら、私たちは何の進歩もしません。 何もしない理由は常にあります。 開発者の100％を参加させないことは、私たちがしなければならない犠牲にすぎません。 本当にセキュリティが必要/必要な場合は、手動でセキュリティを設定できます。

LTSの選択に関して、最も賢明な選択は、Nodejs LTSに自分自身をバインドすることです。つまり、ノードLTSに対応する電子のバージョンは事実上電子LTSです。 これにより、ある程度の調和と合意がもたらされ、自由な選択（このコミュニティを否定する）や議論（私たちをどこにも導く）として残すのではなく、集合的に前進し、ある程度の確実性を得ることができます。

@CxResしかし、どのバージョンのElectronをサポートしていますか？ 私のプロジェクトでは、主な問題は、特定のバージョンのElectron（ノードではない）に対して.nodeファイルを再構築することでした。

最新のElectronバージョンをltsとして設定するか、最も広く使用されているバージョンを使用することができます。

ここで何かが足りませんか？ Imo、問題はノードではなく電子です

さて、これを例を挙げてもう一度説明してみましょう。

• ノードLTSは現在6.11.1にあります
• したがって、<= 6.11.1> = 6.0.0の条件を満たす、最高バージョンのノードで公式に構築された最高バージョンの電子を使用する必要があります。
• ノード6を使用して構築された電子の最高バージョンは、ノード6.5.0で構築された電子1.4.15です。
• つまり、electron 1.4.15は、electron LTSをフォークし、6.11.1で再構築する場所です（新しいNode v6リリースがリリースされるまで続きます）。

ノードLTSがv8に移行すると（LTSは偶数のみ）、まだリリースされていない電子に一緒に移行します。この電子は、ノードv8を使用して構築されるか、そのような電子バージョンがリリースされるまで現在のLTSフォークに残ります。

最新かつ最高のものを求める開発者はどうですか？

@ CxRes @ CiriousJokerここで話題から外れるのは避けましょう。 技術的な理由により、異なるバージョンのElectronの使用が妨げられることはありません。 いずれの場合も断片化が発生します（開発者が1年前にリリースしたアプリを忘れ、最近リリースされた別の開発者の他のアプリが別のバージョンを使用しています）。

@YurySolovyov LTSの全体的な考え方は、最新かつ最高ではなく、安定しているということです。 そして、1つのソリューションに集中することに同意できない場合、すべてのバージョンを再構築してバグをスクリーニングする時間と能力を持っているグループがないため、ランタイムがないというパレートの準最適性に苦しむ運命にあります。

上記の@CiriousJokerコメントも参照してください。

ええ、でも私たちがみんなとその母親の世話を始めたら、私たちは何の進歩もしません。

@develarわかりました。 しかし、これは技術的な問題ではないことを指摘するように、それは政治的なものです（ほとんどの人にとって、負担が分担されるように一貫して機能するビルドについて合意すること）。

今から何をする？ ltsバージョンを選択して開始するか、モジュラーdllを使用して万能のランタイムを構築することですべての人に役立つソリューションを見つけようとしますか（ @develarが正しく理解していれば提案します）

@CiriousJoker特定の電子バージョンのサイドバイサイドアセンブリ。 例： ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 。

@develar Googleでそのelectronruntineassemblyのものを見つけることができません、リンクまたはsmthを提供できますか？

Imo、物事をスピードアップするために、ltsバージョンとしてランダムなElectronバージョンを選択して開始する必要があります。 とにかく、後でいつでもバージョンを変更できます。
@develarサイドバイサイドアセンブリの意味はまだわかりませんが、クロスプラットフォームで動作する必要があり、後で実装することもできます。

私たち（または実際にはあなたたち）はこれについて何年も話してきましたが、誰も始めなければ何も変わらないでしょう。私たちはさらに3年間ここに座って、アイデアについて話し合い、始めない方法を見つけます。

電子開発者が実行環境とアプリケーションの分離をできるだけ早く解決し、電子アプリケーションを大いに促進することを願っています。明るい未来が見えます。

彼らは私には何年もの間それを解決しなかったので、私はそれについて少し悲観的です。 確かに、それは素晴らしいでしょうが、彼らはそれに積極的に取り組んでいますか？

@CiriousJoker上記のように、私はエレクトロンビルダーのウィンドウの共有エレクトロンランタイムサポートに取り組んでいます。 進捗状況を追跡するためにhttps://github.com/electron-userland/electron-builder/issues/1942を提出しました。 1ヶ月で使えるようになるといいですね。

@develar私の悪い、それを見落としていたに違いありません。その場合、あなたがそれを作ることができれば、幸運は素晴らしいでしょう！

https://github.com/electron/electron/issues/673#issuecomment -157980607のスレッドで前述したサブファイルcontent-defined-chunking重複排除に関心がある場合は、 https：//をオープンソース化しています。

この長いスレッドは過去数か月間休止していますが、それが対処する問題はまだ調査する価値があると思います。 週末に、ファイルの名前を一括変更するための小さな最小限の1ページのユーティリティを作成しました。 電子ビルダーが詰め込まれた、最終的なMac.appファイルは121mbです...

私は最近この問題について考えていました。 それから私は自分のスマートフォンを見ました：Facebookアプリは600MBの大きさです。 Chromeは325MB、Mesengerは300MBです...デスクトップ上の120MBアプリ、私はあまり気にしません...

サイズは今日問題ではありません。 RAMと消費電力はです。

_編集：同意しない場合は、理由をお気軽に共有してください_

Windowsプラットフォームの場合、 @ develarのelectron-builder（electron-userland / electronic-builder＃1942）の取り組みは、共有ランタイムの達成に近いように見えます。

また、WebアプリをスタンドアロンのElectronアプリとしてパッケージ化するアプリwebcatalogが、共有ランタイムの使用に関する問題を解決し、アプリのサイズを大幅に削減したことにも注目しました：webcatalog / webcatalog / issues / 171。 これは、アプリ間で共有リソースをシンボリックリンクすることにより、パッケージャーで行われました。

プログレッシブ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で書き直す必要があります。

@develarはこのアイデアについて何か進歩がありますか？

リリース時に使用します！

最近これに出くわしたので、自分の意見を投げ入れたかっただけです。しかし、私は問題全体を読んでいないので、無意識のうちにいくつかのことを繰り返すかもしれません。

Electronプログラムのサイズは今ではそれほど大したことではないように思われるかもしれませんが、非常に単純で小さなプログラム、たとえばカスタム計算機を配布すると、実際にそれがわかり始めるので、このようなものは非常に重要だと思います。 この場合、5〜10MBのようなものが妥当です。 60MB以上はばかげているでしょう。 より大きなプログラムの場合、Electron自体のサイズは無視できるようになりますが、それでも煩わしい場合があります。

ただし、このようなランタイムモードでは、現在のリリースレートを考慮して、ある種のLTSリリースシステムが必要になります。 その後、開発者はLTSリリースに依存するように促され、使用中の最も一般的なバージョンのリストがappsディレクトリに表示され、必要な機能が不足していない限り、最も一般的なバージョンを使用するように促されます。

ランタイムモード自体には、他のバージョンのElectronライブラリをインストールするためのシステムが組み込まれている必要があります。そのため、ユーザーが別のバージョンを必要とするアプリケーションのインストールを要求した場合、ランタイムプログラムはそれを単純なものとして自動的にダウンロードできます。インストールプロセス内のステップ。

ElectronアプリのRAM使用量もこれを利用して改善できる可能性があることにも注意する必要がありますが、それを有効にするために必要な変更ははるかに大きなものになります。 共有ランタイムを使用すると、同じバージョンを使用するElectronアプリは、メモリ内の一部のリソースを共有できます。

とにかく、私はとにかくElectronプロジェクトのソース全体に非常に慣れていないので、何か不明な点がある場合、または不必要に何かを繰り返した場合は申し訳ありません。 ただし、これが実装されることを本当に望んでいます。これにより、Electronは、さらに多くの種類のプログラムにとってはるかに有望なプラットフォームになります。 ：+1：

@octacian私はPWAがより良い選択肢だと思い始めています。 ただし、普遍的ではありません– PWAを使用して_すべて_を行うことはできません–しかし、カスタム計算機のようなものについては、確かに十分すぎるはずです。

これで、デスクトップでのPWAサポートが出現するのを待つ必要があります。

また、このようなシステムでは、1-組み込み/小型システムへの出荷が容易になり、2-将来的にはモバイルデバイス用の電子のようなオペレーティングシステムベースを作成できると思います。

@yasinaydinすでにLGWebOSがあります。 （以前はFirefox OSもありましたが、廃止されました）

@KeitIG先生、Electronの唯一の問題がサイズであるなら、あなたの議論は絶対にまともです。 プログラムは少し大きくなりますが、開発者の複雑さと失敗の可能性を単純化することは素晴らしいことです（Electronは、開発者に、失敗する余地のない標準化されたアプリ構築方法を提供するのに優れています）。 残念ながら、アプリごとに個別のバージョンのライブラリを使用すると、RAMの使用量が増加し、セキュリティの問題が分散（および修正が困難）になります。 これについては重複した問題で詳しく説明しましたが、一言で言えば、共有ランタイムライブラリは、それ自体で更新して、さまざまなElectronアプリ間で共有できると思います（「ライト」バージョンでも出荷されます。一部の開発者は、JVMで使用するJavaファイルを配布し、 .exe s）をバンドルしていたので、Electronにとっては本当に大きな問題になります。おそらく膨大な量の作業になることは理解していますが、それは悲しいことです。それはまだ開発者の計画には含まれていません。 彼らが将来それをすることを期待しましょう。

@ dre-hh私はあなたの提案の善意を認めますが、とりわけ、それは過度に制限的です。 たとえば、私は雇用主向けに商用の電子アプリを開発しました。これは、高度に規制された環境（インターネット接続がない、追跡可能性/監査の要件など）で使用されています。 お客様は、ソフトウェアの自動更新などを許可することはできません。 これは、大衆向けの一般的なWebアプリとは大きく異なります。 エバーグリーンブラウザとOSセキュリティアップデートの自動インストールは、ほとんどの場合、ほとんどの人にとって素晴らしいアイデアですが、私の意見では、それらはどこにでも適合するわけではありません。 ソフトウェアの変更によって引き起こされる混乱のリスクは、特に他のセキュリティ緩和技術が導入されている制御された環境では、古いバージョンのソフトウェアの実行に関連するリスクよりもはるかに大きい場合があります。 したがって、古いバージョンの電子（または実際には任意のライブラリ）を使用してアプリケーションの実行をブロックするなどの極端な対策を講じることは、解決策であるとしても、理想的な解決策ではありません。 （さらに、管理者は実行できるプログラムを制限するための多くのコントロールをすでに持っているので、新しいOS機能なしでこれを実装できます。）

さらに、ほとんどのセキュリティ上の懸念と同様に、問題の多くは、リスクを認識していないか、何らかの理由（時間の不足など）で、使用しているツールのセキュリティガイドラインに従わないことを選択した開発者に起因します。 （例：セキュリティ、ネイティブ機能、およびあなたの責任）私たち開発者はすべて、私たちの仕事の品質（セキュリティを含む）に責任を負うことに責任を負う必要があります。

最後に、これらの懸念に対処するためにマイクロソフトなどの商用ソフトウェアエンティティに目を向けるのは間違いだと思います。 これは、先ほど述べたように、セキュリティを意識していない開発者を介して安全なアプリケーションを作成することは期待できないためです。 さらに重要なのは、少なくとも私の意見では、Electronのすばらしい点の1つは、オープンソースとマルチプラットフォームの性質であり、通常、商用ソフトウェアベンダーにとっては優先度が高くないということです。 よく考えられて成功するためには、開発者コミュニティ全体からのある程度のコンセンサスと努力が必要になる可能性があります。 もちろん、営利団体からの寄付はもちろんありがたいです。

@jacobqご存じない方のために説明すると、MicrosoftはElectronの所有者です。

ご存じない方のために説明すると、MicrosoftはElectronの所有者です。

@ Jop-Vこれについての引用を追加してください。 私はそれが正しくないと思います。 electronicjs.comのフロントページには次のように書かれています。

Electronは、GitHubと活発な貢献者コミュニティによって維持されているオープンソースプロジェクトです。

MicrosoftはElectronの消費者であり（Visual Studio Codeなどの製品で使用されています）、（おそらく）寄稿者でもありますが、所有権はありません。 ライセンスファイルにはMicrosoftについては記載されておらず、Wikipediaの記事ではMicrosoftが所有権を持っていることを示唆していません。

@jacobq MicrosoftはGitHubを買収する予定なので、Electronが現在GitHubによって保守されている場合、私が知る限り、間もなくMicrosoftによって保守される予定です。

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

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

MicrosoftがGithubを買収しても、Electronにとって何の意味もありません。 Githubは、独自の製品とプロジェクトを備えた独立した会社です。 MicrosoftがAtomの所有権を取得しているのを見ないのと同じように、MicrosoftがElectronの所有権を取得しているのを見ていません。

しかし、この議論は問題の最初のポイントを実際には助けていないと思います。

https://github.com/GoogleChromeLabs/carlo

カルロはかなり興味をそそられます。 私はそれを試してみました、そしてそれは非常に直感的です。 誰かがそれをパッケージ化することをまだ実験しましたか？

エンドユーザーのハードドライブとメモリの肥大化を減らすためのすべての提案が決して機能しないのはなぜですか？ これは4年前の素晴らしいアイデアであり、今でも単なるアイデアです。 なぜこのようなことがプロジェクトの優先事項の最優先事項になっていないのか理解できません

@ danielo515なぜなら、さらに別の勤勉なプロジェクトを作成する代わりに、 https： //github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

あなたは何について話していますか？ これはすでに巨大なプロジェクトです。 また、最も普及して使用されているため、このプロジェクトの一部であるはずの機能について別のプロジェクトを紹介することは、私には正しくないようです。
また、Carloは別のアプローチであり、インストールされているChromeを使用するため、Electronのデーモンバージョンとは異なります。

なぜこのようなことがプロジェクトの優先事項の最優先事項になっていないのか理解できません

それを実現するのは難しいからです（「本当に」難しいように）。

あなたが満足していない場合（これは完全に理解できます）、ElectronをフォークしてPRを提出してください。

誤解しないでください。この問題の簡単な解決策があれば、すでに実装されているはずです。

@ danielo515

...このプロジェクトの一部であるはずの機能について、人々に別のプロジェクトを紹介することは、私には正しくないようです。

重要なのは、各プロジェクトには長所と短所があり、Carloはスペースに制約のあるケースに適しているということです。 私のユースケースでは、100 MBのアプリサイズで十分です。この機能が登場するのを楽しみにしていますが、他の電子機能の方がはるかに重要です。

@jacobqはい、その通りです。さまざまなユースケースでさまざまなツールが必要になります。

他の誰かが興味を持っているなら、私はデスクトップでjsアプリを開発するための同様のツールのリストを作成しました。

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

何十もの100MBアプリを更新する余裕がないため、Electronを使用していません。アプリを更新する方法を知っています（他の意見もありますが、共有しても役に立ちません）。
carloのアプローチで私が本当に気に入っているのは、インストールされているブラウザーを使用するというアイデアです。
さらに良いことに、パペッティアは他のブラウザも管理できるため、carloはクロムだけでなく利用可能なブラウザを使用できます。 OSXでは、Safari、Linuxエピファニー（webkitgtk）、Firefoxなどをスポーンします...
したがって、実際にアプリを入手するには、nodejsとアプリをインストールするだけで済みます。
ここで問題となるのは、システムにインストールされたライブラリとネイティブアドオンを使用することで、どの程度優れたpkgが得られるかということです。
たとえば、現在開発中のアプリをパッケージ化する必要がある場合は、postgresql、sharp（およびvips）、、 webkitgtk、およびexiftoolが必要になります。 Linux debian、fedora、またはubuntuユーザーにのみアプリを配布できるようにしたいと思います。 私は「クレイジーバンドル」を回避し、代わりにそれらのディストリビューションによって行われたハードワークを無料で利用したいと思います。

@kapouer ...インストールされているブラウザを使用します...

理論的には良い考えですが、複数のブラウザーのサポートに集中する必要があり、それらがフォールバックするブラウザーは、実行したいものが制限される可能性があるため、Web側でアプリケーションをコーディングするのが難しくなります。 Chromiumで見られるようなものを完全にサポートしていません。 また、ユーザーのブラウザーが最新であること、および複数のブラウザーベンダーが更新によってアプリケーションを壊さないことをユーザーに依存します。

多くのユーザーは、デルタ更新に切り替えるか、パッケージマネージャーに.asarファイルまたはリソースフォルダーのみを更新させることで、50Mbの大規模な更新を回避しています。 そして、必要な場合にのみ大規模なElectronアップデートを実行します。 これは私たちの会社で行っていることであり、うまくいきました。

ナイーブなユーザーの観点からは、共有ランタイムとしてElectronアプリシェルを使用すると、配布と使用が非常に簡単になります。 たとえば 1つのシステムに5つの電子アプリがある場合、アプリシェルのインスタンスが5つあり、約300MBですよね？

電子はデスクトップUXの未来であり、これはWeb技術をより強力にするための大きな一歩になると強く信じています（.NETランタイムを見てください-悪い比較かもしれませんが、それはクールですよね？）。

Electronにはすでに開発用のランタイムがありますね。 「電子」。 コマンド、つまり。 それをユーザー側に再利用してみませんか？

Electronの異なるバージョンに応じて複数のアプリを処理するには、.NETCoreが使用するアプローチを使用できます。 ランタイムの複数のバージョンを並べてインストールし、アプリに必要な最小（または最大）バージョンを宣言させるだけです。

概念実証ランチャーを作成しました： 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ファイルに関連付けて、asarsだけを配布することもできます。

また、 --downloadOnlyや--silentなど、いくつかのコマンドラインパラメータがあるため、セットアッププロセス中にインストーラー内から呼び出すことができます。

自動更新は処理しません（互換性のあるバージョンのElectronがマシンでまだ利用できない場合にのみダウンロードします）が、これは起動時に定期的に、またはバックグラウンドサービスによって（ランタイムが配置されている限り）実行できます。アプリが起動されたときに最新のものを見つけて使用する適切な場所）。

ランタイムの古いコピーをいつ削除するかを知るのは難しいかもしれません。 それらは時間の経過とともに積み重なる可能性があります。 インストールされているどのアプリがどのバージョンを使用したか（したがって、どのバージョンが不要になったのか）を追跡するか、ランタイムバージョンごとに最終使用日を保存し、使用されていない場合は自動削除する必要があります。少しの間。

とにかく、概念実証/提案。 このようなものは問題を解決しますか？ 私は明白で明白な何かを逃したことがありますか？

@ProPukeのelectron-sharedを試してみたところ、 electron-quick-startデモを実行できました。 しかし、 electronjs Webサイトで説明されているアプリを実行できませんでした（私が理解しているように、ほとんどのアプリはpackage.jsonだけでなく、シェルスクリプトを使用してアプリを起動します）。 しかし、この_概念実証/提案_は、次の大きなアップグレードへのポインタになる可能性があると思います。

私にはアイデアがあります。electron現在コマンド「electron.exepath」をサポートしているので、コマンドラインから複数のasarsを呼び出すことで開くことができると思います。現在、私は単なるアイデアです。誰かがそれを実行できることを願っています。このソフトウェアに触れたばかりだからです。
_____________中国語翻訳版__________
考えがある。現在、electronはコマンド「electron.exepath」をサポートしているためです。コマンドラインを使用して複数のasarを呼び出すことで開くことができると思います。私は今のところただのアイデアです。私はこのソフトウェアに携わったばかりなので、誰かがそれを見てくれることを願っています。

会話全体（および複数の「アプリ」などの他のディスカッション）をざっと見てから、要約します。複数のバイナリから始めるのではなく、複数のasarをネイティブに呼び出すことには長い歴史がありますが、サポートされていません。しかし、electronのdefault_appは、コマンドラインを使用して実装されています（多分、当面はわかりません）。電子を介してcmdを呼び出すと（可能と思われます）、この関数の互換性を実現できるはずです。
すべての会話（および複数の「アプリ」などの他のディスカッション）をざっと見てみると、複数のバイナリではなく複数のAsarへのネイティブ呼び出しが開始され、長い歴史がありますが、サポートされていないと結論付けています。しかし、Electronのdefault_appはコマンドラインを利用する実装（そして、おそらくしばらくはわかりません）。電子を介してcmdを呼び出したいのですが（できるかのように）、この機能の互換性バーを実現できるはずです。

最悪のシナリオでは、.batファイルまたはWindows以外のOS用の同等のファイルを作成し、Electronから実行する必要があります。

おそらく便利なリンク：

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

app.asarまたはappフォルダーがない場合にのみコマンドelectronであるように見えます。 有効なexeパス

ああ、それであなたはそれらすべてをセットアップするために使われた電子の中にexeパスを走らせるために電子を持っている必要があります。 使用するすべてのアプリの電子インストールよりもさらに優れています。 アプリに必要な電子のバージョンごとに1つの電子をインストールするだけで済みます。 おそらく、実行しようとしているアプリと、推奨バージョン（すぐに実行される）、互換性のあるバージョン（実行するかどうかを尋ねる）のファイルの両方を含む、名前が変更されたzipアーカイブである別の拡張機能を作成する必要があります。推奨バージョンをインストールし、推奨バージョンをバックグラウンドでダウンロードするか、ダウンロードの進行状況バーを表示して、推奨バージョンをダウンロードします。

または私は何かを誤解しました。

この考えはおそらく同じです。batは現在簡単に言うことができるので、たとえば、コンテンツはelectron.exe app1.asarであり、実行後、electronはapp1.asarのコンテンツを開きます。 それはおそらくそれが機能する方法ですが、次の文、electron.exe app2.asarをバットで書くとき、app1.asarの電子が終了するときにのみそれを行うことができます。 そして、バットがオフになると、電子がオフになります。 ただし、electron.exe app3.asar | electron.exe-vまたはelectron.exeapp3.asar | startなどと記述します。 バットを閉じると、電子は生き残ることができますが、他のアサルを開き続けることはできません。 バットはまだいくらか制限されているので、このスタンドアロンプ​​ログラムはこれよりも優れていると思います。

一時フォルダを使用する場合は違います。

（アーカイブ済みまたは未アーカイブの）バージョンがelectron_versionsフォルダーにあり、そこから、使用しているバージョンを一時フォルダーにコピーしてダウンロードした推奨バージョンまたは最新の互換性のあるバージョンのいずれかを使用します。フォルダを削除します。

ローカルに保存されたファイルのパスは、electronフォルダー内か、使用しているファイルの隣にあります。 過去24時間以内に言及したものを含むアーカイブから使用している場合は、保存したデータファイルをアーカイブに戻すか、その一時的な電子インスタンスフォルダーを削除する前にまったく移動しない必要があります。

SSD？

???

一時的なelectronフォルダーを削除する理由は、アプリが実行中のelectronインストールのファイルを理論的に変更する可能性があるためです。 つまり、アーカイブには、一時的な電子インストール内で書き込みまたは上書きする必要のあるファイルとフォルダーを含めることができます。

そのため、インストールを使用した後は、実行したアプリによって破損したものとして扱われる可能性があるため、リサイクルできないため、削除する必要があります。 ただし、ベースとして使用されていた当時の破損したインストールのバージョンは、作成しようとしているruntime-electronアプリのelectron_versionsフォルダーにそのまま残っています。

実際、前述した明確な拡張子を持つアーカイブが読み取り専用の場合、理論的には、使用したデータを％appdata％に移動できます。 したがって、作成しようとしているruntime-mode-electron内で実行されたアプリは、実際には移植可能（自己完結型）であり、したがって、そのファイルをコピーするだけで、そのアプリの構成を持ち運ぶことができます。

ただし、おそらくそのファイルタイプの更新関数を追加する必要があります。これは、新しいインストールファイルから古いインストールファイルのコピーにファイルをコピーして上書きし、新しいインストールファイルを次のように返す別の電子インストールです。それが持っていたデータ。 私たちが作成しようとしているruntime-mode-electronによって使用されるファイルにダウンロードリンクがあれば、すべてが自動的に実行される可能性があります。

準備ができたら、さらに一歩進んだ場合は、アプリを更新するためのgitクライアントを追加することもできますが、アーカイブのコンパイル済みファイルをホストするにはgithubとbitbucketを使用する必要があります。

「curl、wget、aria2c」ダウンロードファイルを使用でき、ユーザーはgitをインストールする必要はありません。ああ、「gzip、7z」unpackzipを使用する必要があります。

electron-builderと同じように機能するツールelectron-runtimeを作成しています。 app.asarファイルのみを単純なshスクリプトにバンドルします（後で、これはElectronダウンロードの進行状況を表示するUIになります）。 現在、macOSでのみ機能します。

electron-runtimeでパッケージ化されたアプリを実行すると、基本的に対応するメジャーバージョンのElectronがダウンロードされますが、Electronの重大な変更はメジャーバージョンの増分でのみ発生するため、マイナーおよびパッチの場合は最新です。

electron-quick-startアプリはわずか62 KB、スクリーンショット：

興味がある場合は、スター、PR、または問題を残してください。

パッケージを少し更新して、 electron-builderを使用してビルドできるようにしました（これがどのように機能するかを説明します）。 これで、Visual StudioCodeも作成できます。 （ただし、macOSのみ）。

electron-globalの最初のバージョンを正常にリリースしました！ （ electron-runtimeが取られたので、変更しました）。 electron-builderで私のnpmパッケージを使用してアプリをビルドできます。 また、Electronダウンロードの進行状況を表示する進行状況バー付きのUIを追加しました。 Electronをより良くすることがもっと人気になることを願っています。

申し訳ありませんが、私はWindowsシステムを使用しており、MacOSを使用するためのお金がありませんが、あなたのプロジェクトは非常に成功すると思います。

@nwdxlgzs Windows、macOS、Linuxをサポートしています...

このプロジェクトはMACのみをサポートしていると思いました。
私はこの素晴らしいプロジェクトを試すために時間をかけるつもりです。

それを作ってくれて、そして私たちを最新の状態に保ってくれてありがとう！
私もWindowsを使っています。
変更を取得したら、コードを確認します。

さて、 electron-globalを上流に統合して、それを新しいデフォルトにするのはどうですか😏