+100, Было бы очень полезно уменьшить размер приложения.

Можно ли изменить расширение .asar ? На венгерском это звучит очень странно. По сути, это означало бы the shit в плохом смысле ( ссылка ).

.apak? со всей серьезностью, существует множество языков, поэтому почти любое расширение может звучать странно в некоторых из них.

Установка и обновление среды выполнения IMO должны быть максимально простыми. Многие среды выполнения имеют очень раздражающие уведомления. Кроме того, если вы собираетесь сделать это, должны быть предоставлены некоторые дополнительные метаданные манифеста, поскольку более новые версии приложения могут не работать в старой среде выполнения, поэтому вам необходимо сравнить текущую версию среды выполнения с версией в манифесте приложения (возможно, даже диапазон версий, как в узле пакеты ), а затем, если необходимо обновить среду выполнения, максимально упростите этот процесс. Я не знаю, что легко для большинства людей, но для меня это просто окно с индикатором выполнения или сообщениями о состоянии ("Загрузка... 57%", "Обновление...")
Я не уверен, но фоновые обновления также могут быть рассмотрены. Это может быть какая-то служба обновлений или просто загрузка во время выполнения во время работы приложения и обновление, когда приложение закрывается.

+1 за это. Я работаю над приложением, которое мне нужно доставить для Mac и Windows, и это значительно упростит доставку.

Это было бы здорово!

Несколько мыслей:

• Как сказал @YuriSolovyov , нам нужен способ объявить, с какими версиями среды выполнения атома совместим конкретный asar. Желательно, чтобы это также позволяло указать точную версию, поскольку это снижает нагрузку на QA при выпуске приложения на основе asar.
  
  
  
  • Чтобы поддерживать это, нам нужно разрешить установку нескольких версий среды выполнения atom параллельно, потенциально невидимых для пользователя.
  
  
  • Обратите внимание, что это несколько противоречит идеалам ограничения размера загрузки. Тем не менее, компания, производящая несколько продуктов на основе asar, может провести внутреннюю стандартизацию, чтобы все их приложения по-прежнему использовали одну и ту же версию.
  
  
• Вы не упомянули о поддержке автоматического обновления среды выполнения атома на Mac, но это было бы _очень_ полезно.
• Вместо установки только исходного кода в Linux было бы хорошо поддерживать установку/обновление двоичных файлов, как через пакеты .deb/.rpm, так и с помощью какого-либо метода, который не требует прав sudo для установки (т.е. для каждого пользователя). Для сред выполнения, установленных для каждого пользователя, также было бы очень полезно автоматическое обновление.
• Будет ли какая-либо поддержка для поддержания установленных файлов asar в актуальном состоянии - или это что-то, что должно быть реализовано независимо в каждом приложении?

Наконец, каковы сроки этой работы? Что было бы лучшим способом начать, если бы я хотел начать реализацию части этого? Я готов внести свой вклад.

@ joshuawarner32 В настоящее время это всего лишь грубая идея, я планирую поработать над ней после решения некоторых основных проблем атомной оболочки, но это может произойти через несколько месяцев.

Я думаю, что также стоит посмотреть на существующие рантаймы и на то, как они работают/обновляются, насколько они мешают и какие еще плюсы и минусы.

В настоящее время это только грубая идея, я планирую поработать над ней после решения некоторых основных проблем атомной оболочки, но это может произойти через несколько месяцев.

Прошло около 5-6 месяцев. Было бы здорово реализовать это.

Мы создали внутреннюю реализацию этого, которая очень хорошо подходит для нашего конкретного варианта использования, и мы могли бы ее воспроизвести. Опасность заключается в том, что это на самом деле слишком специфично для нашего варианта использования, и никому больше не будет интересна дополнительная сложность.

Вот основные моменты нашего дизайна:

• Разверните файлы .asar.gz для нескольких разных приложений на сервере.
• Распространяйте среди пользователей единую сборку Atom-Shell, которая не содержит кода для конкретных приложений.
• При запуске приложения загрузите соответствующий файл .asar.gz (если его нет или на сервере есть более новый файл). Извлеките его и запустите содержащееся в нем приложение.
• Наша сборка атомной оболочки принимает аргумент --app , чтобы указать, какое приложение загрузить/запустить.

Это то, что имели в виду люди с атомной оболочкой? Может ли что-то подобное быть полезным для других людей?

Как и JRE, это может быть ERE (среда выполнения электронов) с файлами .eapp (приложение для электронов).

-1 для .eapp

+1 Мне это нужно!

В Windows мы можем предоставить установщик и средство автоматического обновления для среды выполнения атома и зарегистрировать тип файла .asar, который будет открываться вместе с ним.

Установите Steam на Windows и посмотрите, как они создают ярлыки для игр, на самом деле они используют обработчик протокола, это относительно умно.

:+1: на модели Steam.

Нет никаких технических препятствий для реализации этого, все это может быть просто приложением Electron. Но проблема в том, что это непросто реализовать, принимая во внимание все детали, я думаю, что для этого требуется небольшая команда, работающая полный рабочий день, я не уверен, что это когда-нибудь произойдет.

Но проблема в том, что это непросто реализовать, принимая во внимание все детали, я думаю, что для этого требуется небольшая команда, работающая полный рабочий день, я не уверен, что это когда-нибудь произойдет.

У меня в голове много вопросов, которые, хотя и не являются непреодолимыми, делают этот план Трудным. Например, скажем, «Приложение 1» требует 0.30.x и не может работать на 0.31.x, а «Приложение 2» требует обратного. Кто выигрывает в этом сценарии?

Кажется, что требуется много усилий и инфраструктуры/хитростей для оптимизации чего-то, что не является нашей самой большой проблемой - дискового пространства и пропускной способности, за счет сложности разработчиков (т.е. теперь разработчики должны создать этот сумасшедший цепной установщик, чтобы сначала установить/ проверьте Electron, затем установите их приложение)

Я не хочу ненавидеть идею! Я просто думаю, что время, которое мы потратили бы на это, мы могли бы вместо этого потратить на нашу большую проблему — упростить для новых разработчиков создание и публикацию приложений Electron, от их первой строки кода до конца. отправка пользователям

@paulcbetts Но эй, преимущества того стоят, не так ли? При обновлении приложения пользователям придется загружать менее 7 МБ вместо ~ 70 МБ. Это означает, что нам даже не понадобятся автообновляющиеся фреймворки и все такое, нам просто нужно скачать и распаковать микро-zip-архив с парой файлов.

Я провел последние три месяца в отдаленном районе, где скорость была меньше 128 кбит/с, и поверьте мне, размер обновления — это огромная боль в заднице, хуже всего то, что есть еще множество людей, которые все еще находятся в подобных ситуациях.

Это означает, что нам даже не понадобятся автообновляющиеся фреймворки и все такое, нам просто нужно скачать и распаковать микро-zip-архив с парой файлов.

Я не думаю, что это правда, потому что почти наверняка в какой-то момент вы захотите перейти на более новую версию Electron, а затем kerplowie, вы находитесь в похожей ситуации (или, по крайней мере, в такой же уродливой). )

Базовые приложения теперь весят от 30 до 50 мегабайт, если только у вас нет дерьмовой тонны видео внутри вашего пакета. Я не думаю, что большинству людей это сложно скачать. Я считаю, что средний размер видео на YouTube составляет от 30 до 40 МБ ...

Я просто хотел бы отметить, что в Китае скорость соединения составляет в среднем около 20 КБ/с (конечно, у меня соединение медленнее, чем ~92% моего города). Обновление Atom/electron обычно требует полного дня wget -c инг. если не используются зеркала таобао.

Для совместимости версий электронная разработка движется слишком быстро, чтобы иметь универсальную версию, возможно, можно использовать какую-то оболочку/помощник для использования/загрузки запрошенной основной версии при запуске приложения?

20 кбит/с? как вы можете выжить? Я не могу себе представить, как это должно усложнять жизнь!

@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 App Launcher . Основная проблема заключается в том, как мы обрабатываем приложения, когда среда выполнения обновляется до новой версии.

Приложения Electron страдают от обновления Electron, особенно собственных модулей узла. Собственные модули необходимо пересобирать для каждого обновления Electron из-за проблемы C ++ ABI (пользователи сообщают о нескольких проблемах с забытым перестроением ).

Steam не страдает от боли, так как каждая игра в Steam является отдельной программой, на самом деле вы можете запустить игру без клиента Steam. Запуск приложений Chrome также не выполняется, поскольку приложения Chrome написаны на HTML/JS/CSS, которые являются своего рода интерпретируемыми языками, и в разных версиях Chrome нет пробелов.

@hokein как насчет того, чтобы у нас был легкий «клиент» на родном языке, который загружает несколько языков, всякий раз, когда он сталкивается с приложением, которое зависит от неустановленной версии электрона, он загружает его копию, а затем запускает каждое приложение с его конкретным электроном.

Новый релиз Electron выходит примерно раз в неделю, поэтому вероятность того, что 2 приложения имеют одинаковую версию Electron, невелика.

Чтобы поддерживать подход времени выполнения, нам, вероятно, потребуется начать разделять выпуски на версии LTS (долгосрочная поддержка) и передовые версии. LTS будет использоваться в производстве, а передовые технологии будут использоваться для разработки и тестирования. LTS получит только исправления ошибок и, возможно, некоторые изменения, которые не заменят основные версии io.js и оболочки содержимого, поэтому нативные модули должны по-прежнему работать.

учитывая то, что сказал @etiktin , если у пользователя нет много электронных приложений в своей системе, время загрузки, вероятно, не принесет никакой пользы, поскольку им все равно придется загружать время выполнения каждый раз.

За две недели, что я смотрю на электрон, я, кажется, увидел 4 релиза.

@etiktin В идеале, если электрон следует за semver, тогда приложение может объявить версию ^ 0.31 и использовать последнюю версию 0.31.x. Это может немного помочь.

У нас есть приложение в производстве с механизмом автоматического обновления semver, который делает следующее:

1. ПОЛУЧИТЕ простую конечную точку HTTP на сервере с указанием текущей версии (0.3.0, 0.3.1 и т. д.) и платформы (darwin-x64, win32-ia32, win32-x64 и т. д.) приложения.
2. Сервер возвращает «304 Not Modified» или манифест JSON, если есть более новая версия.
3. Манифест JSON, по сути, представляет собой вложенный список папок, файлов и символических ссылок в более новой версии.
4. Запись папки в манифесте JSON выглядит так: [имя, массив дочерних записей].
5. Запись файла в манифесте JSON выглядит следующим образом: [имя, хэш содержимого, массив хэшей содержимого, разделенный на куски по 64 КБ, целочисленный флаг, указывающий, является ли файл исполняемым или нет].
6. Запись символической ссылки в манифесте JSON выглядит так: [имя, путь назначения].
7. Эти манифесты JSON создаются и кэшируются на сервере для каждой версии. Для каждого файла в манифесте JSON сервер запускает простой алгоритм дедупликации, чтобы разбить файл на фрагменты переменной длины с использованием фрагментирования в зависимости от содержимого, а затем хеширует фрагменты с помощью SHA256. Это гарантирует, что большинство хэшей фрагментов для разных версий одного и того же файла останутся одинаковыми, даже если содержимое сместится на несколько байтов. Средняя длина фрагмента составляет примерно 64 КБ для оптимальной эффективности дедупликации и сжатия. Если фрагменты больше, они также не будут дедуплицироваться, если фрагменты меньше, они также не будут сжаты. Средняя длина фрагмента также будет увеличена для очень больших файлов, чтобы избежать слишком большого количества хэшей фрагментов в метаданных.
8. Когда приложение получает новый манифест JSON с сервера, оно проверяет доступное свободное место на диске и создает новый временный каталог с универсальным уникальным идентификатором. Используя свой старый локальный манифест в качестве отправной точки, он затем копирует фрагменты из локальных файлов или загружает недостающие фрагменты с сервера для воссоздания нового манифеста. После создания новой версии проверяется структура каталогов и подписи всего содержимого файлов. Если что-то было повреждено при загрузке, обновление удаляется.
9. Если новое обновление успешно проверено на соответствие манифесту, оно запускает новую версию приложения по новому пути обновления.
10. Старая версия замечает, что запущена другая версия, и выключается.
11. Новое приложение ожидает завершения работы старой версии, затем копирует себя в другой временный каталог, переименовывает старую версию в архивный каталог и переименовывает временный каталог в расположение старой версии (/Applications/Ronomon.app). Затем он снова запускается, но теперь из расположения старой версии (/Applicatons/Ronomon.app), а затем очищает каталог архива.
12. Если во время перехода что-то пойдет не так, старая версия останется на каноническом пути до тех пор, пока не будет переключена вызовом переименования.

В целом, это очень хорошо работает в производстве. Дедупликация и сжатие означают, что для типичного обновления основной версии необходимо загрузить только около 33%, а для второстепенных обновлений требуется всего 1-2 МБ в зависимости от приложения. Автообновление обрабатывает код Electron и приложения как одну атомарную единицу и никогда не нарушает какие-либо подписи кода в процессе.

