+100, isso seria muito útil para reduzir o tamanho do aplicativo.

A extensão .asar pode ser alterada? Parece muito estranho em húngaro. Basicamente, isso significaria the shit de uma maneira ruim ( link ).

.apak? com toda a seriedade, existem toneladas de idiomas, então quase qualquer extensão pode soar estranha em alguns deles.

A instalação e atualização do tempo de execução do IMO deve ser o mais fácil possível. Muitos runtimes têm notificações muito irritantes. Além disso, se você fizer isso, alguns metadados de manifesto adicionais devem ser fornecidos, porque as versões mais recentes do aplicativo podem não funcionar no tempo de execução antigo, portanto, você precisa comparar a versão atual do tempo de execução com a versão no manifesto do aplicativo (possivelmente até o intervalo de versões como no nó packages ) e, se o tempo de execução precisar ser atualizado, torne esse processo o mais fácil possível. Não sei o que é fácil para a maioria das pessoas, mas para mim é apenas janela com barra de progresso ou mensagens de status ("Baixando... 57%", "Atualizando...")
Não tenho certeza, mas atualizações em segundo plano também podem ser consideradas. Pode ser algum serviço de atualização ou apenas download de tempo de execução enquanto o aplicativo está em execução e atualização quando o aplicativo é fechado.

+1 para isso. Estou trabalhando em um aplicativo que devo entregar para mac e windows, e isso simplificaria consideravelmente a entrega.

Isso seria incrível!

Alguns pensamentos:

• Como @YuriSolovyov disse, precisamos de uma maneira de declarar com quais versões do atom-runtime um determinado asar é compatível. De preferência, isso também deve permitir a especificação de uma versão exata, pois isso diminui a carga do controle de qualidade ao liberar um aplicativo baseado em asar.
  
  
  
  • Para dar suporte a isso, precisaríamos permitir várias versões do atom-runtime instaladas lado a lado, potencialmente invisíveis para o usuário.
  
  
  • Observe que isso está um pouco em desacordo com os ideais de limitar os tamanhos de download. No entanto, uma empresa que produz vários produtos baseados em asar pode padronizar internamente para que todos os seus aplicativos ainda usem a mesma versão.
  
  
• Você não mencionou suporte para atualização automática do atom-runtime no Mac, mas isso seria _muito_ útil.
• Em vez de ter instalações somente fonte no linux, seria bom oferecer suporte à instalação/atualização de binários, tanto por meio de pacotes .deb/.rpm quanto por algum método que não exija direitos sudo para instalação (ou seja, por usuário). Para tempos de execução instalados por usuário, a atualização automática também seria muito útil.
• Haveria algum suporte para manter os arquivos asar instalados atualizados - ou isso é algo que precisaria ser implementado independentemente em cada aplicativo?

Por fim, qual é o cronograma desse esforço? Qual seria a melhor maneira de começar, se eu quisesse começar a implementar partes disso? Estou aberto a contribuir.

@joshuawarner32 Atualmente, esta é apenas uma ideia aproximada, pretendo trabalhar nela depois de resolver alguns problemas importantes do atom-shell, mas pode ser meses depois.

Eu acho que também vale a pena olhar para os tempos de execução existentes e como eles estão funcionando/atualizados, quão perturbadores eles são e quais outros prós e contras.

Atualmente, esta é apenas uma ideia aproximada, pretendo trabalhar nisso depois de resolver alguns problemas importantes do atom-shell, mas pode ser meses depois.

Tem sido cerca de 5-6 meses. Seria ótimo ter isso implementado.

Construímos uma implementação interna disso que se encaixa muito bem em nosso caso de uso específico e podemos fazer o upstream dela. O perigo seria que ele é realmente muito específico para nosso caso de uso, e ninguém mais estaria interessado na complexidade extra.

Aqui estão os destaques do nosso design:

• Implante arquivos .asar.gz para vários aplicativos diferentes em um servidor
• Distribuir uma única compilação do atom-shell para os usuários, que não agrupa nenhum código para aplicativos específicos
• Na inicialização do aplicativo, baixe o arquivo .asar.gz apropriado (se não estiver lá ou se houver um mais recente no servidor). Extraia-o e execute o aplicativo contido.
• Nossa compilação atom-shell aceita um argumento --app para especificar qual aplicativo baixar/executar

É esse tipo de coisa que o povo da concha atômica tinha em mente? Algo assim seria útil para outras pessoas?

Como o JRE, poderia ser o ERE (electron runtime environment), com arquivos .eapp (electron app)

-1 para .eapp

+1 eu preciso!

No Windows, podemos fornecer instalador e atualizador automático para atom-runtime e registrar o tipo de arquivo .asar a ser aberto com ele.

Instale o Steam no Windows e confira como eles criam atalhos de jogos, eles realmente usam um manipulador de protocolo, é relativamente inteligente

:+1: no modelo Steam.

Não há nenhum obstáculo técnico na implementação disso, a coisa toda pode ser apenas um aplicativo Electron. Mas o problema é que também não é fácil de implementar, levando em conta todos os detalhes, acho que requer uma pequena equipe trabalhando em tempo integral, não tenho certeza se isso aconteceria.

Mas o problema é que também não é fácil de implementar, levando em conta todos os detalhes, acho que requer uma pequena equipe trabalhando em tempo integral, não tenho certeza se isso aconteceria.

Há muitas perguntas em minha mente que, embora certamente não sejam insuperáveis, tornam esse plano difícil. Por exemplo, digamos que "App 1" requer 0.30.xe não pode ser executado em 0.31.xe "App 2" requer o oposto. Quem ganha neste cenário?

Parece muito esforço e infraestrutura / dificuldade para otimizar para algo que não é nosso maior problema - espaço em disco e largura de banda, às custas da complexidade do desenvolvedor (ou seja, agora os desenvolvedores precisam criar esse instalador de cadeia maluco para instalar / verifique o Electron e instale o aplicativo)

Eu não quero estar odiando uma ideia! Eu só acho que com o tempo que levaríamos para fazer isso, poderíamos gastá-lo em nosso grande problema - tornando super fácil para novos desenvolvedores criar e publicar aplicativos Electron, desde sua primeira linha de código até enviando para os usuários

@paulcbetts Mas ei, os benefícios valem a pena, não é? Ao atualizar um aplicativo, os usuários terão que baixar menos de um MB em vez de ~70 MB. O que significa que nem precisaremos de estruturas de atualização automática e tudo, apenas teremos que baixar e extrair um arquivo micro-zip com alguns arquivos.

Passei os últimos três meses em uma área remota onde a velocidade era inferior a 128kbps e acredite, o tamanho da atualização é uma grande dor de cabeça, a pior parte é que ainda há toneladas de pessoas ainda em situações semelhantes

O que significa que nem precisaremos de estruturas de atualização automática e tudo, apenas teremos que baixar e extrair um arquivo micro-zip com alguns arquivos.

Eu não acho que isso seja verdade, porque quase certamente em algum momento você vai querer mudar para uma versão mais recente do Electron e depois kerplowie, você está em uma situação semelhante (ou pelo menos uma que é igualmente feia )

Aplicativos básicos agora estão entre 30 e 50 Megas, a menos que você tenha uma tonelada de vídeos dentro do seu pacote. Eu não acho que é um exagero para a maioria das pessoas fazer o download. Acredito que o vídeo médio do youtube esteja entre 30 e 40 mb...

Eu gostaria apenas de fazer uma observação aqui, na China, a velocidade de conexão é em média cerca de 20kB/s (é claro que tenho uma conexão mais lenta que ~ 92% da minha cidade.) A atualização do Atom/electron geralmente requer um dia inteiro de wget -c 'ing. a menos que os espelhos taobao sejam usados.

Para compatibilidade de versão, o desenvolvimento de elétrons se move muito rápido para ter uma versão abrangente, talvez algum tipo de wrapper/auxiliar possa ser usado para usar/baixar a versão principal solicitada quando o aplicativo for iniciado?

20kb/s? como você pode sobreviver? Eu não posso imaginar o quão difícil isso deve tornar as coisas!

@steelbrain não é minha intenção

@RIAEvangelist Continuando rápido e com muita paciência. A velocidade fica muito rápida tarde da noite, então deixe os downloads em execução ou agendados enquanto você dorme. :3

De qualquer forma, acho que não daria muito trabalho escrever um wrapper (básico) de terceiros, alguém quer tentar?

Os arquivos .asar, no entanto, não podem declarar facilmente sua versão eletrônica. Talvez outro sistema descritor de programa seja necessário?

Que tal algum tipo de despachante de versão de tempo de execução que (baixa se necessário e) lançadores exigem versão de tempo de execução para seu aplicativo? Podemos adicionar uma entrada ao package.json para isso.

@YuriSolovyov Exceto que não podemos ter dito que o tempo de execução lida com arquivos .json por padrão. Suponho que ele poderia ler o arquivo asar primeiro e visualizar o package.json, mas isso o atrasaria um pouco.

@Tribex sim, o fluxo lógico é como:

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

Idealmente, o modo de tempo de execução deve funcionar como o Steam ou o Chrome App Launcher . O principal problema é como lidamos com os aplicativos quando o tempo de execução é atualizado para a nova versão.

Os aplicativos Electron sofrem com a atualização do Electron, especialmente os módulos nativos do nó. Os módulos nativos são necessários para reconstruir para cada atualização do Electron devido ao problema C++ ABI (Existem vários problemas de travamento esquecidos e reconstruídos relatados pelos usuários).

O Steam não sofre com a dor, pois todos os jogos no Steam são um programa autônomo, na verdade, você pode iniciar o jogo sem o Steam Client. Nem o Chrome App Launch, porque os aplicativos Chrome são escritos em HTML/JS/CSS, que são tipos de linguagens interpretadas, não há lacunas em execução em diferentes versões do Chrome.

@hokein que tal termos um "cliente" leve em um idioma nativo, que baixa vários idiomas, sempre que encontra um aplicativo que depende de uma versão desinstalada do electron ele baixa uma cópia dele e executa cada aplicativo com seu elétron específico.

Há um novo lançamento do Electron uma vez por semana, então a chance de dois aplicativos terem exatamente a mesma versão do Electron é pequena.

Para oferecer suporte a uma abordagem de tempo de execução, provavelmente precisaremos começar a separar os lançamentos para versões LTS (suporte de longo prazo) e versões de ponta. O LTS será para produção e a vanguarda será para desenvolvimento e teste. O LTS receberá apenas correções de bugs e talvez algumas alterações que não substituem as principais versões do io.js e do shell de conteúdo, portanto, os módulos nativos ainda devem funcionar.

dado o que o @etiktin disse, a menos que um usuário tenha muitos aplicativos de elétrons em seu sistema, provavelmente não haveria nenhum benefício no tempo de download, pois eles ainda teriam que baixar o tempo de execução quase sempre.

Nas duas semanas que estive olhando para o elétron agora acho que vi 4 lançamentos.

@etiktin Idealmente, se o elétron seguir semver, um aplicativo poderia declarar a versão ^0.31 e usaria a versão 0.31.x mais recente. Isso pode ajudar um pouco as coisas.

Temos um aplicativo em produção com um mecanismo de atualização automática semver que faz o seguinte:

1. GET um ponto de extremidade HTTP simples no servidor fornecendo a versão atual (0.3.0, 0.3.1 etc.) e plataforma (darwin-x64, win32-ia32, win32-x64 etc.) do aplicativo.
2. O servidor retorna "304 Not Modified" ou então um manifesto JSON se houver uma versão mais recente.
3. O manifesto JSON é essencialmente uma lista aninhada de pastas, arquivos e links simbólicos na versão mais recente.
4. Uma entrada de pasta no manifesto JSON tem esta aparência: [nome, matriz de entradas filho].
5. Uma entrada de arquivo no manifesto JSON se parece com isso: [nome, hash de conteúdo, array de hashes de conteúdo dividido em pedaços de 64 KB, um sinalizador de inteiro indicando se o arquivo é executável ou não].
6. Uma entrada de link simbólico no manifesto JSON tem esta aparência: [nome, caminho de destino].
7. Esses manifestos JSON são criados e armazenados em cache no servidor para cada versão. Para cada arquivo no manifesto JSON, o servidor executa um algoritmo de desduplicação simples para dividir o arquivo em partes de comprimento variável usando partes dependentes de conteúdo e, em seguida, faz o hash das partes usando SHA256. Isso garante que a maioria dos hashes de pedaços para diferentes versões do mesmo arquivo permaneçam os mesmos, mesmo que o conteúdo seja deslocado em alguns bytes. O comprimento médio do fragmento é de aproximadamente 64 KB para desduplicação ideal + eficiência de compactação. Se os pedaços forem maiores, eles também não serão desduplicados, se os pedaços forem menores, eles não serão compactados também. O comprimento médio dos pedaços também será aumentado para arquivos muito grandes para evitar ter muitos hashes de pedaços nos metadados.
8. Quando o aplicativo recebe um novo manifesto JSON do servidor, ele verifica o espaço livre em disco disponível e cria um novo diretório temporário com um ID universalmente exclusivo. Usando seu antigo manifesto local como ponto de partida, ele copia trechos de arquivos locais ou baixa trechos ausentes do servidor para recriar o novo manifesto. Depois de criar a nova versão, ele verifica a estrutura de diretórios e as assinaturas de todo o conteúdo do arquivo. Se algo foi corrompido no download, ele remove a atualização.
9. Se a nova atualização for verificada com sucesso em relação ao manifesto, ela iniciará a nova versão do aplicativo no novo caminho de atualização.
10. A versão mais antiga percebe que outra versão está em execução e se desliga.
11. O novo aplicativo aguarda o encerramento da versão mais antiga e, em seguida, copia a si mesmo para outro diretório temporário, renomeia a versão mais antiga para um diretório de arquivo e renomeia o diretório temporário para o local da versão mais antiga (/Applications/Ronomon.app). Em seguida, ele é executado novamente, mas agora a partir do local da versão mais antiga (/Applications/Ronomon.app) e, em seguida, limpa o diretório de arquivamento.
12. Se algo der errado durante a transição, a versão mais antiga permanece no caminho canônico até ser trocada pela chamada de renomeação.