+1 К идее
+1 Чтобы переименовать asar

Я пришел, чтобы задать вопрос по этому поводу. Нашел, что это уже существовало, поэтому я поставлю + :100: к этому
Нам абсолютно необходимо решение, похожее на JRE, .NET или Adobe Air, потому что упаковка среды выполнения с каждым приложением делает их очень громоздкими.

Есть ли какие-либо обновления об отделении среды выполнения от приложений?

Это закрыто, потому что решение было разработано?

@PierBover этот вопрос открыт.

это - https://github.com/KeitIG/museeks/issues/48 - закрыто. в чужом репозитории.

О, спасибо @championswimmer и извините за путаницу.

Так есть какие-нибудь новости о независимой среде выполнения? Над этим ведется работа?

@PierBover , вероятно, этого не произойдет в ближайшее время из-за фрагментации текущей версии (трудно найти 2 электронных приложения, которые используют одну и ту же версию). Возможно, после выхода v1.

@jorangreef , вы используете свой механизм дифференциального обновления на всех платформах? Было бы здорово, если бы вы могли выпустить этот код как отдельный модуль.

@championswimmer Да, мне удалось создать сценарий сборки для своего приложения, так что теперь я могу распространять свое приложение. Но я слежу за этим, потому что это было бы интересно.

@etiktin Да, дифференциальное автоматическое обновление в настоящее время работает на всех платформах. Если бы он также включал минимальный установщик, который выполняет загрузку, то установщик мог бы использоваться несколькими приложениями и использовать кешированную версию Electron, если она уже доступна. Это поможет сделать установку намного быстрее. Я хотел бы открыть его исходный код, если люди заинтересованы, и постараюсь выпустить код в ближайшие несколько месяцев.

Например, скажем, «Приложение 1» требует 0.30.x и не может работать на 0.31.x, а «Приложение 2» требует обратного. Кто выигрывает в этом сценарии?

Затем они должны установить две версии, и будет две среды выполнения, точно так же, как VS C++ 2008 сосуществует с 2005. Мне очень нравится, как устанавливаются среды выполнения VS C++, установщик установит нужную версию, если ее нет, а другие могут зависеть от это позже, и разные среды выполнения могут сосуществовать. Принудительное выполнение требований к версии также кажется более простым в программе установки.

@ louy2 Существует разница между примером Visual C ++ (3 года между выпусками) и Electron (минимум 3 выпуска в месяц)

Я состряпаю здесь цитату «это сломанная система», если большинство
приложения в экосистеме Electron несовместимы с +- 0.0.1 или
Различия версий 0.1.0

20 февраля 2016 г., 18:55, Пьер де ла Мартиньер <
уведомления@github.com> написал:

@louy2 https://github.com/louy2 Есть разница между
пример Visual C++ (3 года между релизами) и Electron (3 релиза в каждом).
минимум месяц)

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/atom/electron/issues/673#issuecomment-186595285 .

+1

Я упаковал электрон в пакет .deb, используя fpm . Это может быть хорошей отправной точкой для Linux (по крайней мере, на основе Debian или RPM). Вы можете посмотреть здесь: iamale/electron-deb ; также есть пример приложения . (Это будет работать и с asar, просто нужно добавить запись MIME в пакет времени выполнения.)

Было бы здорово, если бы у нас было что-то подобное и на других платформах! Я, вероятно, мог бы попытаться упаковать его для Windows, но я больше не использую его активно, и у меня не было большого опыта работы с ним.

(Спасибо @louy2 за то, что указал мне на эту тему!)

Кстати, какой тип MIME у .asar? Подойдет ли application/x-asar ?

@iamale Вместо fpm вы взглянули на AppImageKit . Основное преимущество, которое вы получаете, заключается в том, что вместо создания нескольких библиотек и всего прочего вы можете настроить все дистрибутивы Linux с помощью одного исполняемого файла. Вам также больше не нужно просить пользователя установить какие-либо зависимости, поскольку они связаны с исполняемым файлом. Это хороший проект, пожалуйста, взгляните.

а насчет пантомимы, как насчет application/x-electron ?

@steelbrain Хорошая идея. Однако это не решит первоначальную проблему: среда выполнения Electron должна быть упакована с каждым приложением (поскольку образы должны быть самодостаточными), что и касается этой проблемы. Хотя я думаю, что должно быть относительно легко создавать AppImages из приложений Electron, и я считаю, что это было бы здорово, когда нельзя использовать традиционное управление пакетами (редкие дистрибутивы или непривилегированные пользователи). Итак, спасибо, что указали на это!

Кстати, application/x-electron звучит великолепно, возможно, я так и останусь.

Добавлена ​​поддержка асар! Пока нет в репозитории, пересоберу позже сегодня или, может быть, завтра. На данный момент вы можете получить пакет на Transfer.sh (ссылка будет действительна в течение следующих 2 недель)

Вам нужен asar.json внутри .asar, чтобы сказать:

• рекомендуемая версия
• совместимые версии
  Как только это будет сделано, вам понадобится одно приложение, использующее электрон (любую его версию), чтобы проверить Интернет на наличие (1) обновлений для себя (средство проверки) и (2) существующих версий на вашем компьютере, а затем, если существует совместимая версия, оно анализирует путь открытия к открытому .asar, в противном случае скачайте рекомендуемую версию и проверьте еще раз. Само приложение может быть написано на Electron или Python (поскольку для него потребуется минимальный пользовательский интерфейс или его отсутствие).

Идея такова: приложение, которое проверяет, загружена ли требуемая электронная версия, не имеет ничего общего с необходимыми электронными версиями.

Если возникнет необходимость, вы можете обновить содержимое default_app, а также остальную часть приложения, кроме него.

И там вы можете сохранить версии с помощью app.setPath("userData", __dirname + "/ElectronVersions"); , тогда эти версии можно оставить там в покое, а новые установить по мере необходимости.

Вместо fpm вы взглянули на AppImageKit .

AppImage Atom доступен по адресу https://bintray.com/probono/AppImages/Atom/_latestVersion#files — просто скачайте chmod a+x и запустите на любом не слишком устаревшем дистрибутиве x86_64 Linux.

Проблема не только в Linux, нам нужен способ сделать его кросс-операционным, а это значит, что нам нужно иметь возможность запускать его на Linux, Windows и Mac OSx.

Какая-то программа запуска для конкретной ОС, которая проверяет, доступна ли среда выполнения и актуальна/совместима с пакетом asar.

(много лет спустя) Позвольте мне подытожить обсуждение:

1. @zcbenz предлагает среду выполнения, которая управляет локальными экземплярами Electron, поэтому пакеты .asar распространяются только и избегают связывания двоичных файлов Electron. Среда выполнения также управляет выполнением пакетов .asar .
2. @YurySolovyov предлагает добавить в файл манифеста дополнительную информацию (например, требуемую версию Electron), чтобы среда выполнения знала, какая версия должна использоваться для какого пакета .asar . Обзор этого подхода дан здесь .
3. @joshuawarner32 представляет идею нескольких версий среды выполнения, бинарной упаковки (например, как .deb ) и автоматического обновления для пакетов .asar . Кроме того , рассматривается идея сервера раздачи.
4. @paulcbetts предлагает взглянуть на модель Steam и реализовать нечто подобное. Он указывает на сложности, связанные с идеей локальной среды выполнения, поддерживающей разные версии Electron и т. д.
5. [люди обсуждают скорость интернета в Китае и свои детские дела]
6. @hokein указывает на сложности при обновлении среды выполнения. Специально пис. нативные модули, которые необходимо собрать заново для заголовков Electron.
7. @etiktin хочет иметь версии LTS и передовые версии, поэтому готовые к производству приложения используют LTS, а не передовые версии.
8. @Tribex говорит , что если мы придерживаемся семантического управления версиями , нам не нужно иметь локальный экземпляр _всех_ версий, а только несовместимые.
9. @jorangreef предоставляет пример дифференциальной системы автоматического обновления, уже работающей для их собственного приложения.
10. @iamale создал fpm-пакет Electron для выполнения пакетов .asar .

_disclaimer: Я попытался включить только основные моменты обсуждения. Пожалуйста, извините, если я что-то пропустил!_

Я прочитал обсуждение до сих пор, попытался обобщить основные моменты и хотел затронуть некоторые из них. Идея среды выполнения с «глубокой интеграцией с платформой» выходит за рамки простого локального экземпляра. Необходимо определить минимально жизнеспособный продукт, который действует как общесистемная среда выполнения. Я также добавил приятную функцию, которая может пригодиться. В последнем разделе описывается, какие изменения/функции необходимо реализовать.

Обоснование:

То, что делается большинством разработчиков (т.е. объединение бинарных файлов Electron), похоже на статическое связывание всех разделяемых библиотек! Это как поставлять печь с каждой продаваемой пиццей.

Самый ценный игрок:

• Менеджер среды : отслеживает локально доступные экземпляры Electron. Его можно использовать, чтобы решить, какой пакет совместим с каким экземпляром (используя расширенный package.json [см. ниже]). Он также должен позаботиться о настройке правильных переменных среды для запуска пакетов.
• Менеджер обновлений : обсуждалась возможность автоматического обновления (+ уведомление) и дифференциального автообновления. Было бы неплохо иметь его в качестве демона, который заботится об обновлении локальных экземпляров до последних версий.

Приятно иметь:

• Диспетчер пакетов/зависимостей : так же, как apm в Atom, менеджер пакетов необходим для загрузки пакетов .asar (из GitHub или заданного URL-адреса и т. д.) и их локальной установки (сравнимо с apt-get ). 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 .

epm (менеджер электронных пакетов), похоже, уже используется как имя...
Может быть, назвать среду выполнения elec и приложения .tron ? Вероятно, у TRON есть некоторые проблемы с торговой маркой, но это звучало бы круто ;)

Может быть, uepm (универсальный электронный менеджер пакетов), поскольку он предназначен для запуска на всех ОС, поддерживаемых Electron... или epmc (центр управления электронными пакетами) и файл .epack (электронный пакет). Расширение, по крайней мере, звучит лучше, чем .tron , и его нельзя спутать с фильмом («дай мне этот трон, чувак» _передает тебе фильм_).

Есть также множество слов в области теоретической физики, связанных с электронами.

• фермион
• лептон
• заряжать
• кулон
• Паули

И, не связанный напрямую, но в некоторой степени связанный с тем, что происходит с менеджером пакетов,

• бозон
  ;)
  (я считаю, что фотон уже был сделан)

@kapouer +кварк? хотя не уверен, что это принято

Кварк взят, остальное не знаю. Но почему мы должны сохранять статус-кво, когда этот список предложений предлагает НЕ поддерживать статус-кво? Но раз уж мы заговорили, почему бы не назвать его Халдроном? Снято с БАК. Коллайдер - плохая идея, он придает продукту негативный оттенок, потому что смысл его тесно связан с войной...

Particle(s) ? Хотя довольно долго.
Список частиц в вики

Хотя именование важно, я все же думаю, что нам нужно сначала исследовать семантику времени выполнения/обновления/упаковки/распространения.

lepton кажется идеальным, поскольку это семейство частиц, к которому принадлежит электрон.

Идея немного выходит за рамки: более общий менеджер времени выполнения был бы еще более замечательным (и не очень сложным в реализации). Например, мы могли бы также включить двоичные файлы @nwjs и управлять ими в том же самом менеджере версий (точно так же, как @asdf-vm, но для среды выполнения с графическим интерфейсом).

Быстро и грязно: https://github.com/iamale/lepton. Пока поддерживает только исправленную версию (следующее, что нужно сделать, это semver), а приложения распакованы (т.е. пока нет .asar-ов).

Хороший!

+1

Даже если нет .asar, @iamale , пока у вас есть способ узнать, какой файл открыть, я думаю, все должно быть в порядке. Например, у вас может быть file.something с кодом json, связанным с package.json , чтобы он знал, что открывать...

Это довольно сумасшедшая идея, но как насчет использования поля electron в package.json , чтобы сделать
любой (ну не то чтобы ЛЮБОЙ, а любой подготовленный) исполняемый файл пакета 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"
  ]
}

В этом примере рекомендуется использовать электрон 1.2, если он не найден, также проверяет, есть ли какая-либо версия между 1.2.1 и 1.2.5, если нет, проверяет на 1.3.1, то на 1.3.0.1, если нет, проверяет для 1.1, а если нет, то скачивает 1.2.

Может быть, может быть что-то вроде того, что он автоматически загружает рекомендуемую версию, а если не может, то проверяет совместимые версии. И возьмите все совместимые и проверьте их, и если ни один из них не работает, спросите пользователя, не хотят ли они использовать несовместимую версию, и если они нажмут no , он будет работать с несовместимой версией. найден на ПК, и если ничего не найдено, вместо того, чтобы просить использовать несовместимую версию, показать всплывающее окно с сообщением о том, что установка Electron не обнаружена.

@sapioit Наличие отдельного манифеста кажется мне хорошей идеей. Наличие пользовательского расширения файла немного упростило бы ситуацию. (Хотя .electron кажется немного длинным.)

Может быть, согласно лептону @iamale , .lept?

Я не вижу никакой выгоды в том, чтобы не использовать package.json , электронное поле выполняет часть изоляции. Babel и ESlint используют эту технику и прекрасно себя чувствуют.
Это значительно упрощает публикацию приложений напрямую в/через npm.

Да, я второй @YurySolovyov - я думаю, что более уместно поставить его в package.json

@YurySolovyov Преимущество дополнительного файла заключается в том, что среда выполнения может зарегистрировать обработчик для расширения дополнительного файла и автоматически запускаться в качестве средства открытия файла по умолчанию. В то время как для того, чтобы сделать это с помощью package.json, потребуется зарегистрировать обработчик для каждого файла JSON, что было бы проблемой для пользователей.

@Tribex справедливое замечание.
Возможно, package.electro может быть просто ссылкой, которая сообщает среде выполнения "Hey, take a look at package.json, it should contain the info on how to launch it" . Это была «сумасшедшая» идея, так что да, я не против ее подправить.

Я согласен с @tribex , нам нужен ЛИБО отдельный файл, либо переименовать package.json. к чему-то другому.

@wurysolovoyov вы не можете этого сделать. Единственное, что вы можете открыть файл, — это прикрепить к нему расширение, и в этом случае каждое расширение будет открываться с помощью одного и того же программного обеспечения. Поэтому, если вы не согласны с тем, что не можете открыть .json с помощью чего-либо, кроме electron (что приведет к ошибке, если только не будет открыто правильное электронное приложение), вы все равно можете это сделать, но давайте, те, кто хочет иметь возможность открывать файлы .json , иметь возможность открывать их с помощью программы, с помощью которой мы хотим их открывать.

В противном случае вы не сможете редактировать файл, не открыв сначала редактор или не меняя то, что открывать .json каждую минуту или около того.

Я имею в виду @YurySolovyov , а не @wurysolovoyov

Возможно, я не ясно выразился: цель package.electron состоит только в том, чтобы служить маркером того, что этот каталог является приложением, чтобы среда выполнения могла ссылаться на package.json , который находится в той же папке. и запустите приложение. Если вы откроете package.json напрямую, он откроется во всем, что связано с .json в вашей ОС.

Что-то вроде системы ярлыков.

@YurySolovyov В этом случае это просто вопрос вкуса, определяем ли мы эту информацию в package.json или package.electron. Лично я бы держал его отдельно просто потому, что он кажется мне чище. Возможно, свойства engine в package.json будет достаточно.

@Tribex это также требование для публикации приложения в npm - наличие действительного package.json

@YurySolovyov Верно. Если бы мы использовали package.electro, package.json все равно присутствовал бы. .electron будет использоваться только для определения информации о времени выполнения или, в случае вашего предложения, просто будет маркером.

По сути, package.electron будет там только как запускаемый _marker_ , поэтому package.json по-прежнему будет присутствовать со своими собственными данными, но для этого потребуется отдельный файл: _двойной щелчок открывает приложение _. Я все еще хотел бы иметь возможность переименовать package.electron в my-app.electron или my-app.electron .

@sapioit , конечно, в этом весь смысл наличия файла .electron , вы можете назвать его как хотите, если он имеет расширение .electron .

Мне все еще не кажется очень чистым, что обработчик времени выполнения должен смотреть на *.electron, затем на package.json, чтобы определить, какую версию электрона запускать, которая затем снова читает package.json.

@Tribex , почему вы думаете, что package.json будет прочитан дважды?

• Если мы поместим информацию о времени выполнения в файл .electron , время выполнения запустит приложение, используя package.json , предполагая, что все правильно и безотказно, если это не так.
• Если мы поместим среду выполнения в package.json напрямую или в раздел electron , для этого также потребуется только 1 чтение. Таким образом, я не уверен, что поместить в файл .electron (идеи?), я был бы в порядке, даже если бы он был пуст.

@tribex .electron может указывать на package.json на всякий случай, по каким-то причинам package.json переименован. Таким образом, у вас может быть package.json за NPM и разные package.json (возможно, electron.json ) для Electron. Почему? Возможно, вы хотите, чтобы ваше приложение имело 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 , у нас может быть только ссылка .electron на .json , которую мы хотим использовать для открытия приложения, поэтому:

_ app.electron _

{
  "package": "package.json"
}

или

_ myapp.electron _

{
  "package": "electron.json"
}

Кроме того, возможно, вы хотите иметь две программы запуска в одном каталоге, одну для клиента и одну для сервера, чтобы клиент использовал файлы сервера для запуска локального сервера только с одним игроком. Таким образом, вам не нужно будет дублировать все 99% файлов (при условии, что у вас есть игра, которая использует 500+ МБ файлов) и 5-6 разных файлов, и иметь их в двух отдельных каталогах, а просто иметь один дополнительный файл, чтобы иметь возможность запускать сервер самостоятельно. Буквально то же самое, что иметь несколько исполняемых файлов в одном каталоге.

Отдельный package.electron должен называться package.electron.json или иметь расширение .json , чтобы редакторы и IDE правильно определяли синтаксис.

@StreetStrider Я бы предпочел научить IDE тому, что .electron действительно .json .
И это также подводит нас к тому, что мы обсуждали с @sapioit ассоциации .json . Я не думаю, что какая-либо популярная ОС поддерживает ассоциации с двойным расширением. ( .foo.bar )

Вы можете добавить расширение .json при редактировании. или щелкните правой кнопкой мыши и откройте с помощью редактора, но точно так же, как Adobe Air, который по умолчанию открывает файл с помощью своей программы запуска, позволяя пользователю открыть файл с помощью редактора, что не вызовет проблем.

@sapioit Справедливое замечание, я думаю, что тогда я согласен с вами по поводу указания на package.json.

Для меня среда выполнения и плеер — две разные вещи. Сейчас это больше похоже на игрока. И не похоже, что он получит какое-либо широкое распространение за пределами технически склонного сообщества, которое привыкло к концепциям менеджеров пакетов.

Проблема заключается в создании среды выполнения. Вроде как JRE и .Net. Не игрок.

@baconface Может быть, вы могли бы уточнить? Непонятно, какое различие вы здесь делаете.

@baconface да, но JRE и .Net тоже можно установить.
Без JRE файлы .jar так же бесполезны, как пакеты без среды выполнения electron .

В идеале этот инструмент должен распространяться вместе с или в качестве основного метода установки электрона, что в идеале смягчит проблему распространения.

Для этого вам понадобится только крошечный инструмент для создания исполняемого файла, который будет запускать определенный файл, а именно вмененный .electron . Просто как тот.

.lept выглядит потрясающе, спасибо!

Я лично считаю, что нет необходимости изобретать какую-либо новую конфигурацию, pkg.engines выглядит здесь довольно просто (хотя она должна допускать некоторые сложные выражения semver, например, 1.x || >=2.5.0 || 5.0.0 - 7.2.3 из документации npm , поэтому нет необходимости в { recommended, compatible, etc } -структуры, как в примерах @sapioit , я полагаю). (Однако я добавил поле lepton , потому что scripts.run обычно вызывается npm start , а lepton несколько нарушает его семантику, добавляя свои собственные $VARIABLES .)

Или, если мы поместим все в 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 вы можете использовать простые сценарии оболочки (3 строки, включая #!shebang), а в Windows... ну... ¯_(ツ)_/¯

Во-первых, вы можете взглянуть на эту статью, которая предлагает лучшую альтернативу semver, но при этом совместима практически со всем: Release.Breaking.Feature.Fix или почему семантическая версия должна быть заменена явным управлением версиями как как можно скорее

Во-вторых, вопрос в том, как на самом деле их различать. Я имею в виду, что если server.js уже принимает аргумент --debug , зачем беспокоиться об этом и не позволять людям иметь свои собственные конфигурации файлов. Возможно, для сервера требуются другие конфигурации, чем для клиента, например, клиент работает на 2.2-2.4 , а сервер работает только на 1.4-1.9.2.1 ...
Делая то, что вы предложили, мы были бы только более ограничены.

Кроме того, как насчет использования большего количества переменных, а не только --debug ? Как я собираюсь запустить его с большим количеством таких переменных? Безопасно ли это делать? В конце концов, если бы я хотел, чтобы один файл делал это, я мог бы сделать это, даже имея отдельные файлы, но таким образом это портит возможные результаты запуска файла .lept с параметрами.

Если бы я хотел запустить сервер с параметром отладки, не стал бы я просто запускать .lept с аргументом --debug ? Или я мог бы создать другой файл для запуска этого файла с аргументом --debug . Разве это не так просто?
Я надеюсь, что я имею смысл...

Во-первых, вы можете взглянуть на эту статью, которая предлагает лучшую альтернативу semver.

Я думаю, что это отличная идея! Однако я не думаю, что Electron собирается перейти на эту схему управления версиями. Я также считаю, что, хотя он отлично подходит для продуктов для конечных пользователей, он нам на самом деле не нужен для библиотек, движков, сред выполнения и прочего. В идеале пользователь даже не должен знать, какую версию Electron он использует (если только он этого не хочет).

Возможно, сервер требует другой конфигурации, чем клиент.

Это может быть проблемой, но я не могу представить себе проект, которому потребуется более одной версии среды выполнения.

Если бы я хотел запустить сервер с параметром отладки, не стал бы я просто запускать .lept с аргументом --debug?

Да, почему бы не:

# 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 с двойной конфигурацией отлично подходит для случаев, когда сервер а) использует много общего кода с клиентом и б) предназначен для запуска конечными пользователями. В других случаях имеет смысл разделить все это на два репозитория/пакета, каждый со своим package.json.

Это не для Electron, а для проектов, которые вы создаете. Электрон, скорее всего, имеет свою собственную систему, основанную на семантическом версионировании, чтобы соответствовать их потребностям, и маловероятно, что они собираются ее менять, но для Лептона и других проектов, которые пока не в _ development hell _ может быть хорошей идеей вообще пропустить семантическое управление версиями.

Если бы я хотел запустить сервер с параметром отладки, не стал бы я просто запускать .lept с аргументом --debug?

Да, почему бы не:

# 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 

Но запустите .lept с аргументом --myoption=5 , не трогая файлы (помимо их открытия). Поскольку я почти уверен, что вы можете «протолкнуть» аргумент через средство запуска, вы также можете исключить необходимость в --debug , так как вы запустите его с пользовательским аргументом, если хотите.

Но в одном, я думаю, мы можем согласиться: пользователи действительно хотят иметь стабильную версию, для которой они получают поддержку. Вот почему я сделал " Релиз " отдельным номером, потому что люди вряд ли помнят много цифр, но обычно запоминают первую.

@sapioit , если поле "Release" предназначено для конечных пользователей, для чего нужны другие? Для конечного пользователя это вообще не должно иметь значения, если доступна новая версия и для нее требуется обновленная среда выполнения (через Bump в package.json), тогда среда выполнения также должна быть обновлена.

Вот проблемы:

1. Пользователи хотят знать, для какой версии им предлагается поддержка .
2. Они не хотят запоминать много _бесполезных чисел_, поэтому, если они решат запомнить версию, они с большей вероятностью запомнят версию 13 , чем версию 1.7 (например).
3. Некоторые люди не хотят обновляться до тех пор, пока не произойдут определенные вещи, например, некоторые драйверы nVidia не обновляются, потому что, поскольку была добавлена ​​​​совместимость с Thunderbolt, их видеокарты случайно извлекаются (в зависимости от пользователя / случая) , либо после загрузки компьютера, либо после запуска игры, либо через несколько минут после начала игры). Это хороший пример причины (но есть много других, таких как реклама KMPlayer или автоматические обновления locked on ), которые не позволяют пользователям использовать последнюю версию продукта. Это упрощает просмотр журнала изменений, убирая из него сложность.

Это лишь некоторые из причин... если бы вы могли вдаваться в подробности, я также мог бы вдаваться в подробности и лучше объяснять вам, почему был сделан такой выбор.

@sapioit Разве несколько диапазонов, таких как >= 12.1 , недостаточно гибки для объявления поддержки?
Если доступна новая версия среды выполнения и она удовлетворяет диапазону версий, все следующие запуски приложения должны использовать последнюю возможную среду выполнения.

Должны ли? Но что, если они решат этого не делать из-за технических ограничений (например, с рекламой KMPlayer и драйверами nVidia)?

@sapioit Тогда просто убедитесь, что вы правильно указали свой диапазон времени выполнения.

@sapioit @YurySolovyov Это обсуждение актуально здесь? Менеджер среды выполнения должен следовать любой системе управления версиями, которую использует электрон. Я считаю, что обсуждение того, какую систему управления версиями _должен_ использовать электрон, относится к другому вопросу.