No geral, está funcionando muito bem na produção. A desduplicação e a compactação significam que apenas cerca de 33% precisam ser baixados para uma atualização típica de versão principal e atualizações secundárias exigem apenas 1-2 MB, dependendo do aplicativo. A atualização automática trata o código do Electron e do aplicativo como uma unidade atômica e nunca viola nenhuma assinatura de código no processo.

+1 Para ideia
+1 Para renomear asar

Eu vim para fazer uma questão sobre isso. Descobri que isso já existia, então vou colocar meu + :100: para isso
Precisamos totalmente de uma solução do tipo JRE ou .NET ou Adobe Air, porque empacotar o tempo de execução com cada aplicativo os torna realmente volumosos.

Alguma atualização sobre ter um tempo de execução separado dos aplicativos?

Isso está fechado porque uma solução foi desenvolvida?

@PierBover este problema está aberto.

este - https://github.com/KeitIG/museeks/issues/48 - foi fechado. no repositório de outra pessoa.

Ah, obrigado @championswimmer e desculpe a confusão.

Então, há alguma notícia sobre o tempo de execução independente? Isso é algo que está sendo trabalhado?

@PierBover , provavelmente não acontecerá tão cedo devido à fragmentação da versão atual (é difícil encontrar aplicativos de 2 elétrons que estejam usando a mesma versão exata). Talvez depois que a v1 for lançada.

@jorangreef você usa seu mecanismo de atualização diferencial em todas as plataformas? Seria incrível se você pudesse liberar esse código como um módulo autônomo.

@championswimmer Sim, consegui criar um script de compilação para meu aplicativo, então estou bem distribuindo meu aplicativo agora. Mas estou de olho nisso porque seria interessante.

@etiktin Sim, a atualização automática diferencial atualmente funciona em todas as plataformas. Se também incluísse um instalador mínimo que faça o download, o instalador poderá ser compartilhado por vários aplicativos e usar uma versão em cache do Electron, se já estiver disponível. Isso serviria para tornar as instalações muito mais rápidas. Eu gostaria de abrir o código se as pessoas estiverem interessadas, e tentarei liberar o código nos próximos meses.

Por exemplo, digamos que "App 1" requer 0.30.xe não pode ser executado em 0.31.xe "App 2" requer o oposto. Quem ganha neste cenário?

Então eles devem instalar as duas versões e haverá dois runtimes, assim como o VS C++ 2008 coexiste com o 2005. Eu realmente gosto de como os runtimes do VS C++ são instalados, o instalador instalaria uma versão necessária se não houver nenhuma, e outras podem depender mais tarde, e diferentes tempos de execução podem coexistir. A aplicação dos requisitos de versão também parece ser mais fácil no instalador.

@louy2 Há uma diferença entre o exemplo do Visual C++ (3 anos entre os lançamentos) e o Electron (3 lançamentos por mês pelo menos)

Vou brincar com uma citação 'este é um sistema quebrado' aqui, se a maioria dos
os aplicativos no ecossistema Electron não são compatíveis com +- 0.0.1 ou
0.1.0 diferenças de versão

Em 20 de fevereiro de 2016 às 18h55, Pierre de la Martinière <
[email protected]> escreveu:

@louy2 https://github.com/louy2 Existe uma diferença entre o
Exemplo Visual C++ (3 anos entre lançamentos) e Electron (3 lançamentos por
mês pelo menos)

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/atom/electron/issues/673#issuecomment -186595285.

+1

Empacotei o elétron em um pacote .deb usando fpm . Este pode ser um ponto de partida justo no Linux (baseado em Debian ou RPM, pelo menos). Você pode dar uma olhada aqui: iamale/electron-deb ; também um aplicativo de exemplo está lá . (Ele também funcionará com asar, basta adicionar uma entrada MIME no pacote de tempo de execução.)

Seria muito bom se tivéssemos algo assim nas outras plataformas também! Eu provavelmente poderia tentar empacotá-lo para o Windows, mas não o uso mais ativamente e não tenho muita experiência com ele.

(Obrigado @louy2 por apontar este tópico para mim!)

A propósito, qual é o tipo MIME para .asar? application/x-asar faria?

@iamale Em vez de fpm , você deu uma olhada em AppImageKit . O principal benefício que você obtém é que, em vez de criar várias bibliotecas e tudo mais, você pode direcionar todas as distribuições Linux com um executável. Você também não precisa mais pedir ao usuário para instalar nenhuma dependência, pois elas são empacotadas com o executável. É um belo projeto, por favor, dê uma olhada.

e sobre o mimo, que tal application/x-electron ?

@steelbrain Essa é uma boa ideia. No entanto, isso não resolveria o problema original: o tempo de execução do Electron teria que ser empacotado com cada aplicativo (porque as imagens precisam ser autocontidas), que é exatamente o que esse problema trata. Embora eu ache que deve ser relativamente fácil fazer AppImages de aplicativos Electron, e acredito que isso seria ótimo quando o gerenciamento de pacotes tradicional não pode ser usado (distros raras ou usuários sem privilégios). Então, obrigado por apontar!

application/x-electron soa muito bem, provavelmente vai ficar com ele.

Adicionado suporte asar! Ainda não está no repositório, será reconstruído ainda hoje ou talvez amanhã. Por enquanto, você pode obter o pacote em transfer.sh (o link será válido pelas próximas 2 semanas)

Você precisa de um asar.json dentro do .asar, para dizer:

• versão recomendada
• versões compatíveis
  Feito isso, você precisa de um aplicativo usando o elétron (qualquer versão dele) para verificar a web para (1) atualizações para si mesmo (o verificador) e (2) as versões existentes em seu computador, então, se existir uma versão compatível, ele analisa o caminho de abertura para o .asar aberto, caso contrário, baixe a versão recomendada e verifique novamente. O aplicativo, em si, pode ser escrito em Electron ou python (já que exigiria apenas uma interface do usuário mínima ou nenhuma).

A ideia é: O aplicativo que verifica se a versão eletrônica necessária foi baixada não tem nada a ver com as versões eletrônicas necessárias.

Se necessário, você pode atualizar o conteúdo de default_app, bem como o restante do aplicativo, exceto ele.

E lá, você pode ter as versões salvas com app.setPath("userData", __dirname + "/ElectronVersions"); , então essas versões podem ser deixadas lá sozinhas e novas instaladas conforme a necessidade.

Em vez de fpm, você deu uma olhada no AppImageKit .

Existe um AppImage do Atom disponível em https://bintray.com/probono/AppImages/Atom/_latestVersion#files - basta fazer o download, chmod a+x e executar em qualquer distribuição Linux x86_64 não muito desatualizada.

O problema não é apenas linux, precisamos de uma maneira de torná-lo cross-OS, o que significa que precisamos ser capazes de executá-lo em Linux, Windows e Mac OSx.

Algum tipo de iniciador específico do sistema operacional que verifica se o tempo de execução está disponível e atualizado/compatível com o pacote asar

(muitos anos depois) Deixe-me resumir a discussão:

1. @zcbenz propõe um tempo de execução que gerencia instâncias locais do Electron para que os pacotes .asar sejam distribuídos apenas e os binários do Electron sejam evitados. O runtime gerencia também a execução de pacotes .asar .
2. @YurySolovyov sugere aprimoramento do arquivo de manifesto com informações adicionais (por exemplo, versão do Electron necessária) para que o tempo de execução saiba qual versão deve ser usada para qual pacote .asar . Uma visão geral desta abordagem é dada aqui .
3. @joshuawarner32 apresenta a ideia de várias versões de tempo de execução, empacotamento binário (por exemplo, .deb ) e atualização automática para pacotes .asar . Além disso , a ideia de um servidor de distribuição é considerada.
4. @paulcbetts sugere dar uma olhada no modelo Steam e implementar algo semelhante. Ele aponta as complicações associadas à ideia de um tempo de execução local que suporte diferentes versões do Electron, etc.
5. [as pessoas discutem a velocidade da internet na China e seus assuntos de infância]
6. @hokein aponta as complicações quando o tempo de execução é atualizado. Especialmente wrt. módulos nativos que precisam ser compilados novamente nos cabeçalhos do Electron.
7. @etiktin quer ter versões LTS e de ponta para que os aplicativos prontos para produção usem LTS em vez de ponta.
8. @Tribex diz que se nos atermos ao versionamento semântico , não precisamos ter uma instância local de _all_ versões, mas apenas aquelas que são incompatíveis.
9. @jorangreef fornece um exemplo de sistema de atualização automática diferencial já em produção para seu próprio aplicativo.
10. @iamale construiu um pacote fpm do Electron para executar pacotes .asar .

_disclaimer: Tentei incluir apenas os principais pontos de discussão. Por favor, desculpe se eu perdi alguma coisa!_

Li a discussão até aqui, tentei resumir os pontos principais e quis abordar alguns deles. A ideia de um tempo de execução com "integrações profundas de plataforma" vai além de uma simples instância local. Um produto mínimo viável deve ser definido, que atua como um tempo de execução de todo o sistema. Eu também adicionei um recurso interessante que pode ser útil. A última seção descreve quais mudanças/recursos precisam ser implementados.

Justificativa:

O que está sendo feito pela maioria dos desenvolvedores (ou seja, agrupando binários do Electron) é como vincular todas as bibliotecas compartilhadas estaticamente! É como entregar um forno com cada pizza que vendemos.

MVP:

• Gerenciador de ambiente : mantém o controle de instâncias do Electron disponíveis localmente. Ele pode ser usado para decidir qual pacote é compatível com qual instância (usando package.json aprimorado [veja abaixo]). Ele também deve cuidar de definir as variáveis ​​de ambiente corretas para que os pacotes sejam executados.
• Gerenciador de atualizações : foi discutida a possibilidade de atualização automática (+ notificação) e atualização automática diferencial. Seria bom tê-lo como um daemon que cuida da atualização das instâncias locais para as versões mais recentes.

Bom ter:

• Gerenciador de pacotes/dependências : assim como o apm do Atom , um gerenciador de pacotes é necessário para baixar pacotes .asar (do GitHub ou de um determinado URL, etc.) e instalá-los localmente (comparável com apt-get no Ubuntu ou brew no Mac).

Requisitos:

• Arquivos de manifesto aprimorados : package.json também deve conter um semver (ou intervalo semver) para indicar qual versão do Electron é necessária.
• Procedimento de instalação/desinstalação definido : ATM o pacote .asar contém tudo o que é necessário para executar um aplicativo. No entanto, é possível entregar apenas os módulos de dependência de origem e download na instalação. Se formos muito corajosos, podemos ter algum tipo de diretório _global_ contendo dependências para todos os aplicativos (a estrutura plana do npm 3 pode ajudar). Isso, no entanto, pode ficar muito complicado, muito rápido (por exemplo, ao desinstalar um aplicativo).
• Vários ambientes de execução locais : se o versionamento semântico foi aplicado até agora, existem apenas duas versões incompatíveis por aí 0.x e 1.x . As versões secundárias e patches devem ser compatíveis com versões anteriores, portanto, precisamos apenas da versão mais recente de 0.x e 1.x no sistema.

Inspirações:

• Gerenciador de ambiente/dependência: virtualenv do Python, virtualenv rbenv Ruby e também veja ruby-build .
• Gerenciador de pacotes: pip do Python, pip apm Atom.
• Gerenciador de atualizações: o processo zygote do Chromium tem uma abordagem interessante para atualizações _silenciosas em segundo plano_.
• Tradutores de código (para adaptação às novas APIs): Pythons 2to3 .

epm (gerenciador de pacotes de elétrons) parece já ter sido usado como nome ...
Talvez chamar o tempo de execução elec e os aplicativos .tron ? Provavelmente existem alguns problemas de marca registrada com o TRON, mas seria legal ;)

Talvez uepm (gerenciador universal de pacotes de elétrons), já que deve ser executado em todos os sistemas operacionais suportados por Electron... ou epmc (centro de gerenciamento de pacotes de elétrons) e o arquivo .epack (pacote de elétrons). A extensão, pelo menos, soa melhor que .tron e não pode ser confundida com um filme ("me dá aquela coisa do tron, cara" _entrega o filme_).

Há também uma série de palavras no campo da física teórica relacionadas ao elétron.

• férmion
• lépton
• carregar
• coulomb
• pauli

E, não relacionado diretamente, mas um pouco mais de acordo com o que está acontecendo com um gerenciador de pacotes,

• bóson
  ;)
  (acredito que o fóton já foi tirado)

@kapouer +quark? não tenho certeza se é tomada embora

Quark está tomado, o resto eu não sei. Mas por que devemos manter o status quo, quando esta lista de sugestões sugere NÃO manter o status quo? Mas já que estamos nisso, por que não chamá-lo de Hauldron? Tirado do LHC. Collider não é uma boa ideia, está dando um tom negativo ao produto, porque seu significado está intimamente ligado à guerra...

Particle(s) ? Embora bastante longo.
Lista de partículas no wiki

Embora a nomenclatura seja importante, ainda acho que precisamos investigar a semântica de tempo de execução/atualização/empacotamento/distribuição primeiro.

lepton parece perfeito, pois é a família de partículas à qual o elétron pertence.

Uma ideia um pouco fora do escopo: um gerenciador de tempo de execução mais genérico seria ainda mais incrível (e não muito mais difícil de implementar). Por exemplo, poderíamos incluir os binários @nwjs também e gerenciá-los no mesmo gerenciador de versões (assim como @asdf-vm, mas para tempos de execução de GUI).

Rápido e sujo: https://github.com/iamale/lepton. Suporta apenas a versão fixa por enquanto (semver é a próxima coisa a fazer), e os aplicativos são descompactados (ou seja, não há .asar-s ainda).

Agradável!

+1

Mesmo se não houver .asar, @iamale , contanto que você tenha alguma maneira de saber qual arquivo abrir, acho que deve estar tudo bem. Como, por exemplo, você poderia ter um file.something com código json vinculado a package.json para que ele saiba o que abrir...

Essa é uma ideia bem maluca, mas que tal usar o campo electron em package.json para fazer
algum executável de pacote npm (bem, não como QUALQUER, mas preparado)?
Como:

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

Isso pode ser alcançado adicionando a capacidade de electron instalar pacotes npm e torná-los executáveis ​​e visíveis para o sistema host.
Assim como

electron install atom

Para que isso funcione, precisaríamos dividir o comando electron e os pacotes de tempo de execução reais.

mas que tal renomear o package.json para package.electron e ter seu conteúdo algo assim?

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

Neste exemplo, recomenda-se usar o electron 1.2, se não for encontrado também verifica se existe alguma versão entre 1.2.1 e 1.2.5, se não for 1.3.1, então para 1.3.0.1, se não for verifica para 1.1 e se não, downloads 1.2.

Talvez possa haver algo como baixar automaticamente a versão recomendada, e não pode, então verifica as versões compatíveis. E pegue cada um dos compatíveis e verifique-os, e se nenhum funcionar, pergunte ao usuário se ele deseja não usar uma versão incompatível, e se ele pressionar no , ele rodará com uma versão incompatível encontrado no PC, e se nenhum for encontrado, em vez de pedir para usar uma versão incompatível, mostra um pop-up de erro dizendo que não foi detectada nenhuma instalação do Electron.

@sapioit Ter um manifesto separado parece uma boa ideia para mim. Ter uma extensão de arquivo personalizada simplificaria bastante as coisas. (Embora .electron pareça um pouco longo.)

Talvez de acordo com o lépton de @iamale , .lept?

Não vejo nenhum benefício em não usar package.json , o campo de elétrons faz a parte de isolamento. Babel e ESlint usam essa técnica e estão indo muito bem.
Isso torna muito mais fácil publicar aplicativos diretamente para/via npm.

Sim, eu apoio @YurySolovyov - acho que colocá-lo em package.json é mais apropriado

@YurySolovyov A vantagem de um arquivo adicional é que o tempo de execução pode registrar um manipulador para a extensão do arquivo adicional e ser executado automaticamente como o abridor padrão do arquivo. Considerando que fazer isso com package.json exigiria o registro do manipulador para cada arquivo JSON, o que seria um problema para os usuários.

@Tribex ponto justo.
Talvez package.electron possa ser apenas algum tipo de link que diga ao tempo de execução "Hey, take a look at package.json, it should contain the info on how to launch it" . Esta foi uma ideia "louca", então sim, estou bem em ajustá-la.

Concordo com @tribex , precisamos de um arquivo separado ou renomear o package.json. para outra coisa.

@wurysolovoyov você não pode fazer isso. A única coisa que você pode abrir um arquivo é ter uma extensão anexada a ele, caso em que todas as extensões serão abertas com o mesmo software. Então, a menos que você esteja bem em ser incapaz de abrir um .json com qualquer coisa além de electron (o que seria apenas um erro, a menos que um aplicativo eletrônico adequado seja aberto), você ainda pode fazer isso, mas deixe que nós, aqueles que querem poder abrir arquivos .json , consigamos abri-los com o programa com o qual queremos abri-los.

Caso contrário, você não poderá editar o arquivo, sem abrir o editor primeiro ou alterar o que abrir .json a cada minuto.

Quero dizer @YurySolovyov não @wurysolovoyov

Talvez eu não tenha dito claro: o propósito de package.electron é apenas servir como um marcador de que este diretório é um aplicativo, para que o tempo de execução possa se referir a package.json que está na mesma pasta e inicie um aplicativo. Se você abrir o package.json diretamente, ele será aberto no que estiver associado a .json no seu sistema operacional.

Uma espécie de sistema de atalhos.

@YurySolovyov Nesse caso, é apenas uma questão de gosto definirmos essa informação em package.json ou package.electron. Eu pessoalmente o manteria separado simplesmente porque parece mais limpo para mim. Talvez a propriedade engines em package.json seja suficiente.

@Tribex também é um requisito para publicar o aplicativo no npm - ter package.json válido

@YurySolovyov Certo. Se usássemos package.electron, package.json ainda estaria presente. .electron serviria apenas para definir informações de tempo de execução, ou, no caso de sua sugestão, seria apenas um marcador.

Basicamente, o package.electron estaria lá apenas como um _marker_ inicializável, então o package.json ainda estaria presente com seus próprios dados, mas é por isso que um arquivo separado seria necessário: _duplo clique abre o aplicativo _. Eu ainda gostaria de poder renomear package.electron para my-app.electron ou my-app.electron .

@sapioit claro, esse é o objetivo de ter o arquivo .electron , você pode nomeá-lo como quiser, desde que tenha a extensão .electron .

Ainda não me parece muito claro que o manipulador de tempo de execução tenha que olhar para *.electron, depois para package.json para determinar qual versão do elétron executar, que então lê package.json novamente.

@Tribex por que você acha que package.json seria lido duas vezes?

• Se colocarmos as informações de tempo de execução no arquivo .electron , o tempo de execução iniciará o aplicativo usando package.json supondo que tudo esteja correto e com falha rápida se não estiver.
• Se colocarmos o tempo de execução em package.json diretamente ou na seção electron , isso também exigiria apenas 1 leitura. Dessa forma, não tenho certeza do que colocar no arquivo .electron (idéias?), ficaria bem mesmo com ele vazio.

@tribex O .electron poderia apontar para o package.json , caso, por algum motivo, o package.json seja renomeado. Dessa forma, você poderia ter um package.json para NPM e um package.json diferente (talvez electron.json ) para o Electron. Por quê? Talvez você queira que seu aplicativo tenha o package.json para saber quais coisas importar com o gerenciador de pacotes, mas uma vez importado, você deseja executá-lo sem precisar mover ou renomear arquivos.

_ app.electron _

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

ou

_ myapp.electron _

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

Ou, se colocarmos tudo em package.json , poderíamos ter o único link .electron para o .json que queremos usar para abrir o aplicativo, então:

_ app.electron _

{
  "package": "package.json"
}

ou

_ myapp.electron _

{
  "package": "electron.json"
}

Além disso, talvez você queira ter dois lançadores no mesmo diretório, um para o cliente e outro para o servidor, com o cliente usando os arquivos do servidor para iniciar um servidor local com apenas um player. Dessa forma, você não precisará duplicar todos os 99% dos arquivos (supondo que você tenha um jogo que use mais de 500 MB de arquivos) e 5-6 arquivos diferentes, e tê-los em dois diretórios separados, mas apenas um extra arquivo para poder iniciar o servidor por conta própria. Literalmente, o mesmo que ter vários executáveis ​​no mesmo diretório.

package.electron separado deve ser nomeado package.electron.json ou algo que tenha extensão .json para que os editores e o IDE determinem a sintaxe corretamente.

@StreetStrider Prefiro ensinar aos IDEs que .electron é realmente válido .json .
E isso também nos leva ao ponto que discutimos com @sapioit sobre associações .json . Eu não acho que nenhum sistema operacional popular suporte associações de extensão dupla. ( .foo.bar )

Você pode adicionar a extensão .json ao editá-la. ou clique com o botão direito e abra com um editor, mas assim como o Adobe Air, que, por padrão, abre o arquivo com seu launcher, permitindo ao usuário abrir o arquivo com um editor, isso não causaria problemas.

@sapioit Ponto justo, acho que concordo com você sobre apontar para o package.json.

Para mim, um tempo de execução e um jogador são duas coisas separadas. Isso está saindo mais como um jogador agora. E não parece que teria qualquer uso generalizado fora de uma comunidade tecnicamente inclinada que está acostumada com os conceitos de gerenciadores de pacotes.

O problema em questão é criar um tempo de execução. Tipo como JRE e .Net. Não um jogador.

@baconface Talvez você possa elaborar? Não está claro qual é a distinção que você está fazendo aqui.

@baconface sim, mas JRE e .Net também são instaláveis.
Sem JRE, arquivos .jar são tão inúteis quanto pacotes sem tempo de execução electron .

Idealmente, esta ferramenta seria distribuída com ou como o principal método de instalação do elétron, idealmente aliviando o problema de propagação.

Para isso, você só precisaria de uma pequena ferramenta para fazer um executável que lançaria um determinado arquivo, ou seja, o .electron imputado. Simples assim.

.lept parece incrível, obrigado!

Pessoalmente, acho que não há necessidade de inventar nenhuma nova configuração, pkg.engines parece bastante simples para mim aqui (deve permitir algumas expressões semver complicadas, como 1.x || >=2.5.0 || 5.0.0 - 7.2.3 dos documentos do npm , então não há necessidade de { recommended, compatible, etc } -estruturas como nos exemplos de @sapioit , acredito). (Adicionei um campo lepton , porque scripts.run geralmente é invocado por npm start , e o lepton quebra a semântica adicionando seu próprio $VARIABLES .)

Ou, se colocarmos tudo em package.json, poderíamos ter o link .electron apenas para o .json que queremos usar para abrir o aplicativo

Também não me parece uma grande ideia. Se tivermos um pacote com vários pontos de entrada, ainda poderíamos tê-los todos em um package.json, como temos um mapa scripts agora. Estou pensando em algo assim:

// 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

Então, se você realmente quer isso como arquivos executáveis, no Linux / macOS você pode usar scripts de shell simples (3 linhas incluindo #!shebang), e no Windows... bem... ¯_(ツ)_/¯

Primeiro, você pode querer dar uma olhada neste artigo, que oferece uma alternativa melhor para semver, enquanto ainda é compatível com praticamente tudo lá fora: Release.Breaking.Feature.Fix ou por que a Versão Semântica deve ser substituída por Versão Explícita como assim que possível

Em segundo lugar, a questão é como realmente diferenciá-los. Quer dizer, se server.js já aceita o argumento --debug , por que se preocupar com isso e não permitir que as pessoas tenham suas próprias configurações de arquivo. Talvez o servidor exija configurações diferentes do cliente, como o cliente trabalhando em 2.2-2.4 e o servidor trabalhando apenas em 1.4-1.9.2.1 ...
Fazendo como você sugeriu, só seríamos mais limitados.

Além disso, que tal usar mais variáveis, não apenas --debug ? Como vou executá-lo com mais variáveis ​​como essa? É seguro fazer isso? Afinal, se eu quisesse que um arquivo fizesse isso, eu poderia ter feito isso mesmo com arquivos separados, mas dessa forma isso atrapalha os possíveis resultados de executar o arquivo .lept com parâmetros.

Se eu quisesse rodar o servidor com o parâmetro debug, eu não iria simplesmente iniciar o .lept com o argumento --debug ? Ou eu poderia criar outro arquivo para iniciar esse arquivo com o argumento --debug . Não é tão simples?
Espero estar fazendo sentido...

Primeiro, você pode dar uma olhada neste artigo, que oferece uma alternativa melhor para semver

Acho uma ótima ideia! Eu não acho que o Electron vai mudar para esse esquema de versão, no entanto. Também acredito que, embora seja ótimo para produtos de usuário final, não precisamos dele para bibliotecas, mecanismos, tempos de execução e outras coisas. Idealmente, o usuário nem deve saber qual versão do Electron está executando (a menos que queira).

Talvez o servidor exija configurações diferentes do cliente

Isso pode ser um problema, mas não consigo imaginar um projeto que precisaria de mais de uma versão de um tempo de execução.

Se eu quisesse rodar o servidor com o parâmetro debug, eu não iria simplesmente iniciar o .lept com o argumento --debug?

Sim, porque não:

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

Este pacote.json de configuração dupla é ótimo para casos em que o servidor a) compartilha muita base de código com o cliente eb) é destinado a ser executado por usuários finais. Em outros casos, faria sentido separar tudo em dois repositórios/pacotes, cada um com seu próprio package.json.

Não é para Electron, mas para os projetos que você constrói. O Electron, provavelmente, tem seu próprio sistema derivado do Versionamento Semântico para atender às suas necessidades, e é improvável que eles o mudem, mas para Lepton e outros projetos que não estão tão longe em _ development hell _, pode ser uma boa ideia pular completamente o versionamento semântico.

Se eu quisesse rodar o servidor com o parâmetro debug, eu não iria simplesmente iniciar o .lept com o argumento --debug?

Sim, porque não:

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

Não, não quero dizer na configuração, mas através do launcher. Então, é isso:

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

Mas inicie o .lept com o argumento --myoption=5 sem tocar nos arquivos (além de abri-los). Como tenho certeza de que você pode "_push_" o argumento através do iniciador, você também pode remover a necessidade de --debug , já que você o iniciará com o argumento personalizado, se desejar.

Mas em uma coisa acho que podemos concordar: os usuários querem estar em uma versão estável para a qual estão recebendo suporte. Por isso fiz o " Lançamento " com número próprio, porque as pessoas dificilmente se lembrarão de muitos números, mas geralmente lembram do primeiro.

@sapioit se o campo "Release" for para usuários finais, para que servem os outros? Para o usuário final, isso não deve importar, se uma nova versão estiver disponível e exigir tempo de execução atualizado (via bump em package.json), então o tempo de execução também deve ser atualizado.

Aqui estão os problemas:

1. Os usuários querem saber para qual versão eles estão recebendo suporte .
2. Eles não querem se lembrar de muitos _números inúteis_, então se eles escolherem se lembrar da versão, é mais provável que eles se lembrem da versão 13 do que da versão 1.7 (por exemplo).
3. Algumas pessoas não querem atualizar até que certas coisas aconteçam, como alguns drivers nVidia não estão sendo atualizados porque desde que a compatibilidade Thunderbolt foi adicionada, suas placas gráficas são ejetadas aleatoriamente (dependendo do usuário/caso , seja após inicializar o computador, após abrir um jogo ou alguns minutos após o jogo). Este é um bom exemplo de um motivo (mas existem muitos outros, como os anúncios do KMPlayer ou locked on atualizações automáticas ) que impedem os usuários de usar a versão mais recente de um produto. Isso facilita a visualização do changelog, removendo a complexidade dele.