@Tribex несколько. Я пытался сказать, что мы не должны слишком усложнять вещи, которые уже в основном решены. Но я согласен с тем, что менеджер времени выполнения должен делать в этом отношении простейшую возможную вещь.

@yurysolovyov Так почему бы просто не разрешить столько разделов в номере версии, сколько хочет игрок?

@сапиоит

Это не для Electron, а для проектов, которые вы создаете.

У Lepton нет назначенной схемы управления версиями (пока), а пакеты (приложения) могут использовать любую схему управления версиями, которую они хотят. Нам нужно справиться с этим (например, если мы хотим поддерживать обновление приложений через сам Lepton).

В идеале среды выполнения должны использовать semver, так как они не являются продуктами, но опять же, теперь поддерживается любое трехзначное управление версиями (однако разработчикам следует быть осторожными с указанием диапазонов). Если нам когда-нибудь понадобится поддерживать более 3 чисел (как в вашем предложении по явному управлению версиями), нам потребуется расширить синтаксический анализатор (для Python я предлагаю разветвить k-bx/python-semver или podhmo/python-semver — первое обновился совсем недавно, в то время как первый более точно следует API node-semver, и это то, что я сейчас использую).

Могу я просто сказать, что наличие менеджера пакетов во время выполнения, написанного на python для проекта nodejs, — это просто плохая идея.
Просто давайте не будем этого делать. Как бы это ни называлось, лептон или как-то так. Давайте напишем это в узле или воспользуемся чем-то другим. И давайте не будем спамить эту проблему ненужными письмами о том, как вы думаете, что знаете лучше, чем хорошо продуманная схема семантического управления версиями.

@championswimmer Было бы интересно создать менеджер времени выполнения с упакованной версией электрона и пользовательским интерфейсом, показывающим, когда загружаются другие версии.

@championswimmer iamale/lepton — своего рода одноразовая эталонная реализация: я просто поместил ее, чтобы проверить различные идеи, витающие в этой теме, не более того.

@iamale , может быть, вам следует указать это в файле readme, чтобы избежать путаницы?

@YurySolovyov Готово!

Что касается реальной реализации, то у нас есть два варианта: либо мы используем node.js, либо компилируемый язык, такой как C/++ или Go; а для узла нам пришлось бы связать с ним node.js (или, может быть, просто запустить его на одном из загруженных экземпляров электрона? Однако нам нужно убедиться, что он работает на _любой_ нормальной электронной версии).

@iamale Не совсем, нам просто нужно запустить версию, установленную по умолчанию. После этого обновления могут переключить его на более новую версию на месте.

Я бы предпочел использовать одну определенную версию, потому что при необходимости все можно обновить...

Лептон может быть не таким уж хорошим именем сейчас, когда это формат изображения .

Итак... как мы теперь это называем? Hadron ?

Кварк? Если кто-то хочет взять имя «Мюон», я могу переименовать один из своих проектов.

Разве именование не является наименее важной частью здесь?
Согласовали ли мы семантику установки/обновления/времени выполнения?

Почему бы просто не electron ...

Оп 15 июл. 2016 г., 13:22, Джошуа Бемендерфер, [email protected] , а затем сообщение:

Кварк? Если кто-то хочет взять имя «Мюон», я могу переименовать один из своих проектов.

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub или закройте ветку.

@yurisolovyov Думаю, мы договорились... более или менее.
@ job-v Это то, что я всегда предлагал. Просто давайте выберем один и придерживаемся его.

@zcbenz ты наблюдаешь за этой веткой?
Если это так, было бы неплохо иметь некоторое представление о том, как это должно работать, чтобы получить некоторые указания здесь.

Привет
какие-либо обновления об этой электронной среде выполнения ?
@zcbenz , что вы думаете обо всех дискуссиях о:

• выбор электронной версии
• установка подходящей версии
• подготовьте его для работы в win, linux, mac
• какой инструмент использовать для сборки (python, node, go, c++)?
  @YurySolovyov @sapioit спасибо за классные идеи
  @iamale - это ваше решение для destros на основе Debian '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 Я думаю, что сделайте электрон как пакет deb и используйте его в качестве зависимостей в приложении, которое будет установлено вручную или из центрального репозитория для многих пакетов deb электронной версии.
а затем использовать этот пакет после установки для запуска пользовательского приложения

Если кто-то начнет работать над чем-то для этого, может быть, ссылка на это здесь...

@sapioit Я начал работать над решением для Linux (APT/RPM). Простой сервис, в который вы загружаете .asar, и он преобразуется в пакеты и добавляется в репозитории. Должна быть возможность расширения на Windows и macOS, но пока никаких обещаний.

@iamale Круто! Дайте мне знать, когда вы заработаете на окнах.

Как насчет создания среды выполнения Flatpak для Linux? Таким образом, среда выполнения может быть разделена между несколькими приложениями, и вы также получаете песочницу.

После того, как Flatpak уберет свою зависимость от systemd , он, вероятно, станет универсальным в Linux для упаковки исходных пакетов.

среда выполнения может быть разделена между несколькими приложениями

Я думал, что с Flatpak это невозможно?..

@iamale Flatpak предназначен для совместного использования сред выполнения — разработчики приложений выбирают среду выполнения, устанавливают SDK для этой среды выполнения, а затем создают приложение с flatpak-builder или аналогичным. Затем, когда пользователь устанавливает приложение, Flatpak устанавливает соответствующую среду выполнения.

@moosingin3space Спасибо за объяснение! Тогда точно стоит задуматься.

Еще одна вещь, которая мне нравится в Flatpak, это то, что он был разработан для варианта использования, когда пользователь добавляет репозиторий, запускаемый разработчиком среды выполнения и разработчиком приложения (прозрачно), и это делает обновления автоматическими.

Единственные проблемы, которые я вижу, связаны с безопасностью — необходимо изменить системные библиотеки, чтобы использовать интерфейс «порталов» в Flatpak, чтобы обеспечить безопасный выход из песочницы.

Кажется, здесь есть работа над Flatpak: https://github.com/endlessm/electron-installer-flatpak

В качестве примечания, Flatpak основан на проекте OSTree , который выполняет адресацию содержимого для деревьев файловой системы. Это означает, что файлы с идентичными контрольными суммами автоматически дедуплицируются на диске, а обновления выполняются с использованием статических дельт. Это означает, что не только Electron может предоставить общую среду выполнения, которую можно независимо обновлять и совместно использовать между приложениями, но также и то, что приложения, созданные на основе идентичных файлов, будут автоматически совместно использовать их на диске, и что после установки приложения и/или среды выполнения обновления не требует полной загрузки.

Простите меня, если это немного наивно, мне интересно, рассматривалась ли возможность создания среды рабочего стола как естественного логического развития среды выполнения. Идея состоит в том, что существует приложение запуска, которое электрон загружает при запуске (вместо, скажем, атома) с возможностью запуска других электронных приложений (учитывая большую растущую библиотеку), создавая новые экземпляры средства визуализации или, возможно, даже повторно используя его и имея приложения открываются в новой вкладке.

Хром как и в ОС в моем понимании кажется именно таким (но ограничиваясь веб-приложениями). Наличие настольных приложений с полным доступом к fs через nodejs (в отличие от ограничений chromeAPI) с электроном в качестве среды выполнения поверх Linux (или даже замена или, по крайней мере, расширение в начале explorer.exe в Windows) было бы очень интересно имхо. Я думаю, что это более чистое решение, чем ChromeOS, которое загружает то, что фактически является средой выполнения, а затем движком браузера, а затем размещает приложение - здесь приложения будут загружаться непосредственно во время выполнения, а сам браузер будет просто еще одним приложением (и есть так много инновационных проектов электронных браузеров в дикой природе).

Опять же, мне интересно, рассматривалось ли это или уже есть какой-то проект, делающий это. Если нет, то, возможно, фея может сказать слово руководству Github за то, что оно взяло на себя инициативу????

PS: Одна вещь, которую я здесь не предлагаю, — это перенос OS.js (который сам по себе является симпатичным небольшим проектом) на электронный, но создание среды для электронных приложений (хотя я был бы не против повторного использования кода из OS.js).
PPS: Я создам отдельную проблему, если она будет сочтена достаточно достойной или если она отвлечет внимание на проблему среды выполнения.

Я действительно думаю, что встроенная среда выполнения сделает приложения Electron намного лучше. Я думаю, что для их упаковки нужно просто заархивировать файлы и переименовать расширение в asar , но в этом архиве должны быть две папки, одна из которых называется asar , с содержимым папки среды выполнения по умолчанию, а другая называется enviroment с файлами, которые должны перезаписывать конфигурацию по умолчанию.

Например, запуск нового приложения скопирует требуемую версию Electron во временную папку и переместит среду выполнения (содержимое папки asar ) в расположение файлов по умолчанию, в то время как необязательная папка enviroment (с 3 подпапками, windows , linux , macosx ) должны содержать файлы, которые будут вставлены в папку по умолчанию, перезаписывая ее содержимое.

Таким образом, нам нужно только приложение или что-то еще, чтобы оценить расширение .asar для приложения и предоставить этому приложению доступ к папке с загруженными версиями Electron (в архиве), скопировать (извлечь) их во временную папку. , и используйте содержимое .asar , чтобы изменить то, что необходимо, затем запустите экземпляр Electron из этой временной папки и подождите, пока он не умрет, чтобы принудительно удалить временную папку. Во-первых, даже заставить конфигурацию по умолчанию работать с архивом с пользовательским расширением во всех поддерживаемых операционных системах будет намного больше, чем у нас уже есть. После этого мы можем беспокоиться о наличии третьей папки, config , где хранятся текущие настройки конфигурации, и, возможно, папки _config внутри нее для настроек конфигурации по умолчанию (если они нам нужны). ).

Поскольку пакетные приложения Chrome скоро будут прекращены, люди будут искать альтернативы. Среда выполнения была бы отличной для тех небольших проектов, для которых не всегда будут доступны сборки/выпуски. Поскольку приложения создаются с использованием веб-технологий, как и приложения Chrome, для пользователя было бы полезно просто запустить приложение из исходного кода. Я не могу оправдать портирование бесчисленных второстепенных проектов на Electron, если единственный способ, с помощью которого пользователь может их запустить, — это загрузить большой двоичный выпуск для каждого отдельного скрипта или приложения, а пользователи не могут воспользоваться преимуществами запуска последней фиксации без ее сборки или загрузки Electron. Сами IDE.

Привет всем, даже если я не в JS-ориентированном мире, у меня недавно была идея, очень похожая на _Электрон_ (который я случайно знал, но не использовал для разработки), но с более широкой аудиторией; выражаясь очень просто: _просто ограничьте веб-технологии графическим интерфейсом и предоставьте API._

Так что продолжайте работать с разделяемой библиотекой/средой выполнения с семантическими версиями (построенной поверх _Blink_, _Skia_ и т. д.; возможно, в «современном» — _C++_) и позвольте разработчикам выбирать язык с помощью привязок…
например, вы хотите _JS_, используйте _Node.JS_; вы хотите _C++_, нет проблем; вы хотите _Python_ со стандартным _CPython_ должно быть возможно; что-нибудь еще ? возможно, _SWIG_ может помочь. В (почти) любом случае мы выиграем.

Когда у нас есть общая (зависимая от ОС) библиотека/среда выполнения, вы решаете основную проблему и можете разработать любой способ, который, по вашему мнению, лучше всего доставить остальным (кроме революционного/модернизированного подхода к программированию с графическим интерфейсом для остальных из нас; огромный шаг вперед!)

Так что отправной точкой должен быть "сплит" (даже название, связанное с физикой, учитывая тот факт, что вы, кажется, действительно заботитесь о нем) проекта _Электрон_… :)

Мы даже не можем сделать аддон для Electron, но я думаю, что он не будет иметь такого большого успеха, если только не будет много рекламы.

@dezzeus Над этой строкой была попытка, которая провалилась. Взгляните на среду выполнения Throw , предназначенную для размещения браузера взлома .

Я прочитал эту длинную и увлекательную ветку дважды, так как хотел бы увидеть больше импульса в этом направлении. Вот последнее заявление @zcbenz , я считаю, что оно все еще актуально:

Нет никаких технических препятствий для реализации этого, все это может быть просто приложением Electron. Но проблема в том, что это тоже непросто реализовать, принимая во внимание все детали, я думаю, что _это требует небольшой команды, работающей над этим полный рабочий день_, я не уверен, что это когда-нибудь произойдет.

(Добавленный акцент) — Как я это интерпретирую, если решение когда-либо будет создано, это будет зависеть от усилий сообщества и / или бизнес-потребностей GitHub и других организаций, заинтересованных в нем.

Краткий обзор @yan-foto выглядит как разумный план действий с четкими целями/требованиями. Существует эталонная реализация/прототип под названием lepton от @iamale , предлагающая «универсальный менеджер версий среды выполнения», ориентированный на Electron. Комментарий @jorangreef был интригующим, поскольку он описывает «приложение в производстве с механизмом автообновления semver», с дифференциальным обновлением, дедупликацией (не уверен, что это одно и то же) и сжатием. Многие из описанных им функций казались идеальными для адаптации/принятия.

Это определенные шаги исследования и прогресса, и это вселяет в меня надежду, что в результате этого процесса родятся пригодные для производства общие решения.

Приятно видеть, что есть еще люди, верящие в человечество.

Единственное, что мешает этому стать продуктом, — это отсутствие непосредственных возможностей для бизнеса, открывающихся при создании этого продукта (концепции).

@eliot-akira да, так оно и есть. Код, который я написал, выполняет дедупликацию на основе содержимого каждого файла (фрагменты переменного размера) в файле, чтобы свести к минимуму загрузки, когда изменяется всего несколько байтов в файле. Он также обновляет только те файлы, которые меняются между версиями, и обновления приложения в целом являются атомарными перед лицом любых ошибок. Либо запустится новая версия, либо останется старая версия.

Я хотел бы открыть исходный код, и есть некоторые вещи, которые мне все еще нужно закодировать для общей идеи. Было бы здорово, если бы несколько приложений Electron могли совместно использовать один процесс супервизора автоматического обновления (с локальным общим неизменяемым кешем для дедупликации в нескольких независимых приложениях Electron).

Целью всего этого подхода будет минимизация общей пропускной способности загрузки, необходимой для установки и обновления приложений Electron, при этом приложения Electron будут полностью изолированы друг от друга (несколько приложений будут иметь свои собственные двоичные файлы Electron). Нецелью было бы минимизировать занимаемую площадь на диске.

Первая установка приложения Electron должна быть загружена полностью, но последующие установки приложения Electron выиграют от локального общего неизменного кеша.

Поскольку дело дошло до автоматического обновления, я должен указать на проблему управления версиями и тот факт, что несколько систем управления версиями, похоже, используют разное количество цифр для управления версиями. Я, например, использую Explicit Versioning .

У нас есть два типа вещей, которые необходимо обновить здесь:

• Сам Electron, который использует Electron Versioning и
• Приложения, для которых нам не нужно заботиться о SemVer или чем-то еще, поскольку они, как правило, не имеют API (если только они, возможно, не используют какую-то систему дополнений).

Хотя, если нам нужно поддерживать несколько систем управления версиями, может быть, мы могли бы иметь некоторые настройки в package.json , например, "breakingVersionComponents": 1 для semver и 2 для явного управления версиями или электронного управления версиями?

(Еще один вариант — добавить еще один разделитель в версию, например 1.3:3.7 , который будет разделять неразрывные и неразрывные части. Тогда Semver станет x:y.z , а Electron Versioning x.y:z . Это будет хотя, я полагаю, сломайте каждый инструмент там.)

@jorangreef Если каждое приложение по-прежнему имеет свой собственный двоичный файл Electron, это не решит проблему избыточного использования ОЗУ при открытии нескольких приложений Electron.

Я заметил старый комментарий @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, который представляет собой другую модель, чем я думал), я вижу, что люди уже создают свои собственные конкретные решения проблемы общей среды выполнения, которые также предоставляют функции какого- либо средства запуска/менеджера приложений . Было бы здорово увидеть некоторую конвергенцию, выделить некоторые из упомянутых функций в модули общего назначения.

Интересно, существуют ли существующие модули, не относящиеся к Electron, которые можно было бы использовать, например, механизм загрузки: сервер среды выполнения, управление версиями, дифференциальные обновления. Кажется немного сложным создавать все это с нуля, если другие уже «решили» некоторые из этих областей. @iamale , спасибо за вашу работу над Lepton , на мой взгляд, это конкретная реализация в направлении решения.

Еще одна идея: просто публиковать приложения в npm и делать специальную оболочку npm, которая сможет их устанавливать и запускать. Тогда было бы очень легко развернуть и, вероятно, легко использовать (хотя это зависит от качества оболочки). Что вы думаете, ребята?

Для проектов oss мы могли бы использовать npm в качестве хостинга, для проектов с закрытым исходным кодом нам нужно иметь возможность указать диспетчеру пакетов на файл .asar для загрузки и, возможно, некоторые другие метаданные. Вопрос в том, как этот добрый менеджер будет выглядеть (и называться)

Кроме того, мне интересно, действительно ли нам нужна отдельная команда для установки приложений, может быть, просто
electron install atom будет достаточно?

Только что видел это на Node Weekly:

Electrino — это экспериментальная полулегкая альтернатива популярному и мощному Electron. Он реализует незначительную часть API, доступных в Electron, но размер выходного приложения намного меньше.

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

https://github.com/pojala/электрино

@YurySolovyov Проекты с закрытым исходным кодом также не должны иметь проблем с публикацией в npm — уже есть несколько проектов Node.js, например, enclose . (Технически это не npm, а просто загрузчик, но я все равно не понимаю, как загрузка .asar неопубликованных файлов может помочь, поскольку их все еще можно распаковать.)

Я просто пытался подумать, как мы можем повторно использовать как можно больше существующей экосистемы.

Не уверен, что мы хотим...

@jorangreef Если каждое приложение по-прежнему имеет свой собственный двоичный файл Electron, это не решит проблему избыточного использования ОЗУ при открытии нескольких приложений Electron.

@ Jop-V Нет, не будет. Я не хочу смешивать вещи и в итоге получить монстра. Идея состоит в том, чтобы иметь отличный установщик/автообновитель, который решает большинство проблем в комментарии, который открыл эту проблему: https://github.com/electron/electron/issues/673#issue -44580957.

Проблема заключается не столько в наличии нескольких двоичных файлов на диске, сколько в том, что пользователю приходится загружать и автоматически обновлять несколько копий одного и того же двоичного файла.

Тем не менее, решение проблемы использования памяти определенно стоит того. Я думаю, что есть множество способов сделать это, но они не обязательно должны быть связаны с дедуплицирующим установщиком/автообновителем.

Если размер диска также является проблемой, ее можно решить с помощью жестких ссылок в системах, которые ее поддерживают, хотя это начнет нарушать идею изоляции между приложениями (например, если одно приложение решит записать в жесткую ссылку, совместно используемую с чем-то другим).

В качестве альтернативы, по крайней мере, в macOS в среднесрочной перспективе APFS будет копировать файлы по ссылке с прозрачной дедупликацией под капотом, сводя к минимуму занимаемую площадь на диске. Это было бы лучше, чем жесткие ссылки, поскольку сохраняло бы изоляцию (копирование при записи).

@jorangreef Какой смысл использовать отдельные двоичные файлы Electron для приложений? О какой изоляции вы говорите? Извините, если это глупый вопрос, но я просто не понимаю.

@iamale Некоторые приложения могут быть нацелены на разные официальные версии Electron или могут распространять предварительно собранный Electron, скомпилированный из модифицированных источников. Этот подход будет работать со всеми ними. Даже при значительных различиях в двоичных файлах (в отличие от изменений JS и ресурсов) дедупликация устранит 70% или более требований к загрузке, поэтому приложения, предназначенные для разных двоичных файлов, все равно будут в выигрыше.

При таком подходе можно даже отправить любой пакет (любой набор файлов и каталогов, определенный манифестом JSON), не обязательно только приложения Electron. Это также может быть приложение Python. Это не зависит от любого выбора, который разработчик хочет сделать в отношении того, как он структурирует или упаковывает свое приложение (файлы против asar и т. д.).

Основная идея заключается в том, что экосистема выигрывает от очень небольших дельт установки/обновления, поскольку все больше и больше приложений используют один и тот же установщик/автообновитель. В наши дни каждое приложение работает со своим собственным супервизорным автоматическим обновлением, и в этом нет необходимости.

@jorangreef Спасибо! Я предполагаю, что это очень похоже на классические репозитории APT/RPM, просто более «умные» (не нужно объявлять свои зависимости или что-то в этом роде).

Вопрос в том, как этот добрый менеджер будет выглядеть (и называться)

А как насчет Minifitron (уменьшенный электрон)?

Я думаю, что файл архива (т.е. .asar ) должен содержать содержимое папки, в которой находится бинарный файл электрона, чтобы мы могли добавлять или заменять файлы, которые отклоняются от стандарта. У нас будет каждая версия в папке или архиве, и мы скопируем ее в новую временную папку на время ее запуска.

И должна быть возможность установить или минимизировать приложения, установка оставит их как новый экземпляр электрона, в то время как минифицированный будет использовать md5 для удаления файлов, которые не были изменены при разархивировании .asar (или то, что мы будем использовать) и заархивировать его обратно и заменить исходный файл в качестве обновленного состояния используемого нами приложения.

Просто чтобы добавить еще одну идею: что, если бы каждое приложение Electron содержало свои собственные копии сред выполнения, но при запуске они могли бы проверить, существует ли уже запущенный экземпляр Electron (и его версия) - если он совместим (в пределах диапазона semver). и т. д.), приложение могло бы взаимодействовать с ним и использовать тот же экземпляр; если несовместимо, то приложение может запустить свой собственный экземпляр Electron. Казалось бы, это решает проблему уменьшения объема памяти.

(Опять же, к тому времени, когда приложение будет запущено, я думаю, что в любом случае уже будет несколько экземпляров среды выполнения.. так что это может быть нелогично..)

@eliot-akira У меня была очень похожая идея при чтении этой темы.

(Опять же, к тому времени, когда приложение будет запущено, я думаю, что в любом случае уже будет несколько экземпляров среды выполнения.. так что это может быть нелогично..)

Что ж, он может загрузить достаточно, чтобы проверить это, и после того, как он увидит, что нет доступного «электронного помощника», с которым можно было бы разделить время выполнения, загрузить остальное.

Однако это создаст много проблем с безопасностью. Вредоносное приложение может предложить измененную версию среды выполнения другим пользователям и получить доступ к их данным. Возможно, он мог бы использовать сегмент общей памяти, сделать его доступным только для чтения, а «пользовательские» приложения (которые используют среду выполнения ранее запущенного приложения) могли бы контролировать время выполнения, но разработка их для всех целевых ОС может быть кошмаром ( Я даже не знаю, существует ли это в Windows; я предполагаю, что это должно быть).

Если только ради любопытства, разве это бессмысленно? Будет ли это столько же или может быть намного больше работы, чем отдельная общая среда выполнения? Создает ли это другие дополнительные проблемы?

ДОБАВЛЕНО ПОЗЖЕ: Это может быть далеко, но существуют технологии для дедупликации идентичных страниц в ОЗУ; они используются в основном в средах виртуализации и гипервизорах. Это первое, о чем я подумал и побежал проверить, используют ли это современные операционные системы, и тогда, возможно, будет способ настроить электрон таким образом, чтобы эта функция могла быть использована, но, по-видимому, нет.

@jorangreef Если разработчик изменил двоичный файл Electron, разве он не должен просто создать запрос на включение?

@ Jop-V Они могут, но они также могут поддерживать свою собственную вилку. Они могут даже не публиковать исходники, если не хотят — лицензия MIT не накладывает на них никаких обязательств.

@jkurei Чтобы глубже изучить эту идею, я представляю несколько способов, которые могут работать:

1) Тонкая нативная обертка вокруг Электрона или самого приложения, которое будет "лаунчером". Он проверяет уже запущенный экземпляр Electron и его версию: если он совместим, передает остальную часть процесса запуска этому экземпляру и завершает работу; если нет, продолжайте запускать собственный экземпляр Electron.

2) Библиотека JavaScript, которую сами приложения могут импортировать в основной процесс в качестве лаунчера. Он может реализовать протокол, аналогичный приведенному выше: транслировать существование экземпляра Electron и способ для других приложений (использующих ту же библиотеку) найти его и связаться с ним - может быть, через сетевой порт..?

@ eliot-akira Кстати, я думаю, что уже есть какой-то примитивный «протокол», о котором вы говорите; это то, что стоит за app.makeSingleInstance , которое каким-то образом обнаруживает уже запущенные процессы Electron и являются ли они одним и тем же приложением или нет (возможно, путем получения полного пути к исполняемому файлу).

@iamale Я вижу, метод использует собственный класс Chromium ProcessSingleton для регистрации текущего каталога приложения (в качестве уникального идентификатора?). Да, я представлял себе что-то подобное, чтобы оно было инициализировано до app.on('ready') . Таким образом, вместо того, чтобы просто проверять существующий экземпляр этого конкретного приложения, он может проверять любой экземпляр Electron, а затем «передавать процесс запуска», если он совместим.

С другой стороны, я нашел модуль под названием node-ipc , который может взаимодействовать между отдельными процессами Node.js. Возможно, это можно использовать для управления процессом запуска исключительно на уровне JS.

Вот базовый пример совместного использования одного экземпляра Electron несколькими приложениями с использованием node-ipc для межпроцессного взаимодействия: https://github.com/eliot-akira/singletron-example.

Концентратор IPC — это собственный модуль , тонкая оболочка вокруг node-ipc . Его инициализация находится в основном процессе, main.js внизу .