Essas são apenas algumas das razões... se você pudesse entrar em mais detalhes, eu também poderia entrar em mais detalhes e explicar melhor por que essas escolhas foram feitas.

@sapioit Os intervalos semver como >= 12.1 são flexíveis o suficiente para declarar suporte?
Se houver uma nova versão do tempo de execução disponível e ela satisfizer o intervalo de versões, todas as próximas inicializações de um aplicativo devem usar o tempo de execução mais recente possível.

Eles deveriam? Mas e se eles decidirem não fazer isso, devido a limitações técnicas (como os anúncios do KMPlayer e os drivers nVidia)?

@sapioit Em seguida, certifique-se de ter declarado seu intervalo de tempo de execução corretamente

@sapioit @YurySolovyov Essa discussão é relevante aqui? Um gerenciador de tempo de execução teria que seguir qualquer sistema de controle de versão que o elétron esteja usando. Acredito que uma discussão sobre qual sistema de controle de versão elétron _deve_ estar usando pertence a outra questão.

@Tribex um pouco. Eu estava tentando dizer que não devemos complicar demais as coisas que já estão basicamente resolvidas. Mas concordo que o gerenciador de tempo de execução deve fazer a coisa mais simples possível a esse respeito.

@yurysolovyov Então, por que não simplesmente permitir quantas seções no número da versão o jogador quiser?

@sapioit

Não é para Electron, mas para os projetos que você constrói.

O Lepton não tem um esquema de versão atribuído (ainda), e os pacotes (aplicativos) podem usar qualquer esquema de versão que desejarem. Precisamos lidar com isso (por exemplo, se quisermos oferecer suporte à atualização de aplicativos por meio do próprio Lepton).

Os tempos de execução, idealmente, devem usar semver, pois não são produtos, mas, novamente, qualquer versão de 3 números é suportada agora (os desenvolvedores precisariam ter cuidado ao especificar intervalos). Se precisarmos dar suporte a mais de 3 números (como com sua proposta de versão explícita), precisaremos estender o analisador (para Python, sugiro bifurcar k-bx/python-semver ou podhmo/python-semver — o primeiro foi atualizado mais recentemente, enquanto o primeiro segue a API node-semver com mais força e é o que estou usando atualmente).

Posso apenas dizer que ter um gerenciador de pacotes de tempo de execução escrito em python para um projeto nodejs é apenas uma má ideia.
Apenas não vamos fazer isso. Seja como for chamado, lépton, ou qualquer outra coisa. Vamos escrevê-lo no nó ou usar outra coisa. E não vamos enviar spam a esse problema com e-mails desnecessários sobre como você acha que sabe melhor do que o esquema de versão semântica bem pensado

@championswimmer Seria interessante construir o gerenciador de tempo de execução com uma versão do electron empacotada com ele e uma interface do usuário para mostrar quando outras versões estão sendo baixadas.

@championswimmer iamale/lepton é uma espécie de implementação de referência descartável: acabei de colocá-lo para testar várias ideias flutuando em torno deste tópico, nada mais.

@iamale talvez você deva declarar no readme para evitar confusão então?

@YurySolovyov Pronto!

Quanto à implementação real, temos duas opções: ou usamos node.js, ou uma linguagem compilada como C/++ ou Go; e para node, teríamos que agrupar node.js com ele (ou talvez apenas executá-lo em uma das instâncias do electron baixadas? No entanto, precisaremos garantir que ele seja executado em _qualquer_ versão de elétron sã).

@iamale Na verdade, não, apenas temos que executar uma versão instalada padrão. Depois disso, as atualizações podem mudar para a versão mais recente no local.

Prefiro optar por usar uma determinada versão, pois, se necessário, tudo pode ser atualizado...

Lepton pode não ser um nome tão bom agora que é um formato de imagem .

Então... como vamos chamá-lo agora? Hadron ?

Quark? Se alguém quiser usar o nome "Muon", posso renomear um dos meus projetos.

A nomeação não é realmente a parte menos importante aqui?
Nós concordamos com a semântica de instalação/atualização/tempo de execução?

Por que não apenas electron ...

Op 15 jul. 2016 às 13:22 heeft Joshua Bemenderfer [email protected] volgende geschreven:

Quark? Se alguém quiser usar o nome "Muon", posso renomear um dos meus projetos.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@yurisolovyov Acho que concordamos... mais ou menos.
@job-v Isso é o que venho sugerindo o tempo todo. Apenas vamos escolher um e ficar com ele.

@zcbenz você está observando este tópico?
Se assim for, seria bom ter alguma visão de como isso deve funcionar para obter algumas direções aqui.

Oi
alguma atualização sobre este runtime de elétrons ?
@zcbenz o que você acha de toda a discussão sobre:

• selecionando a versão eletrônica
• instalando a versão apropriada
• prepará-lo para trabalhar em win, linux, mac
• que ferramenta usar para construir com ele (python, node, go, c++)?
  @YurySolovyov @sapioit obrigado por suas ideias incríveis
  @iamale é o seu trabalho de solução para destros baseados em debian 'ubuntu ...'

@alnour-altegani
Sim, funcionaria para qualquer distribuição baseada em dpkg porque não dependemos de pacotes externos. Os pacotes RPM podem ser gerados de forma semelhante, por que não?

Estou pensando em iniciar um repositório central para todas as coisas do Electron, ou seja, você pode executar:

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 Eu acho que faça o electron como pacote deb e use-o como dependências no aplicativo para ser instalado manualmente ou do repositório central para muitos pacotes deb da versão do electron.
e, em seguida, use este pacote após a instalação para executar o aplicativo do usuário

Se alguém começar a trabalhar em algo para isso, talvez link para isso aqui ...

@sapioit Comecei a trabalhar em uma solução Linux (APT/RPM). Um serviço simples para o qual você carrega .asar e ele é convertido em pacotes e adicionado aos repositórios. Deve ser extensível para Windows e macOS também, mas não há promessas sobre isso por enquanto.

@iamale Legal! Deixe-me saber quando você começar a trabalhar no Windows.

Que tal fazer um tempo de execução Flatpak para Linux? Dessa forma, o tempo de execução pode ser compartilhado entre vários aplicativos e você também obtém sandboxing.

Com o Flatpak removendo sua dependência de systemd , provavelmente se tornará universal no Linux para empacotamento upstream.

o tempo de execução pode ser compartilhado entre vários aplicativos

Achei que com Flatpak não seria possível?..

O @iamale Flatpak foi projetado para compartilhar tempos de execução - os desenvolvedores de aplicativos escolhem um tempo de execução, instalam o SDK para esse tempo de execução e, em seguida, criam um aplicativo com flatpak-builder ou similar. Então, quando o usuário instala o aplicativo, o Flatpak instala o runtime associado.

@moosingin3space Obrigado pela explicação! Definitivamente vale a pena considerar então.

A outra coisa que eu gosto no Flatpak é que ele foi projetado em torno do caso de uso em que um usuário adiciona um repositório executado pelo dev de tempo de execução e app dev (transparentemente) e isso torna as atualizações automáticas.

As únicas coisas que vejo como problemas estão relacionadas à segurança - necessidade de modificar as bibliotecas do sistema para usar a interface "portais" no Flatpak para permitir a saída segura da sandbox.

Parece haver trabalho no Flatpak aqui: https://github.com/endlessm/electron-installer-flatpak

Como nota lateral, o Flatpak é baseado no projeto OSTree , que faz o endereçamento de conteúdo para árvores do sistema de arquivos. Isso significa que arquivos com somas de verificação idênticas são automaticamente desduplicados no disco e que as atualizações são executadas usando deltas estáticos. Isso significa que não apenas o Electron pode fornecer um tempo de execução de compartilhamento que pode ser atualizado e compartilhado independentemente entre aplicativos, mas também que aplicativos criados em arquivos idênticos os compartilhariam automaticamente no disco e que, uma vez instalado um aplicativo e/ou um tempo de execução, as atualizações não exigiria um download completo.

Perdoe-me se isso é um pouco ingênuo, estou me perguntando se a possibilidade de construir um ambiente de desktop como uma progressão lógica natural do ambiente de tempo de execução foi considerada. A ideia é que existe um aplicativo de lançamento que o elétron carrega na inicialização (em vez de, digamos, átomo) com a capacidade de iniciar outros aplicativos de elétrons (dada a grande biblioteca crescente) gerando novas instâncias do renderizador ou talvez até reutilizando-o e tenha aplicativos abrem em uma nova guia.

O Chrome, como no sistema operacional, no meu entendimento, parece ser exatamente isso (mas se limitando a aplicativos da web). Ter aplicativos de desktop com acesso fs completo por meio de nodejs (em oposição às limitações de chromeAPIs) com electron como um ambiente de tempo de execução em cima do Linux (ou mesmo substituir ou pelo menos aumentar no início explorer.exe no Windows) seria muito emocionante. Eu acho que esta é uma solução mais limpa do que o ChromeOS, que está carregando o que é efetivamente um tempo de execução e, em seguida, um mecanismo de navegador e, em seguida, hospeda um aplicativo - aqui um carregará aplicativos diretamente no tempo de execução e o próprio navegador será apenas outro aplicativo (e há tantos muitos projetos inovadores de navegadores eletrônicos à solta).

Novamente, estou querendo saber se isso foi considerado ou se já existe algum projeto fazendo isso. Se não, talvez uma fada possa colocar uma palavra nos ouvidos do gerenciamento do Github por assumir a liderança????

PS: Uma coisa que não estou sugerindo aqui é portar o OS.js (que é um projeto bonitinho por si só) para o elétron, mas criar um ambiente para aplicativos de elétron (embora eu não seja avesso à reutilização de código do OS.js).
PPS: Vou criar um problema separado se for considerado digno o suficiente ou se for uma distração para o problema de um ambiente de tempo de execução.

Eu acho que um ambiente de tempo de execução integrado tornaria os aplicativos Electron muito melhores. Acho que empacotá-los deve ser apenas compactar os arquivos e renomear a extensão para asar , mas esse arquivo deve ter duas pastas, uma chamada asar , com o conteúdo da pasta de tempo de execução padrão e uma chamado enviroment com arquivos que devem substituir a configuração padrão.

Por exemplo, a execução de um novo aplicativo copiaria a versão necessária do Electron em uma pasta temporária e moveria o tempo de execução (conteúdo da pasta asar ) para o local de arquivos padrão, enquanto a pasta opcional enviroment (com 3 subpastas, windows , linux , macosx ) deve conter arquivos que serão colados sobre a pasta padrão, substituindo seu conteúdo.

Dessa forma, precisamos apenas de um aplicativo ou algo assim para avaliar a extensão .asar de um aplicativo e fazer com que esse aplicativo acesse a pasta com as versões baixadas do Electron (arquivadas), copie (extraia) para uma pasta temporária , e use o conteúdo do .asar para modificar o que é necessário, execute a instância Electron dessa pasta temporária e espere que ela morra para forçar a exclusão da pasta temporária. Para começar, mesmo obter apenas a configuração padrão para funcionar com um arquivo com uma extensão personalizada em todos os sistemas operacionais suportados seria muito mais do que já temos. Depois disso, podemos nos preocupar em ter uma terceira pasta, config , onde manter as configurações atuais, e talvez uma pasta _config dentro dela, para as configurações padrão (se precisarmos delas ).

Com os aplicativos empacotados do Chrome sendo eliminados em breve, as pessoas vão procurar alternativas. Um tempo de execução seria ótimo para projetos menores que nem sempre terão versões/lançamentos disponíveis. Como os aplicativos são feitos com tecnologia da Web, assim como os aplicativos do Chrome, seria valioso para um usuário simplesmente executar o aplicativo a partir da fonte. Não posso justificar a portabilidade de inúmeros projetos menores para o Electron se a única maneira de um usuário executá-los é baixar uma grande versão binária para cada script ou aplicativo individual, e os usuários não podem aproveitar a execução do commit mais recente sem compilá-lo ou baixar o Electron's próprios IDE.

Olá a todos, mesmo que eu não esteja no mundo centrado em JS, recentemente tive uma ideia bem parecida com o _Electron_ (que por acaso eu conhecia, mas não uso para desenvolvimento) mas com um público mais amplo; para colocar de uma maneira muito simples: _apenas limite as tecnologias web à GUI e forneça APIs._

Portanto, continue com uma biblioteca / runtime compartilhada com versão semântica (construída em cima de _Blink_, _Skia_, etc; talvez em – “moderno” – _C++_) e deixe os desenvolvedores escolherem a linguagem usando ligações…
por exemplo, você quer _JS_, use _Node.JS_; você quer _C++_, sem problemas; você quer _Python_, com o padrão _CPython_ deve ser possível; algo mais ? talvez _SWIG_ possa ajudar. Em (quase) qualquer caso, vencemos.

Uma vez que tenhamos a biblioteca/tempo de execução compartilhado (dependente do SO), você resolve o problema principal e pode elaborar da maneira que achar melhor entregar o resto (além de revolucionar/modernizar a abordagem de programação GUI para o resto de nós; um grande passo em frente!).

Então o ponto de partida deve ser o "split" (deveria até ter um nome relacionado à física, dado o fato de que você parece realmente se importar com isso) do projeto _Electron_… :)

Não podemos nem fazer um addon para o Electron, mas acho que não vai ter tanto sucesso, a não ser muita publicidade.

@dezzeus Houve um esforço nestas linhas antes que fracassou. Dê uma olhada no tempo de execução de impulso destinado a hospedar o navegador de violação .

Li este longo e fascinante tópico duas vezes, pois adoraria ver mais impulso nessa direção. Aqui está a última declaração de @zcbenz , acredito que ainda seja relevante:

Não há nenhum obstáculo técnico na implementação disso, a coisa toda pode ser apenas um aplicativo Electron. Mas o problema é que também não é fácil de implementar, levando em conta todos os detalhes, acho que _requer uma pequena equipe trabalhando em tempo integral_, não tenho certeza se isso aconteceria.

(Ênfase adicionada) - Como interpreto isso, se a solução for construída, dependerá do esforço da comunidade e/ou das necessidades de negócios do GitHub e de outras organizações interessadas nela.

Uma visão geral concisa de @yan-foto parece um plano sensato de abordagem, com objetivos/requisitos claros. Há uma implementação/protótipo de referência chamado lepton por @iamale , propondo um "gerenciador de versão de tempo de execução universal" direcionado ao Electron. Um comentário de @jorangreef foi intrigante, pois ele descreve "um aplicativo em produção com um mecanismo de atualização automática semver", com atualização diferencial, deduplicação (não tenho certeza se os dois são os mesmos) e compactação. Muitos dos recursos que ele descreveu pareciam perfeitos para adaptação/adoção.

Esses são passos definitivos de exploração e progresso, e isso me dá esperança de que soluções gerais dignas de produção nascerão desse processo.

É bom ver que ainda existem pessoas com fé na humanidade.

A única coisa que impede que isso se torne um produto é a falta de oportunidades de negócios imediatas abertas pela fabricação desse produto (conceito).

@eliot-akira sim, é isso. O código que escrevi faz a desduplicação baseada em conteúdo por arquivo (pedaços de tamanho variável) em um arquivo para minimizar os downloads quando apenas alguns bytes dentro de um arquivo são alterados. Ele também atualiza apenas os arquivos que mudam entre as versões e as atualizações do aplicativo como um todo são atômicas diante de quaisquer erros. A nova versão será lançada ou a versão antiga permanecerá em vigor.

Eu gostaria de abrir o código do código, e há algumas coisas que eu ainda precisaria codificar para a ideia geral. Seria ótimo se vários aplicativos Electron pudessem compartilhar um único processo de supervisor de atualização automática (com um cache imutável local compartilhado para desduplicação em vários aplicativos Electron independentes).

O objetivo de toda essa abordagem seria minimizar a largura de banda geral de download necessária para instalar e atualizar os aplicativos Electron, mantendo os aplicativos Electron completamente isolados uns dos outros (vários aplicativos teriam seus próprios binários Electron). Uma não meta seria minimizar a pegada de disco.

A primeira instalação do aplicativo Electron precisaria ser baixada por completo, mas as instalações subsequentes do aplicativo Electron se beneficiariam do cache imutável compartilhado local.

Desde que chegou a atualização automática, eu tenho que trazer o problema de versionamento, e o fato de que vários sistemas de versionamento parecem estar usando diferentes números de dígitos para versionamento. Eu, por exemplo, estou usando o Explicit Versioning .

Temos dois tipos de coisas que precisam ser atualizadas aqui:

• O próprio Electron, que usa o controle de versão eletrônica e
• Apps, para os quais realmente não precisamos nos preocupar com SemVer ou qualquer coisa, pois geralmente não possuem uma API (a menos que utilizem algum tipo de sistema de complemento, talvez).

Embora, se precisarmos oferecer suporte a vários sistemas de versão, talvez possamos ter alguma configuração em package.json , como "breakingVersionComponents": 1 para semver e 2 para versão explícita ou versão eletrônica?

(Outra opção seria adicionar outro separador na versão, como 1.3:3.7 que separaria as partes com e sem quebra. Semver então se torna x:y.z e Versão eletrônica x.y:z . Isso seria quebrar todas as ferramentas lá fora, no entanto, eu acredito.)

@jorangreef Se cada aplicativo ainda tiver seu próprio binário Electron, isso não resolveria o problema de uso excessivo de RAM ao ter vários aplicativos Electron abertos.

Percebi um comentário mais antigo de @joshuawarner32 , que eu havia esquecido. Ele menciona um exemplo já funcionando, ainda não uma solução de propósito geral, mas o resumo é:

- 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

Junto com o exemplo do @jorangreef (obrigado pela explicação adicional - edit: ah, eu não sabia que cada aplicativo tem seu próprio binário Electron, que é um modelo diferente do que eu pensava), vejo que as pessoas já estão construindo seus próprias soluções específicas para o problema de um tempo de execução compartilhado - que também fornece recursos de algum tipo de lançador/gerente de aplicativos . Seria ótimo ver alguma convergência, dividir alguns desses recursos mencionados em módulos de uso geral.

Gostaria de saber se existem módulos não específicos do Electron que possam ser aproveitados, como o mecanismo de download: servidor de tempo de execução, controle de versão, atualizações diferenciais. Parece um pouco assustador construir tudo do zero, se outros já "resolverem" algumas dessas áreas. @iamale , obrigado pelo seu trabalho no Lepton , aos meus olhos esta é uma implementação concreta na direção de uma solução.

Outra ideia: apenas publique aplicativos em npm e crie um wrapper npm especial que possa instalá-los e executá-los. Seria realmente fácil de implantar e provavelmente fácil de usar (dependendo da qualidade do wrapper) também. O que vocês acham pessoal?

Para projetos oss, poderíamos usar o npm como hospedagem, para os de código fechado, precisamos apontar o gerenciador de pacotes para o arquivo .asar para download e talvez mais alguns metadados. A questão é, como será esse tipo de gerente (e chamado)

Além disso, gostaria de saber se realmente precisamos de um comando separado para instalar aplicativos, talvez apenas
electron install atom seria suficiente?

Acabei de ver isso no Node Weekly:

O Electrino é uma alternativa experimental de peso-pena ao popular e poderoso Electron. Ele implementa uma porção minúscula das APIs disponíveis no Electron, mas o tamanho do aplicativo de saída é muito menor.

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

https://github.com/pojala/electrino

@YurySolovyov Projetos de código fechado não devem ter problemas em serem publicados em npm também - já existem alguns Node.js por aí, ou seja, inclua . (Tecnicamente, não está em npm, apenas um carregador, mas de qualquer maneira não consigo ver como o sideload .asar's ajudaria, pois eles ainda podem ser descompactados.)

Eu estava apenas tentando pensar como podemos reutilizar o máximo possível do ecossistema existente.

Não tenho certeza se queremos...

@jorangreef Se cada aplicativo ainda tiver seu próprio binário Electron, isso não resolveria o problema de uso excessivo de RAM ao ter vários aplicativos Electron abertos.

@Jop-V Não, não seria. Não quero confundir as coisas e acabar com um monstro. A ideia é ter um ótimo instalador/auto-atualizador que resolva a maioria dos problemas no comentário que abriu esta edição: https://github.com/electron/electron/issues/673#issue -44580957

O problema não é tanto ter vários binários no disco, mas o impacto da rede em um usuário ter que baixar e atualizar automaticamente várias cópias do mesmo binário.

Resolver o uso de memória definitivamente vale a pena. Acho que existem várias maneiras de fazer isso, mas elas não precisam necessariamente ser empacotadas com um instalador/atualizador automático de desduplicação.

Se a pegada do disco também for um problema, isso pode ser resolvido por meio de hardlinks em sistemas que o suportam, embora isso comece a infringir a ideia de isolamento entre aplicativos (por exemplo, se um aplicativo decidir gravar em um hardlink compartilhado com outra coisa).

Alternativamente, pelo menos no macOS a médio prazo, o APFS copiará arquivos por referência, com desduplicação transparente sob o capô, minimizando o espaço de disco. Isso seria melhor do que hardlinks, pois manteria o isolamento intacto (copy-on-write).

@jorangreef Qual é o objetivo de usar binários Electron separados para aplicativos? De que tipo de isolamento você está falando? Desculpe se for uma pergunta idiota, mas não entendi.

@iamale Alguns aplicativos podem ter como alvo diferentes versões oficiais do Electron ou podem distribuir um Electron pré-construído compilado a partir de fontes modificadas. Essa abordagem funcionaria com todos eles. Mesmo com grandes diferenças nos binários (ao contrário de JS e alterações de ativos), a desduplicação eliminaria 70% ou mais dos requisitos de download, de modo que os aplicativos direcionados a binários diferentes ainda seriam beneficiados.

Com essa abordagem, é até possível enviar qualquer tipo de pacote (qualquer conjunto de arquivos e diretórios definidos por um manifesto JSON), não necessariamente apenas aplicativos Electron. Também pode ser um aplicativo Python. É agnóstico a qualquer escolha que o desenvolvedor queira fazer em relação a como estruturar ou empacotar seu aplicativo (arquivos vs asar etc).

A ideia principal é que o ecossistema se beneficie de deltas de instalação/atualização muito pequenos, pois mais e mais aplicativos usam o mesmo instalador/atualizador automático. Atualmente, cada aplicativo está executando seu próprio atualizador automático de supervisão e isso é desnecessário.

@jorangreef Obrigado! Eu acho que é muito parecido com os repositórios APT/RPM clássicos, apenas mais “inteligentes” (sem necessidade de declarar suas dependências ou qualquer outra coisa).

A questão é, como será esse tipo de gerente (e chamado)

E quanto Minifitron (elétron minificado)?

Acho que o arquivo (ou seja .asar ) deve conter o conteúdo da pasta onde está o binário do elétron, para que possamos adicionar ou substituir os arquivos que fogem do padrão. Devemos ter cada versão em uma pasta ou arquivo e copiá-la para uma nova pasta temporária durante a execução.

E deveria haver a opção de ter os aplicativos instalados ou minificados, a instalação os deixaria como uma nova instância do electron, enquanto os minificados usariam md5 para deletar os arquivos que não foram alterados pelo desarquivamento do .asar (ou o que estaríamos usando) e arquive-o de volta e substitua o arquivo original, como um estado atualizado do aplicativo que usamos.

Apenas para lançar outra ideia: e se cada aplicativo Electron contivesse suas próprias cópias de tempos de execução, mas ao iniciar, eles pudessem verificar se existe uma instância já em execução do Electron (e sua versão) - se é compatível (dentro do intervalo semver , etc.), o aplicativo pode se comunicar com ele e usar essa mesma instância; se não for compatível, o aplicativo poderá iniciar sua própria instância do Electron. Isso parece resolver a questão de reduzir a pegada de memória.

(Então, novamente, no momento em que o aplicativo for iniciado, acho que já haverá várias instâncias do tempo de execução de qualquer maneira .. então pode não ser lógico ..)

@eliot-akira Tive uma ideia muito semelhante ao ler este tópico.

(Então, novamente, no momento em que o aplicativo for iniciado, acho que já haverá várias instâncias do tempo de execução de qualquer maneira .. então pode não ser lógico ..)

Bem, ele pode carregar apenas o suficiente para verificar isso, e depois de ver que não há um "mate eletrônico" disponível para compartilhar o tempo de execução, carregue o resto.

Isso criaria muitas preocupações de segurança. Um aplicativo maligno pode oferecer uma versão modificada do tempo de execução para outras pessoas e acessar seus dados. Pode ser que possa usar um segmento de memória compartilhada, torná-lo somente leitura e aplicativos de "usuário" (que usam o tempo de execução de um aplicativo lançado anteriormente) podem fazer a soma de verificação do tempo de execução, mas desenvolvê-los para todos os sistemas operacionais de destino pode ser um pesadelo ( Eu nem sei se isso existe no Windows; suponho que deve).

Se apenas por curiosidade, isso não faz sentido? Seria tanto ou pode ser muito mais trabalhoso do que um tempo de execução compartilhado separado? Isso cria outros problemas adicionais?

ADICIONADO DEPOIS: Isso pode ser um tiro longe, mas existem tecnologias para desduplicar páginas idênticas na RAM; eles são usados ​​principalmente em ambientes de virtualização e hipervisores. Esta é a primeira coisa que pensei e corri para verificar se os sistemas operacionais de hoje usam isso, e então pode haver uma maneira de definir o elétron de uma maneira que esse recurso possa ser aproveitado, mas aparentemente não.

@jorangreef Se um desenvolvedor modificou o binário Electron, eles não deveriam apenas criar uma solicitação pull?

@Jop-V Eles podem, mas também podem manter seu próprio fork. Eles podem até não publicar as fontes se não quiserem – a licença do MIT não impõe obrigações a eles.

@jkurei Para explorar mais a ideia, imagino algumas maneiras que podem funcionar:

1) Um wrapper nativo fino em torno do Electron ou do próprio aplicativo, que seria o "lançador". Ele verifica uma instância do Electron já em execução e sua versão: se compatível, entrega o restante do processo de inicialização para essa instância e sai; caso contrário, continue lançando sua própria instância do Electron.

2) Uma biblioteca JavaScript que os próprios aplicativos podem importar para o processo principal, como um iniciador. Ele poderia implementar um protocolo semelhante ao acima: transmitir a existência de uma instância do Electron e uma maneira de outros aplicativos (usando a mesma biblioteca) encontrarem e se comunicarem com ele - talvez via porta de rede ..?

@eliot-akira Acho que, a propósito, já existe algum tipo de "protocolo" primitivo do qual você está falando; é aquela coisa por trás do app.makeSingleInstance que de alguma forma detecta os processos do Electron em execução e se eles são o mesmo aplicativo ou não (provavelmente obtendo o caminho executável completo).

@iamale Eu vejo, o método usa a classe nativa ProcessSingleton do Chromium, para registrar o diretório atual do aplicativo (como um identificador exclusivo?). Sim, eu estava imaginando algo assim, para ser inicializado antes app.on('ready') . Portanto, em vez de apenas verificar a instância existente desse aplicativo específico, ele pode verificar qualquer instância do Electron - e "entregar o processo de inicialização", se compatível.