При запуске приложение сначала попытается подключиться к существующему экземпляру Electron. Если его нет, он запустит «сервер», который прослушивает запросы между процессами. Любые последующие экземпляры приложения будут подключаться к первому экземпляру, получать его «конфиг» (версии Chrome, Node, Electron) и смогут обмениваться сообщениями, например, для запроса нового окна для себя.

Это наивная реализация для начала, но что мне нравится в этом подходе, так это то, что приложение должно обрабатывать то, как сервер/клиенты должны договариваться: проверка совместимости, открывать ли новые окна, передавать другую конфигурацию и т. д.

@eliot-akira Я думаю, что указание идентификатора сервера по умолчанию - это _действительно-действительно-плохая_ идея на данный момент: если кто-то начнет использовать это в своих целях, он, вероятно, просто изменит ваш примерный код для своих нужд и нарушит протокол ( таким образом ломая другие приложения, полагающиеся на это).

Кроме того, выглядит хорошо и чисто, спасибо!

Re: проблемы безопасности: приложения Electron уже работают с правами пользователя, и если мы поместим их в одно дерево процессов, они действительно будут иметь (или смогут получить) доступ к другим экземплярам Electron. Тем не менее, я думаю, что если мы собираемся смягчить это, каждый, кто может предоставить пропатченный экземпляр Electron, определенно не поможет.

@iamale Спасибо за отзыв. Я предоставил возможность установить идентификатор сервера на случай, если некоторые приложения захотят реализовать свой собственный протокол, а не общий для всех приложений Electron. На самом деле, такого общего протокола еще нет, поэтому на данный момент для этой цели нецелесообразно, чтобы неизвестные приложения подключались и передавали процесс запуска. Это должно было быть доказательством концепции, поэтому я обновлю документ, чтобы упомянуть об этом. Я буду продолжать изучать, как сделать его более практичным.

Я думаю, что вновь прибывшим людям было бы полезно иметь какое-то резюме, похожее на то, которое кто-то делал полгода назад.

Кроме того, что делает конечный пользователь?

Если бы я был конечным пользователем (а частично я им являюсь), я бы хотел один-единственный пакет .exe/.app/.deb, который работает как установщик PortableApps.net. Этот исполняемый файл должен быть небольшим и автоматически загружать последнюю обновленную версию программного обеспечения вместе со средой выполнения, если она не была установлена. В простом процессе настройки я должен иметь возможность вручную установить «местоположение во время выполнения» (используя флажок «Дополнительные параметры») вместе с флажками для создания системных ссылок (Рабочий стол, меню «Пуск» и т. д.).

Когда я загружаю следующее программное обеспечение, предыдущая среда выполнения (как бы она ни выглядела, idc) должна быть повторно использована, если это возможно.

Как разработчик, я хотел бы иметь возможность создать такой загружаемый пакет (в лучшем случае) одним щелчком мыши. Этот один щелчок должен загрузить мой код в какой-нибудь репозиторий (похожий на play/web/app store) и создать для меня пакет .exe/.app/.deb, которым я могу поделиться со всем миром.

Я еще не так сильно связан с Electron, так как я просто создаю небольшой установщик модов, используя Electron и Electron-Edge для C#.

Я могу быть наивным, но, на самом деле, единственная «настоящая» причина, по которой вещи несовместимы с версиями +-0.1, заключается в том, что файлы .node должны быть пересобраны для каждой версии Electron. Нельзя ли создать эти файлы .node во время установки с помощью какого-либо облачного решения?

Кроме того, действительно ли будет так уж сложно создавать один большой Electron LTS каждые полгода или около того? Я сомневаюсь, что разработчики на самом деле используют все передовые функции каждого нового выпуска Electron, поэтому, если мы (как бы) заставим их дольше придерживаться одной версии, это действительно сильно упростит задачу.

Имо, единственная проблема заключается в том, что LTS-версия Electron не готова для всех.

С этой версией lts создание автообновления, дедупликации, управления версиями и всего остального должно быть проще простого.

Предложенное мной решение для установщика также имеет дополнительное преимущество: пользователь на самом деле не видит папку с программным обеспечением, поэтому нам не нужно упаковывать его как .whatever и говорить ему переместить его в безопасное место. Кроме того, во время установки можно добавить несколько «подисполняемых файлов» (например, для многопользовательских игр, нескольких «профилей» и т. д.). Эти исполняемые файлы должны называться просто somelaunchername.electron, но в формате Json с информацией о том, как запускать программное обеспечение (например, какой index.html загружать и тому подобное). node_modules должны быть общими для исполняемых файлов (если только разработчику НЕ НУЖНО использовать разные версии модуля для каждого исполняемого файла). Этого можно добиться, имея три папки node_modules. Один для каждого исполняемого файла и один для обоих. В package.json будет только общая информация. Каждый файл .electron должен (imo) иметь возможность перезаписывать значения в package.json.

Затем эти файлы .electron можно было добавить в меню «Пуск» и в другие места с помощью «runtime --appname» или специального протокола, такого как steam. Не уверен, какой из них лучше, но паровой меня несколько раз бесил в прошлом.

Теперь, если разработчик действительно хочет выпустить модифицированную среду выполнения, он все равно может упаковать ее так, как это делается сейчас.

Заключить:
На мой взгляд, следующим шагом будет создание стабильной версии lts и привлечение разработчиков к работе, предоставив им простое решение для упаковки. Процесс установки может быть улучшен позже, в настоящее время достаточно загрузить среду выполнения и лаунчер для этих файлов .electron.

Что вы ребята думаете?

Электронный конструктор @CiriousJoker может создать портативное приложение и веб-установщик. Насколько я вижу, в Windows общая DLL - это решение. Общая библиотека DLL также поддерживает подсчет ссылок для автоматического удаления неиспользуемой среды выполнения электронов. В настоящее время среда выполнения электрона на окнах представляет собой один большой исполняемый файл (кроме node.dll). Если его можно разделить на dll, решение на стороне электронного сборщика реализовать довольно просто. Это также сэкономит память, а не только место на диске.

@zcbenz @paulcbetts Рассматривали ли вы возможность использования общей dll? Можно ли уменьшить размер exe и переместить весь электронный код в dll (таким образом, оставить только минимальный код в exe)? Круто, что, поскольку общая среда выполнения C для электрона 1.7.5 удалена из node.dll и exe. Сейчас в DLL-файлах уже 30 МБ кода (но exe все равно большой — 80 МБ), так что можно начинать с ним экспериментировать.

@develar imo, настоящая проблема не в том, как мы можем обмениваться dll, а в том, как мы можем получить lts-версию электрона

Делает ли Chromium исправления безопасности для более старых версий? У меня есть сильное ощущение, что их политика заключается в том, чтобы «обновить до последней версии, чтобы быть в безопасности». Без обновлений безопасности от Chromium до LTS Electron, похоже, далеко.

@ sedwards2009 Но действительно ли так много угроз? Конечно, я могу быть здесь наивным, но мы защищаем пользователей не от открытого интернета, а от (в основном) локальных приложений. Запуск любого .exe-файла в 10 000 раз опаснее, а написание .exe-вирусов также в 10 000 раз проще, когда даже установщик моего законного электронного приложения был назван AVG вирусом.

Так что для меня достаточно «обновлять» эту безопасность каждые 6 месяцев или около того. Кроме того, более небезопасно позволять каждому разработчику использовать свою собственную упакованную версию хрома, в любом случае они могут причинить больше вреда, чем мы не можем предотвратить (с общей средой выполнения или иным образом).

Да, безопасность заканчивается там, где приложение получает прямой доступ к файловой системе и сети.
Вы либо доверяете поставщику приложения, либо держитесь подальше. <- это для приложений с закрытым исходным кодом.
Для OSS лучше, большинство из них хотя бы не имеют плохих намерений, но могут содержать баги.

Итак, как легко получить версию lts? Нельзя ли просто выбрать текущую версию и объявить ее lts-версией?

Более серьезная проблема, вероятно, возникнет позже, когда мы попытаемся убедить разработчиков создавать свои приложения для этой конкретной версии, но в любом случае это последний шаг. Для создания общей среды выполнения нам просто нужно сначала выбрать среду выполнения.

Я бы сказал, что это должно быть решение разработчика - выяснить, над какими версиями среды выполнения должно работать приложение.
Вроде как поле двигателей npm .
Работа среды выполнения здесь состоит в том, чтобы получить необходимую dll или что-то еще и разрешить запуск приложения.

Но если мы позволим им выбрать одну из десятков почти одинаковых несовместимых сред выполнения, мы полностью упустим суть, не так ли? Мы пытаемся избежать использования нескольких сред выполнения, а не просто их дедупликации. Как кто-то упомянул где-то в начале, дедупликация среды выполнения не имеет особого смысла, когда существует вероятность 1 из 20, что одна и та же среда выполнения будет снова использоваться в той же системе.

Или вы имеете в виду, что у нас есть большая часть среды выполнения, и мы просто переключаем разные части по мере необходимости? Это имело бы смысл, но я думаю, что это сложно реализовать

Я не понимаю, как можно разделить время выполнения, основными потребителями размера являются Chromium и Node, которые тесно интегрированы, и я сомневаюсь, что их можно заставить работать более чем с одной версией друг друга.

Я думаю, что в узле было что-то вроде этого:

• некоторые разработчики хотели последнюю версию v8 и были в порядке, чтобы терпеть поломку
• крупные компании хотели стабильности и долгосрочной поддержки.

Я не уверен, что у электронной команды достаточно ресурсов для поддержки обоих, но я могу ошибаться.
В любом случае, это не противоречит диапазонам версий, просто нужно указать, какие версии являются «LTS».

Что ж, если бы все электронные приложения использовали одну и ту же среду выполнения и поставлялись только с пакетом .asar, специально созданным для этой среды выполнения, все бы сработало, не так ли?

Да, но вы хотите время от времени обновлять Chrome и Node, верно?

Да, но я мог бы жить с одним и тем же узлом/хромом в течение 6 месяцев. В любом случае у Node есть LTS-версия, и chrome не сильно отличается от того, что я заметил. Имо, преимущество экономии 100 МБ при каждой установке приложения компенсирует небольшое увеличение скорости время от времени после выхода новой версии Chromium / Electron. Кроме того, как только мы привлекли разработчиков, не должно быть слишком сложно сократить время между новыми версиями среды выполнения. Затем мы могли бы поддерживать последнюю версию среды выполнения и одну или две более старые версии.

Я думаю, восстановление файлов .node каждые 6 месяцев не должно быть слишком сложным.

Electron-builder будет поддерживать новую опцию для всех целей nsis — useSharedElectronRuntime. Пока все существующие dll будут, думаю можно уменьшить размер exe и переместить код в dll, но это можно сделать и позже, экономия 30Мб это уже хорошая цель.

1. Создайте подписанную сборку для всех электронных dll и опубликуйте в выпусках GitHub (bintray не вариант, потому что ненадежен).
2. Установщик Nsis загрузит и установит сборку, если она еще не установлена. Безопасность — сборка подписана. Electron-builder также поддерживает установку на машину. А Windows обеспечивает дополнительный уровень безопасности, если сборка установлена ​​на машину, так что при необходимости вы можете ее включить. В любом случае будет добавлена ​​дополнительная опция для установки сборки на машину. Пока не ясно — должно ли оно быть по умолчанию true или false. Я думаю, что это неверно, чтобы убедиться, что по умолчанию электронное приложение может быть установлено без администратора.
3. не нужно беспокоиться о неиспользуемом времени выполнения электрона — общая dll поддерживает подсчет ссылок. При удалении приложения сборка будет удалена, и Windows удалит ее, если ее больше не используют другие приложения.

@CiriousJoker Re: безопасность. Я не думал о проблемах с безопасностью, поскольку само приложение является вредоносным. Я думал об электронных приложениях, которые высасывают и используют ненадежный контент. то есть каждый раз, когда электронное приложение показывает веб-страницу из открытой сети в webview или аналогичном.

Многие приложения не выставляют себя в открытую сеть, и они вполне могли бы работать на более старом электроне. Но другая крайность — это что-то вроде Brave, который как веб-браузер не делает ничего, кроме раскрытия себя. :-)

@sedwards2009 да, но если мы начнем заботиться обо всех и их мамах, мы не добьемся никакого прогресса. Всегда будут причины что-то не делать. Отсутствие 100% разработчиков — это просто жертва, на которую мы должны пойти. Если им действительно нужна/хотят безопасность, они могут получить ее вручную.

Что касается выбора LTS, то наиболее разумным выбором будет привязать себя к Nodejs LTS, т.е. любая версия электрона, соответствующая узлу LTS, фактически является электронной LTS. Это могло бы принести некоторую гармонию и согласие, чтобы мы могли двигаться вперед коллективно и иметь некоторую уверенность, а не оставлять это как свободный выбор (что отрицает это сообщество) или спорить (что нас никуда не ведет).