Por outro ângulo, encontrei um módulo chamado node-ipc que pode se comunicar entre processos separados do Node.js. Talvez isso possa ser usado para gerenciar o processo de inicialização puramente na camada JS.

Aqui está um exemplo básico de compartilhamento de uma única instância do Electron entre vários aplicativos, usando node-ipc para comunicação entre processos: https://github.com/eliot-akira/singletron-example.

O hub IPC é seu próprio módulo , um invólucro fino em torno node-ipc . Sua inicialização está no processo principal, main.js na parte inferior .

Quando iniciado, o aplicativo tentará primeiro se conectar a uma instância do Electron existente. Se não houver nenhum, ele iniciará um "servidor" que escuta solicitações entre processos. Quaisquer instâncias subsequentes do aplicativo se conectarão com a primeira instância, receberão sua "config" (versões do Chrome, Node, Electron) e poderão trocar mensagens, por exemplo, para solicitar uma nova janela para si.

É uma implementação ingênua para começar, mas o que eu gosto na abordagem é que cabe ao aplicativo lidar com como o servidor/clientes deve negociar: verificar a compatibilidade, abrir novas janelas, passar outras configurações, etc.

@eliot-akira Acho que especificar um ID de servidor padrão é uma ideia _realmente ruim_ neste momento: se alguém começar a usar isso para seus próprios propósitos, provavelmente modificará seu código de exemplo para suas próprias necessidades e quebrará o protocolo ( quebrando assim outros aplicativos contando com isso).

Além disso, parece bom e limpo, obrigado!

Re: preocupações de segurança: os aplicativos Electron já estão sendo executados com privilégios de usuário e, se os colocarmos em uma árvore de processos, eles realmente terão (ou poderão obter) acesso a outras instâncias do Electron. No entanto, acho que se vamos mitigar isso, todo mundo sendo capaz de fornecer uma instância do Electron corrigida certamente não ajudará.

@iamale Obrigado pelo feedback. Expus a opção de definir o ID do servidor, caso alguns aplicativos quisessem implementar seu próprio protocolo, em vez de um comum para todos os aplicativos Electron. Na verdade, ainda não existe esse protocolo comum - então, neste momento, não é prático para esse propósito, que aplicativos desconhecidos se conectem e entreguem o processo de inicialização. Era para ser uma prova de conceito, então atualizarei o documento para mencionar isso. Vou continuar explorando como torná-lo mais prático.

Acho que seria útil para as pessoas recém-chegadas terem algum tipo de resumo novamente, semelhante ao que alguém fez há meio ano.

Além disso, o que o usuário final faz?

Se eu fosse o usuário final (e em parte sou ofc), gostaria de um único pacote .exe/.app/.deb que funcionasse como o instalador do portableapps.net. Esse arquivo exe deve ser pequeno e baixar a versão upstream mais recente do software automaticamente junto com o Runtime, se não estiver instalado. Em um processo de configuração simples, devo ser capaz de definir um "local de tempo de execução" (usando a caixa de seleção de opções avançadas) manualmente junto com as caixas de seleção para criar links do sistema (Desktop, menu Iniciar, etc.).

Quando eu baixar o próximo software, o tempo de execução anterior (seja lá o que for, idc) deve ser reutilizado, se possível.

Como desenvolvedor, gostaria de poder criar um pacote para download com (na melhor das hipóteses) um clique. Este clique deve enviar meu código para algum repositório (semelhante ao play/web/app store) e criar um pacote .exe/.app/.deb para mim que eu possa compartilhar com o mundo.

Ainda não estou tão envolvido com o Electron, pois estou apenas criando um pequeno instalador de mod usando Electron e Electron-Edge para C#.

Posso ser ingênuo, mas afaik, a única razão "real" pela qual as coisas não são compatíveis com versões +-0.1 é que os arquivos .node precisam ser reconstruídos para cada versão do Electron. Esses arquivos .node não poderiam ser criados durante a instalação usando algum tipo de solução em nuvem?

Além disso, seria realmente um grande negócio criar um grande Electron LTS a cada meio ano? Duvido que os desenvolvedores estejam realmente usando todos os recursos de ponta de cada novo lançamento do Electron, então se nós (meio que) forçá-los a ficar com uma versão por mais tempo, isso realmente tornaria as coisas muito mais fáceis.

Imo, o único problema é não ter uma versão LTS do Electron pronta para todos confiarem.

Com essa versão, construir atualização automática, desduplicação, gerenciamento de versão e todas essas outras coisas devem ser muito fáceis.

A solução do instalador que propus também tem o benefício adicional de que o usuário não vê realmente a pasta do software, então não temos que empacotá-lo como .whatever e dizer a ele para movê-lo para algum lugar seguro. Além disso, vários "subexecutáveis" podem ser adicionados durante a instalação (por exemplo, para jogos multiplayer, vários "perfis" etc.). Esses executáveis ​​devem ser chamados apenas de somelaunchername.electron, mas no formato Json com informações sobre como iniciar o software (como qual index.html carregar e coisas assim). node_modules deve ser compartilhado entre executáveis ​​(a menos que o dev PRECISA usar versões diferentes de um módulo para cada executável). Isso pode ser feito com três pastas node_modules. Um para cada executável e um para ambos. No package.json haveria apenas informações gerais. Cada arquivo .electron deve (imo) poder sobrescrever os valores no package.json.

Esses arquivos .electron podem ser adicionados ao menu iniciar e outros locais usando "runtime --appname" ou um protocolo personalizado como o steam. Não tenho certeza qual é o melhor, mas o vapor me irritou algumas vezes no passado.

Agora, se o desenvolvedor realmente deseja enviar um runtime modificado, ele ainda pode empacotá-lo da maneira que está sendo feito atualmente.

Concluir:
Na minha opinião, o próximo passo é criar uma versão lts estável e envolver os desenvolvedores, fornecendo-lhes uma solução de empacotamento fácil. O processo de instalação pode ser melhorado posteriormente, atualmente basta baixar um runtime e um launcher para esses arquivos .electron.

O que é que vocês acham?

O construtor de elétrons @CiriousJoker pode criar um aplicativo portátil e um instalador da web. Pelo que vejo, no Windows compartilhado DLL é uma solução. A DLL compartilhada também oferece suporte à contagem de referência, para remover automaticamente o tempo de execução de elétrons não utilizado. Atualmente, o tempo de execução do elétron no Windows em um grande exe (exceto node.dll). Se puder ser dividido em dll, a solução no lado do construtor de elétrons é muito fácil de implementar. Também economizará memória, não apenas espaço em disco.

@zcbenz @paulcbetts Você considerou o uso de dll compartilhada? É possível reduzir o tamanho do exe e mover todo o código de elétrons para a dll (portanto, mantenha apenas o código mínimo no exe)? É legal que desde o elétron 1.7.5 o tempo de execução C compartilhado seja removido do node.dll e do exe. Agora, 30 MB de código já estão nos arquivos DLL (mas o exe ainda é grande — 80 MB), então posso começar a experimentar.

@develar imo, o verdadeiro problema não é como podemos compartilhar dlls, mas sim como podemos obter uma versão lts do electron

O Chromium faz correções de segurança para versões mais antigas? Tenho uma forte sensação de que a política deles é "atualizar para a versão mais recente para ser seguro". Sem atualizações de segurança do Chromium, um LTS de Electron parece muito distante.

@sedwards2009 Mas existem realmente tantas ameaças? Claro, posso ser ingênuo aqui, mas não estamos protegendo os usuários da internet aberta, mas de (principalmente) aplicativos locais. Executar qualquer arquivo .exe é 10.000 vezes mais perigoso e escrever vírus .exe também é 10.000 vezes mais fácil quando até mesmo o instalador do meu aplicativo legítimo foi chamado de vírus pelo AVG.

Então, para mim, "renovar" essa segurança a cada 6 meses é suficiente. Além disso, é muito mais inseguro permitir que cada desenvolvedor use sua própria versão empacotada do chromium, eles podem fazer muito mais mal com isso de qualquer maneira que não podemos impedir (com um tempo de execução compartilhado ou não)

Sim, a segurança termina onde o aplicativo obtém acesso bruto ao fs e à rede.
Você confia no fornecedor do aplicativo ou fica longe. <- isso é para aplicativos de código fechado.
Para os OSS, é melhor, a maioria deles pelo menos não tem más intenções, mas pode conter bugs.

Ok, então é fácil obter uma versão lts? Não poderíamos simplesmente escolher a versão atual e declará-la uma versão lts?

O problema maior provavelmente surgirá mais tarde, quando estivermos tentando convencer os desenvolvedores a criar seus aplicativos para esta versão específica, mas esse é o último passo de qualquer maneira. Para construir um runtime compartilhado, só precisamos escolher um runtime primeiro

Eu diria que isso deve ser uma decisão do desenvolvedor - descobrir em quais versões de tempo de execução o aplicativo deve estar trabalhando.
Tipo de campo de motores npm .
O trabalho do tempo de execução aqui é buscar a dll necessária ou qualquer outra coisa e permitir que o aplicativo seja executado.

Mas se permitirmos que eles escolham uma das dezenas de quase o mesmo tempo de execução que não são compatíveis, perderíamos completamente o ponto, não é? Estamos tentando evitar ter vários tempos de execução, não apenas desduplicando-os. Como alguém mencionou em algum lugar no início, a desduplicação de tempos de execução não faz muito sentido quando há uma chance de 1 em 20 de que o mesmo tempo de execução seja usado novamente no mesmo sistema.

Ou você quer dizer que temos a maior parte do tempo de execução compartilhado e apenas trocamos as diferentes partes conforme necessário? Isso faria sentido, mas imagino que seja difícil de implementar

Não vejo como o tempo de execução pode ser compartilhado, os principais consumidores de tamanho são Chromium e Node, que são totalmente integrados e duvido que possam funcionar com mais de 1 versão um do outro.

Acho que o node tinha algo assim:

• alguns desenvolvedores queriam a v8 mais recente e estavam OK em tolerar quebras
• as grandes empresas queriam estabilidade e suporte de longo prazo.

Não tenho certeza se a equipe eletrônica tem recursos suficientes para apoiar ambos, mas posso estar errado.
De qualquer forma, isso não entra em conflito com os intervalos de versão, basta indicar quais versões são "LTS"

Bem, se cada aplicativo de elétron usasse o mesmo tempo de execução e fosse fornecido apenas com o pacote .asar criado especificamente para esse tempo de execução, as coisas funcionariam, não é?

Sim, mas você quer o Chrome e o Node mais novos de vez em quando, certo?

Sim, mas eu poderia viver com o mesmo nó/cromo por 6 meses np. O Node tem uma versão LTS de qualquer maneira e o chrome não muda muito do que notei. Imo, o benefício de economizar 100 MB em cada instalação de aplicativo compensa os pequenos aumentos de velocidade de vez em quando, uma vez que uma nova versão do Chromium / Electron é lançada. Além disso, uma vez que temos os desenvolvedores a bordo, não deve ser muito difícil reduzir o tempo entre novas versões do tempo de execução. Poderíamos então suportar a versão mais recente do runtime e uma ou talvez duas mais antigas.

Reconstruir os arquivos .node a cada 6 meses também não deve ser muito difícil, eu acho

O Electron-builder suportará a nova opção para todos os alvos nsis — useSharedElectronRuntime. Por enquanto, todas as dlls existentes serão, acho que é possível reduzir o tamanho do exe e passar o código para a dll, mas pode ser feito depois, economizar 30Mb já é uma boa meta.

1. Crie um assembly assinado para todas as dll eletrônicas e publique nas versões do GitHub (bintray não é uma opção, porque não é confiável).
2. O instalador do Nsis baixará e instalará o assembly se ainda não estiver instalado. Segurança — a montagem é assinada. O Electron-builder também suporta instalação por máquina. E o Windows fornece um nível adicional de segurança se o assembly for instalado por máquina, portanto, se necessário, você pode habilitá-lo. A opção adicional será adicionada para instalar o conjunto por máquina em qualquer caso. Ainda não está claro - deve ser por padrão verdadeiro ou falso. Eu acho falso, para garantir que, por padrão, o aplicativo electron possa ser instalado sem admin.
3. não há necessidade de se preocupar com o tempo de execução de elétrons não utilizados - a dll compartilhada suporta contagem de referência. Na desinstalação do aplicativo, o assembly será removido e o Windows o removerá se nenhum outro aplicativo o usar.

@CiriousJoker Re: segurança. Eu não estava pensando em problemas de segurança se o próprio aplicativo fosse malicioso. Eu estava pensando em aplicativos eletrônicos que sugam e usam conteúdo não confiável. ou seja, sempre que um aplicativo de elétron mostra uma página da web aberta em um webview ou similar.

Muitos aplicativos não se expõem à web aberta e funcionariam bem em um elétron mais antigo. Mas o outro extremo é algo como o Brave, que como navegador web não faz nada além de se expor. :-)

@sedwards2009 sim, mas se começarmos a cuidar de todos e de sua mãe, não faremos nenhum progresso. Sempre haverá razões para não fazer algo. Não conseguir 100% dos desenvolvedores a bordo é apenas um sacrifício que temos que fazer. Se eles realmente precisam/querem a segurança, eles podem obtê-la manualmente.

Quanto à escolha de um LTS, a escolha mais sensata é nos vincularmos ao Nodejs LTS, ou seja, qual versão do elétron corresponde ao nó LTS é efetivamente o elétron LTS. Isso pode trazer alguma harmonia e acordo para que possamos avançar coletivamente e ter alguma segurança em vez de deixá-lo como uma escolha livre (o que nega essa comunidade) ou discussão (o que não nos leva a lugar algum).

@CxRes Mas qual versão do Electron suportamos? No meu projeto, o principal problema era reconstruir os arquivos .node contra a versão específica do Electron (não do Node).

Poderíamos apenas definir a versão mais recente do Electron como lts ou usar a mais usada.

Estou faltando alguma coisa aqui? Imo, o problema é o Electron, não o Node

Ok, deixe-me tentar explicar isso novamente com um exemplo:

• O nó LTS está atualmente em 6.11.1
• Portanto, queremos usar a versão mais alta do elétron que foi oficialmente construída com a versão mais alta do nó que satisfaça a condição <=6.11.1 >=6.0.0
• A versão mais alta do elétron construído usando o Node 6 é o elétron 1.4.15, que é construído com o Node 6.5.0
• Então, o elétron 1.4.15 é onde nós bifurcamos o elétron LTS e o reconstruímos com o 6.11.1 (e assim por diante até que haja novos lançamentos do Node v6)

Quando o Node LTS mudar para v8 (LTS são apenas números pares), migraremos juntos para um elétron ainda não lançado que será construído usando o Node v8 ou permanecerá no fork LTS atual até que uma versão eletrônica seja lançada.

E os desenvolvedores que querem o melhor e o mais recente?

@CxRes @CiriousJoker Vamos evitar assuntos estranhos aqui. Nenhum motivo técnico impede o uso de diferentes versões do Electron. A fragmentação será em qualquer caso (o desenvolvedor lançou o aplicativo há um ano e esqueceu, outro aplicativo de outro desenvolvedor lançado recentemente e usa outra versão).

@YurySolovyov Toda a ideia do LTS é que não é o mais recente e o melhor - é estável. E se não podemos concordar em focar em uma solução - estamos condenados a sofrer com a sub-optimidade de Pareto de não ter nenhum tempo de execução porque nenhum grupo tem tempo e capacidade para reconstruir todas as versões e rastreá-las em busca de bugs.

Veja também o comentário @CiriousJoker acima:

sim, mas se começarmos a cuidar de todos e de sua mãe, não faremos nenhum progresso.

@develar Tudo bem. Mas, como você aponta, isso não é um problema técnico, é político (chegar a um acordo sobre uma construção que funcione para a maioria das pessoas de forma consistente, de modo que o fardo seja compartilhado).

Então o que fazemos agora? Escolhemos uma versão lts e começamos ou tentamos encontrar uma solução para fazê-la funcionar para todos, tentando construir um tempo de execução único com dlls modulares (como @develar sugere se entendi corretamente)

@CiriousJoker Montagem lado a lado para uma versão eletrônica específica. por exemplo ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar Não consigo encontrar essa coisa do electronruntineassembly no Google, você poderia fornecer um link ou algo?

Imo, para acelerar as coisas, devemos apenas escolher uma versão aleatória do Electron como a versão lts e começar. Podemos alterar a versão de qualquer maneira a qualquer momento mais tarde.
@develar Ainda não sei o que você quer dizer com essa montagem lado a lado, mas tem que funcionar em plataforma cruzada e imagino que podemos implementá-la mais tarde também.

Nós (ou na verdade vocês) estamos falando sobre isso há anos, mas se ninguém começar, nada vai mudar e vamos ficar sentados aqui por mais 3 anos discutindo ideias e encontrando maneiras de não começar.

Espero que os desenvolvedores de elétrons possam resolver a separação do ambiente de execução e do aplicativo o mais rápido possível, o que promoverá bastante os aplicativos de elétrons, e eu verei um futuro brilhante.

Eles não resolveram isso pelo que parece anos para mim, então estou meio pessimista sobre isso. Claro, seria incrível, mas eles estão trabalhando ativamente nisso?

@CiriousJoker Como dito acima, estou trabalhando no suporte de tempo de execução de elétrons compartilhados para janelas no construtor de elétrons. Eu arquivei https://github.com/electron-userland/electron-builder/issues/1942 para acompanhar o progresso. Espero que esteja pronto para uso em 1 mês.

@develar Que pena, deve ter esquecido.. Nesse caso, boa sorte, seria incrível se você conseguisse!

Se alguém estiver interessado na desduplicação de fragmentação definida pelo conteúdo do subarquivo mencionada anteriormente no tópico em https://github.com/electron/electron/issues/673#issuecomment -157980607, eu abri o código-fonte: https:// github.com/ronomon/deduplication

Este longo tópico está inativo nos últimos meses, mas acho que o problema que ele aborda ainda vale a pena investigar. Durante o fim de semana eu fiz um utilitário pequeno e mínimo de uma página para renomear arquivos em massa. Embalado com o construtor de elétrons, o arquivo .app final do Mac tem 121mb ...

Eu estava pensando sobre esse problema ultimamente. Então dei uma olhada no meu smartphone: o aplicativo do Facebook tem 600 MB. O Chrome tem 325 MB, o Mesenger tem 300 MB... Então, um aplicativo de 120 MB na área de trabalho, eu realmente não me importo...

O tamanho não é um problema hoje. RAM e consumo de energia é.

_edit: se você discordar, sinta-se à vontade para compartilhar o motivo_

Para a plataforma Windows, os esforços do @develar com o electron-builder (electron-userland/electron-builder#1942) parecem próximos de alcançar o tempo de execução compartilhado.

Também notei que o webcatalog do aplicativo, que empacota aplicativos da web como aplicativos Electron autônomos, resolveu o problema de usar um tempo de execução compartilhado, para reduzir massivamente o tamanho do aplicativo: webcatalog/webcatalog/issues/171. Isso foi feito em seu empacotador, por meio de links simbólicos de recursos compartilhados entre aplicativos .

Progressive Web Applications (PWAs) são uma solução parcial para este problema. No Android, você pode adicionar o PWA à tela inicial e ele funcionará como um apk real. A equipe do Chrome agora está trabalhando para permitir que os PWAs sejam instalados na área de trabalho (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/), Microsoft também mostra interesse em oferecer suporte a PWAs (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) e espero que o Firefox e o Safari se atualizem em breve. APIs ausentes (por exemplo, acesso ao sistema de arquivos nativo) serão adicionadas se os desenvolvedores mostrarem interesse.
A maioria dos aplicativos Electron baseados na Web podem ser facilmente convertidos em PWAs, mas não tenho certeza sobre aqueles como Atom, VSCode - o código nativo provavelmente precisará ser reescrito no WebAssembly.

@develar tem algum progresso sobre essa ideia?

Vou usar quando lançar!

Tendo recentemente deparado com isso, eu só queria dar minha opinião. Eu não li a edição inteira, então posso repetir algumas coisas sem saber.

Acho que algo assim é muito importante, pois embora o tamanho de um programa Electron possa não parecer grande coisa agora, você realmente começa a vê-lo ao distribuir um programa muito simples e pequeno - digamos, uma calculadora personalizada. Nesse caso, algo como 5-10 MB seria razoável. 60 MB ou mais seria ridículo. Para um programa maior, o tamanho do próprio Electron se torna mais ignorável, mas ainda pode ser irritante.

Agora, esse modo de tempo de execução exigiria, no entanto, algum tipo de sistema de lançamento LTS, considerando a taxa atual de lançamentos. Os desenvolvedores podem ser incentivados a depender de uma versão LTS, e uma lista das versões mais comuns em uso pode até ser exibida no diretório de aplicativos, incentivando-os a usar o mais comum, a menos que falte um recurso necessário.

O próprio modo de tempo de execução deve, IMO, ter um sistema embutido para instalar outras versões da biblioteca Electron, de modo que, caso o usuário solicite a instalação de um aplicativo que exija uma versão diferente, o programa de tempo de execução possa baixá-lo automaticamente como um simples passo dentro do processo de instalação.

Acho que deve-se notar também que o uso de RAM dos aplicativos Electron também pode ser melhorado com a ajuda disso, embora as alterações necessárias para colocá-lo em vigor sejam muito mais importantes. Com um tempo de execução compartilhado, os aplicativos Electron usando a mesma versão podem compartilhar alguns recursos na memória.

De qualquer forma, sou muito novo em toda a fonte do projeto Electron, então desculpe se algo não ficou claro, ou se eu repeti algo desnecessariamente. Eu realmente espero que isso seja implementado, no entanto, pois realmente tornaria o Electron uma plataforma muito mais promissora para ainda mais tipos de programas. :+1:

@octacian Estou começando a pensar que os PWAs são uma opção melhor. Não é universal, no entanto – você não pode fazer _tudo_ usando PWA – mas certamente para coisas como calculadoras personalizadas elas devem ser mais que suficientes.

Agora só temos que esperar o suporte a PWA no desktop surgir.

Eu também acho que com tal sistema, 1- será mais fácil enviar para sistemas embarcados/menores, e 2- no futuro, uma base de sistema operacional semelhante ao elétron poderá ser criada para dispositivos móveis.

@yasinaydin Já existe o LG WebOS. (Costumava haver o Firefox OS também, mas foi descontinuado)

@KeitIG ​​Meu senhor, seu argumento seria absolutamente decente se o único problema com o Electron fosse seu tamanho. Ter um programa um pouco maior, mas simplificar a complexidade e a possibilidade de falha para os desenvolvedores (não podemos negar que o Electron é ótimo em fornecer aos desenvolvedores uma maneira padronizada de criar aplicativos sem muito espaço para estragar) seria incrível. Infelizmente, usar uma versão separada das bibliotecas para cada aplicativo também significa maior uso de RAM e problemas de segurança distribuídos (e mais difíceis de corrigir). Eu expliquei isso melhor no meu problema duplicado , mas em poucas palavras eu realmente acho que uma biblioteca de tempo de execução compartilhada que você pode atualizar por conta própria e compartilhar entre diferentes aplicativos Electron (que também seriam enviados em uma versão "lite", como quando alguns desenvolvedores costumavam distribuir arquivos Java para usar em sua JVM e agrupar .exe s) seria realmente o disjuntor do negócio para o Electron e, embora eu entenda que provavelmente seria uma grande quantidade de trabalho, isso me entristece que ainda não está nos planos dos desenvolvedores. Vamos torcer para que eles façam isso no futuro.

@dre-hh Embora reconheça a boa intenção de sua proposta, ela é, entre outras coisas, excessivamente restritiva. Por exemplo, desenvolvi um aplicativo eletrônico comercial para meu empregador e é usado em ambientes altamente regulamentados (sem conectividade com a Internet, requisitos de rastreabilidade/auditoria etc.). Nossos clientes não podem permitir que façamos coisas como atualizar automaticamente o software. É um mundo muito diferente dos aplicativos da web típicos para as massas. Navegadores perenes e instalação automática de atualizações de segurança do sistema operacional são, na minha opinião, uma ótima ideia para a maioria das pessoas na maioria dos casos, mas meu ponto é que eles não se encaixam em todos os lugares. Às vezes, o risco de interrupção causada pela alteração do software é muito maior do que o risco associado à execução de uma versão desatualizada do software, especialmente em ambientes controlados onde outras técnicas de mitigação de segurança estão em vigor. Portanto, tomar uma medida extrema, como bloquear a execução de aplicativos usando versões desatualizadas do elétron (ou, na verdade, qualquer biblioteca) não é uma solução ideal, se é que é uma solução. (Além disso, os administradores já têm muitos controles para restringir quais programas podem ser executados, para que possam implementar isso sem novos recursos do sistema operacional.)

Além disso, como acontece com a maioria das preocupações de segurança, grande parte do problema decorre de desenvolvedores que desconhecem os riscos ou optaram, por qualquer motivo (por exemplo, falta de tempo), não seguir as diretrizes de segurança para as ferramentas que estão usando. (por exemplo , segurança, recursos nativos e sua responsabilidade ) Todos nós, como desenvolvedores, precisamos fazer nossa parte para assumir a responsabilidade pela qualidade (que inclui segurança) de nosso trabalho.

Por fim, acho que é um erro procurar uma entidade comercial de software, como a Microsoft, para tratar dessas preocupações. Isso ocorre em parte porque, como acabamos de observar, não podemos esperar produzir aplicativos seguros por meio de desenvolvedores que não estejam preocupados com a segurança. Mais importante, pelo menos na minha opinião, é que uma das coisas bonitas do Electron é sua natureza de código aberto e multiplataforma, que geralmente não são altas prioridades para fornecedores de software comercial. Um progresso bem pensado e bem-sucedido provavelmente exigirá algum nível de consenso e esforço de toda a comunidade de desenvolvedores. Naturalmente, as contribuições de entidades comerciais são apreciadas.

@jacobq Caso você não saiba, a Microsoft é a dona da Electron.

Caso você não saiba, a Microsoft é a dona da Electron.

@Jop-V Por favor, adicione uma citação para isso; Eu não acho isso correto. A primeira página do electronjs.com diz:

Electron é um projeto de código aberto mantido pelo GitHub e uma comunidade ativa de contribuidores.

A Microsoft é consumidora do Electron (usando-o em produtos como o Visual Studio Code) e (presumo) também contribuidora, mas não possui propriedade. O arquivo de licença não menciona a Microsoft nem o artigo da Wikipedia sugere que eles tenham uma posição de propriedade.

@jacobq A Microsoft vai adquirir o GitHub, portanto, se o Electron for atualmente mantido pelo GitHub, em breve será mantido pela Microsoft até onde eu sei.

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

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

A aquisição do Github pela Microsoft não significa nada para a Electron. O Github ainda é/será uma empresa separada, com seus próprios produtos e projetos. Não vejo a Microsoft assumindo a propriedade da Electron, tanto quanto não vejo a Microsoft assumindo a propriedade da Atom.

Eu acho que este debate não está realmente ajudando o ponto inicial da questão.

https://github.com/GoogleChromeLabs/carlo

Carlo parece bastante intrigante. Eu o levei para dar uma volta e é muito intuitivo. Alguém já experimentou com pkg ing-lo ainda?

Por que todas as propostas para reduzir o inchaço do disco rígido e da memória dos usuários finais nunca são trabalhadas? Esta é uma ideia fantástica que tem 4 anos e ainda é apenas uma ideia. Não consigo entender por que esse tipo de coisa não está no topo das prioridades do projeto

@danielo515 porque em vez de criar mais um projeto industrioso, existe https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

O que você está falando? Este já é um projeto enorme. Também é o mais difundido e usado, então apontar para um projeto diferente para um recurso que deveria fazer parte deste não me parece correto.
Além disso, Carlo é uma abordagem diferente, eles usam o Chrome instalado, então não é como uma versão daemon do Electron .

Não consigo entender por que esse tipo de coisa não está no topo das prioridades do projeto

Porque torná-lo uma realidade é difícil (como "muito" difícil).

Se você não estiver feliz (o que é totalmente compreensível), sinta-se à vontade para fazer um fork do Electron e enviar um PR.

Não me interpretem mal, se houvesse uma solução fácil para este problema, tenho certeza que já teria sido implementada.

@danielo515

... apontar pessoas para um projeto diferente para um recurso que deveria fazer parte deste não me parece correto.

Acho que o ponto é que cada projeto tem seus pontos fortes e fracos, e Carlo é adequado para casos com restrições de espaço. Para meus casos de uso, um tamanho de aplicativo de 100 MB é perfeitamente adequado, então, embora eu adoraria ver esse recurso chegar, os outros recursos de elétrons são muito mais importantes para mim.

@jacobq Sim, você está certo - casos de uso diferentes exigem ferramentas diferentes.

Se mais alguém estiver interessado, criei uma lista de ferramentas semelhantes para desenvolver aplicativos js na área de trabalho.

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

Eu simplesmente não uso o Electron porque não posso atualizar dezenas de aplicativos de 100 MB - e você sabe como os aplicativos precisam ser atualizados (tenho outras opiniões sobre isso, mas compartilhá-los não ajudará).
O que eu realmente gosto na abordagem de carlo é a ideia de usar o navegador instalado.
Melhor ainda, certamente carlo poderia usar qualquer navegador disponível, não apenas o chromium, já que o marionetista também pode gerenciar outros navegadores. No OSX, você geraria o Safari, no linux epiphany (webkitgtk) ou no firefox, etc ...
Então, realmente, para obter um aplicativo, você só precisa instalar o nodejs e seu aplicativo.
Agora a questão será: quão bom o pkg pode ser em usar libs instaladas no sistema e addons nativos?
Por exemplo, se eu tivesse que empacotar o aplicativo que estou desenvolvendo atualmente, precisaria de postgresql, sharp (e vips), webkitgtk e exiftool. Eu gostaria de poder distribuir o aplicativo apenas para usuários linux debian, fedora ou ubuntu. Eu gostaria de me livrar dos "pacotes malucos" e, em vez disso, capitalizar o trabalho duro feito por essas distribuições, de graça.

@kapouer ... use o navegador instalado ...

Embora em teoria seja uma boa ideia, isso resulta em maior dificuldade em codificar aplicativos no lado da Web, pois agora você teria que se concentrar no suporte a vários navegadores e os navegadores aos quais eles recorrem podem ser limitados no que você deseja fazer, pois eles não tem suporte total para coisas como você pode encontrar no Chromium. Você também confia no usuário para garantir que seu navegador esteja atualizado e que os vários fornecedores de navegadores não interrompam seu aplicativo com uma atualização.

Muitos usuários conseguiram fazer atualizações massivas de 50 Mb mudando para atualizações delta ou fazendo com que os gerenciadores de pacotes apenas atualizassem o arquivo .asar ou as pastas de recursos. E só faça uma grande atualização do Electron quando necessário. Isso é o que fazemos em nossa empresa e tem dado muito certo.

Do ponto de vista de um usuário ingênuo, usar o Electron app-shell como tempo de execução compartilhado tornaria muito fácil distribuir e usar. Por ex. Com 5 apps de elétrons em um único sistema, você tem 5 instâncias de app-shell e são cerca de 300MB, certo?

Eu acredito fortemente que o elétron é o futuro do UX de desktop e isso seria um grande passo (veja o .NET Runtime -- pode ser uma comparação ruim, mas é legal né?) para trazer a tecnologia da web mais poderosa.

O Electron já possui um runtime para uso em desenvolvimento, não é? O "elétron". comando, quero dizer. Por que não reutilizar isso para o lado do usuário?

Para lidar com vários aplicativos dependendo da versão diferente do Electron, você pode usar a abordagem que o .NET Core usa. Basta ter várias versões do runtime instaladas lado a lado e fazer com que os aplicativos declarem a versão mínima (ou máxima) necessária.

Eu fiz um lançador de prova de conceito: https://github.com/ProPuke/electron-shared

Executável único, com menos de 1 MB de tamanho. Passe para ele um diretório de aplicativo ou pacote asar e ele verificará os requisitos da versão eletrônica em seu package.json devDependencies e fará o download/execução com a versão correta.

Os tempos de execução do Electron são armazenados em AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac) para que possam ser compartilhados entre aplicativos.