@CxRes Но какую версию Electron мы поддерживаем? В моем проекте основная проблема заключалась в том, чтобы пересобрать файлы .node для конкретной версии Electron (не Node).

Мы могли бы просто установить новейшую версию Electron в качестве lts или использовать наиболее широко используемую.

Я что-то упустил здесь? Имо, проблема в Электроне, а не в узле

Хорошо, позвольте мне попытаться объяснить это еще раз на примере:

• Узел LTS в настоящее время на 6.11.1
• Следовательно, мы хотим использовать самую высокую версию электрона, которая была официально создана с самой высокой версией узла, которая удовлетворяет условию <= 6.11.1 >= 6.0.0.
• Самая высокая версия электрона, созданная с использованием Node 6, — это электронная версия 1.4.15, созданная с помощью Node 6.5.0.
• Таким образом, электрон 1.4.15 — это место, где мы разветвляемся для электронного LTS и пересобираем его с 6.11.1 (и так далее, пока не появятся новые выпуски Node v6).

Когда Node LTS перейдет на v8 (LTS — это только четные числа), мы вместе перейдем на еще не выпущенный электрон, который будет построен с использованием Node v8, или останемся на текущем форке LTS до тех пор, пока не будет выпущена такая электронная версия.

Как насчет разработчиков, которым нужны самые последние и лучшие?

@CxRes @CiriousJoker Давайте не будем отходить от темы. Никакие технические причины не препятствуют использованию различных версий Электрона. Фрагментация будет в любом случае (разработчик выпустил приложение год назад и забыл, другое приложение от другого разработчика выпущено недавно и использует другую версию).

@YurySolovyov Вся идея LTS заключается в том, что она не самая последняя и лучшая — она стабильна. И если мы не можем договориться о том, чтобы сосредоточиться на одном решении, мы обречены страдать от неоптимальности по Парето из-за отсутствия среды выполнения, потому что ни у одной группы нет времени и возможности пересобирать каждую версию и проверять их на наличие ошибок.

Также см. комментарий @CiriousJoker выше:

да, но если мы начнем заботиться обо всех и их мамах, мы не добьемся никакого прогресса.

@develar Хорошо. Но, как вы указываете, это не техническая проблема, а политическая (договориться о сборке, которая работает для большинства людей последовательно, так что бремя распределяется).

Итак, что нам теперь делать? Выберем ли мы версию lts и начнем или попытаемся найти решение, чтобы оно работало для всех, пытаясь создать универсальную среду выполнения с модульными dll (как предлагает @develar , если я правильно понял)

@CiriousJoker Параллельная сборка для конкретной электронной версии. например ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar Я не могу найти эту сборку электронов в Google, не могли бы вы дать ссылку или что-то в этом роде?

Имо, чтобы ускорить процесс, мы должны просто выбрать случайную версию Electron в качестве версии lts и начать. Мы можем изменить версию в любом случае в любой момент позже.
@develar Я до сих пор не знаю, что вы имеете в виду под этой параллельной сборкой, но она должна работать кроссплатформенно, и я думаю, мы можем реализовать ее позже.

Мы (или на самом деле вы, ребята) говорили об этом годами, но если никто не начнет, ничего не изменится, и мы будем сидеть здесь еще 3 года, обсуждая идеи и находя способы не начинать.

Я надеюсь, что разработчики электроники смогут как можно скорее решить вопрос о разделении рабочей среды и приложения, что значительно продвинет электронные приложения, и я увижу светлое будущее.

Они не могли решить эту проблему в течение, как мне кажется, лет, так что я отношусь к этому пессимистично. Конечно, это было бы здорово, но активно ли они над этим работают?

@CiriousJoker Как указано выше, я работаю над поддержкой общей среды выполнения электронов для окон в электронном конструкторе. Я зарегистрировал https://github.com/electron-userland/electron-builder/issues/1942 , чтобы отслеживать прогресс. Я надеюсь, что он будет готов к использованию через 1 месяц.

@develar Плохо, должно быть, проглядел это .. В таком случае, удачи, было бы здорово, если бы ты смог это сделать!

Если кого-то интересует дедупликация с определением содержимого подфайла, упомянутая ранее в ветке https://github.com/electron/electron/issues/673#issuecomment -157980607, я открыл исходный код: https:// github.com/ronomon/дедупликация

Эта длинная ветка бездействовала в течение последних месяцев, но я думаю, что проблема, которую она затрагивает, все же заслуживает изучения. На выходных я сделал небольшую одностраничную утилиту для массового переименования файлов. Конечный файл .app для Mac, упакованный электронным компоновщиком, весит 121 МБ ...

Я думал об этой проблеме в последнее время. Затем я взглянул на свой смартфон: приложение Facebook весит 600 МБ. Размер Chrome — 325 МБ, Mesenger — 300 МБ… Так что приложение размером 120 МБ на рабочем столе — мне все равно…

Размер сегодня не проблема. Оперативная память и энергопотребление есть.

_edit: если вы не согласны, поделитесь, почему_