Sem um caminho especificado, ele executará automaticamente o diretório app ou app.asar se houver; Assim, você pode distribuir seu aplicativo apenas com este arquivo e app.asar . Ou isso pode ser associado a arquivos .asar e apenas os asars podem ser distribuídos.

Ele também possui alguns parâmetros de linha de comando, incluindo --downloadOnly e --silent para que possa ser chamado de dentro dos instaladores durante o processo de configuração.

Ele não lida com atualização automática (só baixa se uma versão compatível do Electron ainda não estiver disponível em sua máquina), mas isso pode ser feito periodicamente na inicialização ou por um serviço em segundo plano (desde que os tempos de execução sejam colocados em no lugar certo, ele encontrará e usará o mais recente quando os aplicativos forem iniciados).

Saber quando excluir cópias antigas dos tempos de execução pode ser complicado. Eles podem se acumular com o tempo. Precisaríamos acompanhar quais aplicativos instalados usaram quais versões (e, portanto, quais não eram mais necessários) ou talvez apenas armazenar uma data de uso pela última vez para cada versão de tempo de execução e excluí-los automaticamente se não tiverem sido usados daqui a pouco.

Enfim, uma prova de conceito/proposta. Algo assim resolve problemas? Eu perdi alguma coisa gritante e óbvia?

Experimentei o compartilhamento de elétrons do @ProPuke e consegui executar a demonstração de início rápido do elétron . Mas não consegui executar nenhum dos aplicativos descritos no site do electronjs (porque a maioria dos aplicativos usa algum script de shell para iniciar o aplicativo e não apenas package.json, pelo que entendi). Mas acredito que esta _prova de conceito/proposta_ pode ser um indicador para a próxima grande atualização.

Eu tenho uma ideia. electron Porque atualmente suporta o comando "electron.exe path". Acho que você pode abri-lo chamando vários asars na linha de comando. No momento, sou apenas uma ideia. Espero que alguém possa fazer isso, porque acabei de tocar neste software.
_____________ versão da tradução chinesa__________
Eu tenho uma ideia. Porque atualmente o elétron suporta o comando "caminho do electron.exe". Eu acho que pode ser aberto usando a linha de comando para chamar vários asars. Eu sou apenas uma idéia no momento, espero que alguém possa dar uma olhada, porque acabei de me envolver neste software.

Depois de uma olhada superficial em toda a conversa (e outras discussões como Vários "aplicativos"), vou resumir - chamar vários asars nativamente em vez de começar com vários binários tem um longo histórico, mas não é suportado. Mas o default_app do electron é implementado usando a linha de comando (talvez, eu não saiba por enquanto). Eu acho que chamar cmd por meio de elétron (parece ser possível) deve ser capaz de alcançar essa compatibilidade de função.
Dando uma olhada superficial em todas as conversas (e outras discussões, como vários "aplicativos"), concluo que as chamadas nativas para vários Asar em vez de vários binários começam, o que tem um longo histórico, mas não é suportado. Mas o default_app do Electron é uma implementação que tira proveito da linha de comando (e, talvez, eu não saiba por um tempo) Eu quero chamar cmd por meio de elétron (como se eu pudesse) deve conseguir essa barra de compatibilidade de recurso.

Na pior das hipóteses, você teria que criar um arquivo .bat ou equivalente para sistemas operacionais não Windows e executá-lo a partir do Electron.

Links possivelmente úteis:

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

Parece que somente quando não há app.asar ou pasta app é o comando elétron. exe caminho válido

Ah, então você precisa ter um elétron para executar o caminho exe dentro do elétron usado para configurar tudo isso. Ainda melhor do que uma instalação eletrônica para cada aplicativo usado. Você só precisaria de uma instalação de elétron para cada versão de elétron que seu aplicativo precisa. Você provavelmente precisaria fazer uma extensão separada, que é um arquivo zip renomeado que contém o aplicativo que estamos tentando executar e um arquivo com a versão recomendada (executá-lo imediatamente), versões compatíveis (perguntar se deseja executar ou instalar a versão recomendada e também baixar a versão Electron recomendada em segundo plano), ou apenas mostraria uma barra de progresso do download, para que a versão recomendada fosse baixada.

Ou eu entendi errado alguma coisa.

Essa ideia provavelmente é a mesma: como bat é fácil de dizer atualmente, tome-o por exemplo, o conteúdo é electron.exe app1.asar, após a execução, o electron abre o conteúdo de app1.asar. Provavelmente é assim que funciona, mas quando você escreve a próxima frase, electron.exe app2.asar, em bat, você só pode fazê-lo quando o elétron de app1.asar terminar. E quando o morcego é desligado, o elétron é desligado. Mas eu escrevo electron.exe app3.asar|electron.exe-v ou electron.exe app3.asar|start, e assim por diante. Quando fecho o morcego, o elétron pode sobreviver, mas não posso continuar a abrir outros asars. Eu acho que este programa autônomo pode ser melhor do que este, porque o bat ainda é um pouco limitado.

Não se você usar pastas temporárias.

Você tem as versões (arquivadas ou desarquivadas) em uma pasta electron_versions, da qual você usa a versão recomendada ou a versão compatível mais recente que você baixou copiando a versão que está usando para uma pasta temporária e, depois de concluí-la, você exclua a pasta.

O caminho dos arquivos salvos localmente estaria na pasta eletrônica ou próximo ao arquivo que você está usando. Se você estiver usando-o de um arquivo contendo as coisas que mencionei nas últimas 24 horas, você teria que mover os arquivos de dados salvos de volta para o arquivo ou não movê-lo antes de excluir essa pasta de instância eletrônica temporária.

SSD？

???

O motivo para excluir a pasta eletrônica temporária é porque o aplicativo teoricamente poderia alterar os arquivos da instalação eletrônica em que estão sendo executados e por design. Quer dizer, o arquivo pode conter os arquivos e pastas que precisam ser escritos ou sobrescritos dentro da instalação eletrônica temporária.

Portanto, após a instalação ser usada, ela pode ser tratada como corrompida pelo aplicativo executado, portanto, não pode ser reciclada e, portanto, deve ser excluída. No entanto, a versão da qual a instalação corrompida usada como base ainda está intacta, na pasta electron_versions do aplicativo runtime-electron que estamos tentando fazer.

Na verdade, se o arquivo com extensão distinta, que mencionei antes, for somente leitura, os dados usados ​​poderiam ser movidos para %appdata%, teoricamente. Portanto, um aplicativo executado dentro do elétron do modo de execução que estamos tentando fazer seria realmente portátil (autocontido) e, portanto, copiar esse arquivo seria suficiente para levar a configuração desse aplicativo com você.

Mas provavelmente também precisaríamos adicionar uma função de atualização para esse tipo de arquivo, que seria outra instalação eletrônica que copiaria e substituiria os arquivos do novo arquivo de instalação por uma cópia do arquivo de instalação antigo e retornaria o novo arquivo de instalação com o dados que tinha. A coisa toda pode ser feita automaticamente, se houver um link de download nos arquivos usados ​​pelo runtime-mode-electron que estamos tentando fazer.

Quando estiver pronto, se você quiser ir além, você pode até adicionar um cliente git para atualizar os aplicativos, embora isso possa exigir o uso de github e bitbucket para hospedar arquivos compilados.

você pode usar o arquivo de download "curl, wget, aria2c" e o usuário não precisa instalar o git, oh, você precisa usar "gzip,7z" descompactar zip。

Estou fazendo uma ferramenta electron-runtime que funciona de forma semelhante a electron-builder . Ele agrupa apenas o arquivo app.asar com um script simples sh (mais tarde, esta será uma interface do usuário para mostrar o progresso do download do Electron). Atualmente, ele funciona apenas para macOS.

Ao executar um aplicativo empacotado com electron-runtime Ele basicamente baixa uma versão principal correspondente do Electron, mas a mais nova no caso de menor e patch, já que as alterações de última hora do Electron ocorrem apenas em incrementos de versão principal.

O aplicativo electron-quick-start tem apenas 62 KB, captura de tela:

Se você estiver interessado, deixe uma estrela, PR ou um problema.

Eu atualizei o pacote um pouco, que ele pode construir usando electron-builder ( Aqui está descrito como ele funciona ). Então agora você pode criar até mesmo o Visual Studio Code com ele! (mas ainda apenas no macOS).

Eu lancei com sucesso uma primeira versão de electron-global ! (Eu mudei, já que electron-runtime foi levado). Você pode construir seu aplicativo usando meu pacote npm com electron-builder . Também adicionei uma interface do usuário com uma barra de progresso para mostrar o progresso de um download do Electron. Espero que fique mais popular para tornar o Electron melhor.

Desculpe, eu uso o sistema Windows e não tenho dinheiro para usar o MacOS. Mas acredito que seu projeto terá muito sucesso.

@nwdxlgzs Suporta Windows, macOS e Linux...

Eu pensei que este projeto só suportava MAC.
Eu vou ter tempo para experimentar este grande projeto.

Obrigado por fazer isso e por nos manter atualizados!
Também estou usando o Windows.
Vou dar uma olhada no código quando eu receber a mudança.

Bem, que tal integrar electron-global upstream e torná-lo o novo padrão 😏