Что касается платформы Windows, усилия @develar в отношении электронного построителя (electron-userland/electron-builder#1942) выглядят близкими к достижению общей среды выполнения.

Также заметил, что веб-каталог приложений, который упаковывает веб-приложения как отдельные приложения Electron, решил проблему использования общей среды выполнения, чтобы значительно уменьшить размер приложения: webcatalog/webcatalog/issues/171. Это было сделано в их упаковщике путем символической ссылки на общие ресурсы между приложениями .

Прогрессивные веб-приложения (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 (например, доступ к собственной файловой системе) будут добавлены, если разработчики проявят интерес.
Большинство веб-приложений Electron можно легко преобразовать в PWA, но я не уверен в таких, как Atom, VSCode - вероятно, потребуется переписать нативный код в WebAssembly.

У @develar есть прогресс в этой идее?

Воспользуюсь, когда выйдет!

Недавно наткнувшись на это, я просто хотел высказать свое мнение. Я не читал весь выпуск, поэтому могу повторить некоторые вещи по незнанию.

Я думаю, что что-то подобное очень важно, так как, хотя сейчас размер программы Electron может показаться не такой уж большой проблемой, вы действительно начинаете видеть это, когда распространяете очень простую и маленькую программу — скажем, специальный калькулятор. В этом случае разумным будет что-то вроде 5-10 МБ. Однако 60 МБ или больше были бы просто смешными. Для более крупной программы размер самого Electron становится менее заметным, но он все равно может раздражать.

Однако теперь для такого режима выполнения потребуется какая-либо система выпуска LTS, учитывая текущую скорость выпуска выпусков. Затем разработчиков можно было бы поощрять полагаться на выпуск LTS, а список наиболее распространенных используемых версий можно было бы даже отображать в каталоге приложений, побуждая их использовать наиболее распространенные версии, если только в них не отсутствует необходимая функция.

Сам режим выполнения должен, IMO, иметь встроенную систему для установки других версий библиотеки Electron, поэтому, если пользователь запросит установку приложения, для которого требуется другая версия, программа выполнения может автоматически загрузить его как простой шаг в процессе установки.

Я думаю, следует также отметить, что использование ОЗУ приложениями Electron также может быть улучшено с помощью этого, хотя изменения, необходимые для его реализации, будут гораздо более серьезными. С общей средой выполнения приложения Electron, использующие одну и ту же версию, могут совместно использовать некоторые ресурсы в памяти.

В любом случае, я очень плохо знаком со всем исходным кодом проекта Electron, поэтому извините, если что-то было неясно или я повторил что-то без необходимости. Однако я действительно надеюсь, что это будет реализовано, поскольку это действительно сделало бы Electron гораздо более многообещающей платформой для еще большего количества типов программ. :+1:

@octacian Я начинаю думать, что PWA — лучший вариант. Хотя и не универсальный — вы не можете делать _все_ с помощью PWA — но, безусловно, для таких вещей, как пользовательские калькуляторы, их должно быть более чем достаточно.

Теперь нам просто нужно дождаться появления поддержки PWA на рабочем столе .

Я также думаю, что с такой системой 1- будет легче поставлять ее на встроенные/меньшие системы, и 2- в будущем можно будет создать базу электронно-подобных операционных систем для мобильных устройств.

@yasinaydin Уже есть LG WebOS. (Раньше была и Firefox OS, но она больше не поддерживается)

@KeitIG ​​Сэр , ваш аргумент был бы абсолютно приличным, если бы единственной проблемой Электрона был его размер. Иметь немного большую программу, но упрощающую сложность и вероятность сбоя для разработчиков (мы не можем отрицать, что Electron хорош тем, что дает разработчикам стандартизированный способ создания приложений без особых возможностей для ошибок) было бы здорово. Увы, использование отдельной версии библиотек для каждого приложения также означает увеличение использования оперативной памяти и распределенные (и более сложные) проблемы безопасности. Я объяснил это лучше в своем дублирующем выпуске , но в двух словах я действительно думаю, что общая библиотека времени выполнения, которую вы можете обновлять самостоятельно и делиться между различными приложениями Electron (которые также будут поставляться в «облегченной» версии, вроде как когда некоторые разработчики использовали для распространения файлов Java для использования на вашей JVM и связали .exe s) действительно было бы нарушителем условий сделки для Electron, и хотя я понимаю, что это, вероятно, будет огромный объем работы, это меня огорчает что это пока не входит в планы разработчиков. Будем надеяться, что они сделают это в будущем.

@ dre-hh Хотя я признаю добрые намерения вашего предложения, оно, среди прочего, чрезмерно ограничительно. Например, я разработал коммерческое электронное приложение для своего работодателя, и оно используется в строго регулируемых средах (отсутствие подключения к Интернету, требования к отслеживаемости / аудиту и т. д.). Наши клиенты не могут позволить нам делать такие вещи, как автоматическое обновление программного обеспечения. Это совсем другой мир, чем типичные веб-приложения для масс. Вечнозеленые браузеры и автоматическая установка обновлений безопасности ОС — это, на мой взгляд, отличная идея для большинства людей в большинстве случаев, но я считаю, что они подходят не везде. Иногда риск нарушения работы, вызванный изменением программного обеспечения, намного выше, чем риск, связанный с запуском устаревшей версии программного обеспечения, особенно в контролируемых средах, где используются другие методы снижения безопасности. Следовательно, крайняя мера, такая как блокировка выполнения приложений, использующих устаревшие версии электрона (или вообще любой библиотеки), не является идеальным решением, если вообще является решением. (Кроме того, у администраторов уже есть множество элементов управления для ограничения того, какие программы могут выполняться, поэтому они могут реализовать это без каких-либо новых функций ОС.)

Кроме того, как и в случае с большинством проблем безопасности, большая часть проблем связана с разработчиками, которые либо не знают о рисках, либо по какой-либо причине (например, из-за нехватки времени) решили не следовать рекомендациям по безопасности для инструментов, которые они используют. (например , безопасность, встроенные возможности и ваша ответственность ). Мы, как разработчики, должны вносить свой вклад в обеспечение качества (включая безопасность) нашей работы.

Наконец, я считаю ошибкой обращаться к коммерческим организациям по разработке программного обеспечения, таким как Microsoft, для решения этих проблем. Отчасти это связано с тем, что, как было только что отмечено, мы не можем рассчитывать на создание безопасных приложений разработчиками, не заботящимися о безопасности. Что еще более важно, по крайней мере, на мой взгляд, то, что одной из прекрасных особенностей Electron является его открытый исходный код и мультиплатформенность, что обычно не является приоритетом для поставщиков коммерческого программного обеспечения. Хорошо продуманный и успешный прогресс, скорее всего, потребует определенного уровня консенсуса и усилий со стороны всего сообщества разработчиков. Конечно, участие коммерческих организаций приветствуется.

@jacobq Если вы не знали, Microsoft является владельцем Electron.

Если вы не знали, Microsoft является владельцем Electron.

@ Jop-V Пожалуйста, добавьте ссылку на это; Я не думаю, что это правильно. На главной странице electrojs.com написано:

Electron — это проект с открытым исходным кодом, поддерживаемый GitHub и активным сообществом участников.

Microsoft является потребителем Electron (используя его в таких продуктах, как Visual Studio Code) и (я полагаю) также участником, но они не владеют им. В файле лицензии 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 станет владельцем Electron, так же как я не думаю, что Microsoft станет владельцем Atom.

Я думаю, что эти дебаты на самом деле не помогают в начальной точке вопроса.

https://github.com/GoogleChromeLabs/карло

Карло выглядит довольно интригующе. Я попробовал его, и он очень интуитивно понятен. Кто-нибудь еще экспериментировал с pkg ?

Почему все предложения по уменьшению раздувания жесткого диска и памяти конечных пользователей никогда не работают? Это фантастическая идея, которой уже 4 года, но она до сих пор остается просто идеей. Я не могу понять, почему такие вещи не являются приоритетами проекта.

@danielo515, потому что вместо создания еще одного трудолюбивого проекта есть https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

О чем ты говоришь? Это уже огромный проект. Он также является наиболее распространенным и используемым, поэтому указывать людям на другой проект для функции, которая должна быть частью этого, мне кажется неправильным.
Кроме того, у Карло другой подход, они используют установленный вами Chrome, так что это не похоже на демон-версию Electron.

Я не могу понять, почему такие вещи не являются приоритетами проекта.

Потому что воплотить это в реальность сложно (например, «на самом деле» сложно).

Если вы недовольны (что вполне понятно), смело делайте форк Electron и отправляйте PR.

Не поймите меня неправильно, если бы существовало простое решение этой проблемы, я уверен, что оно уже было бы реализовано.

@danielo515

... указывать людям на другой проект для функции, которая должна быть частью этого, мне кажется неправильным.

Я думаю, дело в том, что у каждого проекта есть свои сильные и слабые стороны, и Carlo хорошо подходит для случаев с ограниченным пространством. Для моих вариантов использования размер приложения в 100 МБ вполне подходит, поэтому, хотя я бы хотел, чтобы эта функция появилась, другие функции электрона для меня гораздо важнее.

@jacobq Да, вы правы — для разных вариантов использования требуются разные инструменты.

Если кому-то еще интересно, я создал список похожих инструментов для разработки js-приложений на рабочем столе.

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

Я просто не использую Electron, потому что не могу позволить себе обновлять десятки приложений по 100 МБ — а вы знаете, как нужно обновлять приложения (у меня есть другие мнения на этот счет, но делиться ими не поможет).
Что мне действительно нравится в подходе carlo, так это идея использовать установленный браузер.
Еще лучше, конечно, Карло мог бы использовать любой доступный браузер, а не только хром, поскольку puppeteer может управлять и другими браузерами. В OSX вы создадите Safari, в Linux Epiphany (webkitgtk) или Firefox и т. Д.
Так что на самом деле, чтобы получить приложение, вам нужно только установить nodejs и ваше приложение.
Теперь вопрос будет заключаться в следующем: насколько хорош pkg при использовании установленных в системе библиотек и нативных дополнений?
Например, если бы мне нужно было упаковать приложение, которое я сейчас разрабатываю, мне понадобились бы postgresql, sharp (и vips), webkitgtk и exiftool. Я хотел бы иметь возможность распространять приложение только среди пользователей Linux Debian, Fedora или Ubuntu. Я хотел бы избавиться от «сумасшедших пакетов» и вместо этого извлечь выгоду из тяжелой работы, проделанной этими дистрибутивами, бесплатно.

@kapouer ... используйте установленный браузер ...

Хотя теоретически это хорошая идея, это приводит к увеличению сложности кодирования приложений на стороне Интернета, поскольку теперь вам придется сосредоточиться на поддержке нескольких браузеров, а браузеры, к которым они возвращаются, могут быть ограничены в том, что вы хотите делать, поскольку они не имеют полной поддержки таких вещей, как вы можете найти в Chromium. Вы также полагаетесь на то, что пользователь должен убедиться, что его браузер обновлен и что несколько поставщиков браузеров не нарушат работу вашего приложения при обновлении.

Многие пользователи обходятся массовыми обновлениями размером 50 МБ, переключаясь на дельта-обновления или заставляя менеджеры пакетов обновлять только файл .asar или папки ресурсов. И делайте большое обновление Electron только при необходимости. Это то, что мы делаем в нашей компании, и это отлично сработало.

С точки зрения наивного пользователя, использование оболочки приложения Electron в качестве общей среды выполнения значительно упростило бы его распространение и использование. Например. С 5 электронными приложениями в одной системе у вас есть 5 экземпляров оболочки приложения, и это около 300 МБ, верно?

Я твердо верю, что электрон — это будущее UX для настольных компьютеров, и это был бы большой шаг (посмотрите на .NET Runtime — может быть, неудачное сравнение, но это круто, не так ли?), чтобы сделать веб-технологии более мощными.

У Electron уже есть среда выполнения для разработки, не так ли? «Электрон». команда, я имею в виду. Почему бы не использовать это для пользовательской стороны?

Чтобы иметь дело с несколькими приложениями в зависимости от разных версий Electron, вы можете использовать подход, который использует ядро ​​.NET. Просто установите несколько версий среды выполнения рядом друг с другом и попросите приложения объявить минимальную (или максимальную) версию, которая им требуется.

Я сделал пусковую установку для проверки концепции: https://github.com/ProPuke/electron-shared

Один исполняемый файл размером менее 1 МБ. Передайте ему каталог приложения или пакет 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 и распространяться могут только асары.

Он также имеет несколько параметров командной строки, в том числе --downloadOnly и --silent , поэтому его можно вызывать из установщиков в процессе установки.

Он не обрабатывает автоматическое обновление (он загружается только в том случае, если совместимая версия Electron еще не доступна на вашем компьютере), но это может выполняться периодически при запуске или фоновой службой (пока среда выполнения находится в правильное место, где он найдет и использует последние версии при запуске приложений).

Знать, когда удалять старые копии среды выполнения, может быть непросто. Они могут накапливаться со временем. Нам нужно либо отслеживать, какие установленные приложения использовали какие версии (и, следовательно, какие больше не нужны), либо, возможно, просто хранить дату последнего использования для каждой версии среды выполнения и автоматически удалять их, если они не использовались. через некоторое время.

В любом случае, доказательство концепции/предложения. Что-то вроде этого решает проблемы? Я пропустил что-то вопиющее и очевидное?

Я попробовал совместное использование электронов @ProPuke и смог запустить демонстрацию быстрого запуска электронов . Но мне не удалось запустить ни одно из приложений, описанных на веб-сайте electronicjs (потому что большинство приложений используют некоторый сценарий оболочки для запуска приложения, а не только package.json, как я понимаю). Но я считаю, что это _доказательство концепции/предложения_ может быть указателем на следующее большое обновление.

У меня есть идея.electron Потому что в настоящее время поддерживает команду "electron.exe path".Я думаю, что вы можете открыть его, вызвав несколько асаров из командной строки.В настоящее время я просто идея.Я надеюсь, что кто-то может это сделать, потому что я только что коснулся этого программного обеспечения.
_____________ Китайская версия перевода__________
У меня есть мысль. Потому что в настоящее время электрон поддерживает команду «путь к electro.exe». Я думаю, что его можно открыть, используя командную строку для вызова нескольких асар. На данный момент я просто идея, я надеюсь, что кто-то может взглянуть на нее, потому что я только что участвовал в этом программном обеспечении.

После беглого просмотра всей беседы (и других дискуссий вроде Множественных «приложений»), резюмирую — вызов нескольких асаров изначально вместо того, чтобы начинать с нескольких бинарников, имеет долгую историю, но не поддерживается. А вот default_app для электрона реализован с помощью командной строки (может быть, я пока не знаю). Я думаю, что вызов cmd через электрон (это кажется возможным) должен обеспечить совместимость с этой функцией.
Бегло взглянув на все разговоры (и другие обсуждения, такие как несколько «приложений»), я прихожу к выводу, что запускаются нативные вызовы нескольких Asar вместо нескольких двоичных файлов, которые имеют долгую историю, но не поддерживаются. реализация, которая использует командную строку (и, возможно, я не знаю какое-то время).Я хочу вызвать cmd через электрон (как если бы я мог) должен быть в состоянии достичь этой панели совместимости функции.

В худшем случае вам придется создать файл .bat или его эквивалент для ОС, отличных от Windows, и запустить его из 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, команда электрон. exe путь действителен

О, так что вам нужен электрон для запуска пути exe внутри электрона, используемого для установки всего этого. Все же лучше, чем электронная установка для каждого используемого приложения. Вам потребуется только одна установка электрона для каждой версии электрона, необходимой вашему приложению. Вам, вероятно, потребуется сделать отдельное расширение, которое представляет собой переименованный zip-архив, содержащий как приложение, которое мы пытаемся запустить, так и файл с рекомендуемой версией (запустит его сразу же), совместимые версии (спросит, следует ли запустить или установить рекомендуемую версию, а также загрузить рекомендуемую версию Electron в фоновом режиме) или просто показать индикатор загрузки для загрузки рекомендуемой версии.

Или я что-то неправильно понял.

Эта идея, вероятно, та же самая: поскольку bat в настоящее время легко сказать, возьмите его, например, содержимое electronic.exe app1.asar, после выполнения электрон открывает содержимое app1.asar. Вероятно, так оно и работает, но когда вы пишете следующее предложение, electronic.exe app2.asar, в bat, вы можете сделать это только тогда, когда заканчивается электрон app1.asar. А когда летучая мышь выключается, электрон выключается. Но я пишу электрон.exe app3.asar|electron.exe-v или электрон.exe app3.asar|start и так далее. Когда я закрываю летучую мышь, электрон может выжить, но я не могу продолжать открывать другие асары. Я думаю, что эта отдельная программа может быть лучше, чем эта, потому что летучая мышь все еще несколько ограничена.

Нет, если вы используете временные папки.

У вас есть (заархивированные или неархивированные) версии в папке electronic_versions, из которой вы можете использовать либо рекомендуемую версию, либо самую новую совместимую версию, которую вы загрузили, скопировав используемую вами версию во временную папку, и после того, как вы закончите ее, вы удалить папку.

Путь к локально сохраненным файлам будет либо в электронной папке, либо рядом с файлом, который вы используете. Если вы используете его из архива, содержащего вещи, которые я упомянул за последние 24 часа, вам придется переместить сохраненные файлы данных обратно в архив или вообще не перемещать их, прежде чем вы удалите эту временную папку экземпляра электрона.

SSD？

???

Причина удаления временной электронной папки заключается в том, что приложение теоретически может изменить файлы электронной установки, на которой они работают, и по замыслу. Я имею в виду, что архив может содержать файлы и папки, которые необходимо перезаписать или перезаписать во временной электронной установке.

Таким образом, после того, как установка используется, она может рассматриваться как поврежденная запущенным приложением, поэтому ее нельзя повторно использовать, и поэтому ее необходимо удалить. Тем не менее, версия, из которой к тому времени поврежденная установка использовалась в качестве основы, все еще не повреждена в папке electronic_versions приложения runtime-electron, которое мы пытаемся создать.

На самом деле, если архив с определенным расширением, о котором я упоминал ранее, предназначен только для чтения, то данные, которые он использовал, теоретически можно было бы переместить в %appdata%. Таким образом, приложение, работающее внутри runtime-mode-electron, которое мы пытаемся сделать, на самом деле будет переносимым (автономным), и, таким образом, копирования этого файла будет достаточно, чтобы взять с собой конфигурацию этого приложения.

Но нам также, вероятно, потребуется добавить функцию обновления для этого типа файлов, которая будет другой электронной установкой, которая будет копировать и перезаписывать файлы из нового установочного файла в копию старого установочного файла и возвращать новый установочный файл с расширением данные у него были. Все это может быть сделано автоматически, если в файлах, используемых runtime-mode-electron, который мы пытаемся создать, есть ссылка для скачивания.

Как только это будет готово, если вы хотите пройти лишнюю милю, вы можете даже добавить клиент git, из которого можно обновлять приложения, хотя для этого может потребоваться использование github и bitbucket для размещения скомпилированных файлов архивов.

вы можете использовать загрузочный файл «curl, wget, aria2c», и пользователю не нужно устанавливать git, вам нужно использовать «gzip, 7z», распаковать zip.

Я делаю инструмент electron-runtime , который работает аналогично electron-builder . Он объединяет только файл app.asar с простым скриптом sh (позже это будет пользовательский интерфейс, показывающий ход загрузки Electron). В настоящее время он работает только для macOS.

При запуске приложения, упакованного с electron-runtime , оно в основном загружает соответствующую основную версию Electron, но самую новую в случае второстепенной версии и патча, поскольку критические изменения Electron происходят только в приращениях основной версии.

Приложение electron-quick-start весит всего 62 КБ, снимок экрана:

Если вам это интересно, оставьте звезду, пиар или вопрос.

Я немного обновил пакет, чтобы его можно было собрать с помощью electron-builder ( здесь описано, как это работает ). Так что теперь вы можете создавать с его помощью даже Visual Studio Code! (но пока только на macOS).

Я успешно выпустил первую версию electron-global ! (Я изменил его, так как electron-runtime был занят). Вы можете создать свое приложение, используя мой пакет npm с electron-builder . Я также добавил пользовательский интерфейс с индикатором выполнения, показывающим ход загрузки Electron. Я надеюсь, что он станет более популярным, чтобы сделать Electron лучше.

Извините, я использую систему Windows, и у меня нет денег, чтобы использовать MacOS. Но я верю, что ваш проект будет очень успешным.

@nwdxlgzs Поддерживает Windows, macOS и Linux...

Я думал, что этот проект поддерживает только MAC.
Я собираюсь найти время, чтобы попробовать этот замечательный проект.

Спасибо за это и за то, что держите нас в курсе!
Я также использую Windows.
Я посмотрю на код, когда получу изменения.

Что ж, как насчет интеграции electron-global апстрим и установки нового значения по умолчанию 😏