+100, 앱의 크기를 줄이는 데 매우 유용합니다.

.asar 확장자를 변경할 수 있습니까? 헝가리어로는 정말 이상하게 들립니다. 기본적으로 나쁜 의미 the shit 를 의미합니다( link ).

.apak? 정말 많은 언어가 있으므로 거의 모든 확장 프로그램이 일부에서는 이상하게 들릴 수 있습니다.

IMO 런타임 설치 및 업데이트는 가능한 한 쉬워야 합니다. 많은 런타임에는 매우 성가신 알림이 있습니다. 또한 이 작업을 수행하려는 경우 최신 앱 버전이 이전 런타임에서 작동하지 않을 수 있으므로 일부 추가 매니페스트 메타데이터를 제공해야 합니다. 따라서 현재 런타임 버전을 앱 매니페스트의 버전과 비교해야 합니다(노드에서와 같이 버전 범위도 가능 package ) 그런 다음 런타임을 업데이트해야 하는 경우 이 프로세스를 최대한 쉽게 만드십시오. 대부분의 사람들에게 쉬운 것이 무엇인지 모르지만 저에게는 진행률 표시줄이나 상태 메시지가 있는 창입니다("다운로드 중... 57%", "업데이트 중...").
확실하지 않지만 백그라운드 업데이트도 고려할 수 있습니다. 일부 업데이트 서비스일 수도 있고 앱이 실행되는 동안 런타임 다운로드일 수도 있고 앱이 닫힐 때 업데이트될 수도 있습니다.

이것에 대해 +1. 저는 Mac 및 Windows용으로 제공해야 하는 응용 프로그램을 작업 중이며, 이는 제공을 상당히 단순화할 것입니다.

이것은 굉장할 것입니다!

몇 가지 생각:

• @YuriSolovyov 가 말했듯이 특정 asar가 호환되는 원자 런타임 버전을 선언하는 방법이 필요합니다. asar 기반 앱을 출시할 때 QA의 부담을 줄이기 때문에 정확한 버전을 지정할 수도 있어야 합니다.
  
  
  
  • 이를 지원하려면 사용자에게 잠재적으로 보이지 않는 여러 버전의 atom-runtime을 나란히 설치하는 것을 허용해야 합니다.
  
  
  • 이것은 다운로드 크기를 제한하는 이상과 다소 상반됩니다. 그러나 여러 asar 기반 제품을 생산하는 회사는 내부적으로 표준화하여 모든 앱이 여전히 동일한 버전을 사용하도록 할 수 있습니다.
  
  
• Mac에서 자동 업데이트 원자 런타임에 대한 지원에 대해 언급하지 않았지만 _매우_ 유용할 것입니다.
• Linux에서 소스만 설치하는 것보다 .deb/.rpm 패키지와 설치에 sudo 권한이 필요하지 않은 방법(예: 사용자별)을 통해 바이너리 설치/업데이트를 지원하는 것이 좋습니다. 사용자별로 설치된 런타임의 경우 자동 업데이트도 매우 유용합니다.
• 설치된 asar 파일을 최신 상태로 유지하기 위한 지원이 있습니까? 아니면 각 앱에서 독립적으로 구현해야 하는 것입니까?

마지막으로 이 노력의 일정은 어떻게 됩니까? 이 부분의 구현을 시작하려는 경우 시작하는 가장 좋은 방법은 무엇입니까? 저는 기꺼이 기여합니다.

@joshuawarner32 현재 이것은 대략적인 생각입니다. 저는 atom-shell의 몇 가지 주요 문제를 해결한 후 작업할 계획이지만 몇 달 후에 될 수 있습니다.

기존 런타임과 작동/업데이트 방식, 얼마나 방해가 되는지, 다른 장단점을 살펴보는 것도 가치가 있다고 생각합니다.

현재 이것은 대략적인 아이디어일 뿐이며, atom-shell의 몇 가지 주요 문제를 해결한 후 작업할 계획이지만 몇 달 후에 가능할 수도 있습니다.

5~6개월 정도 되었습니다. 이것을 구현하면 좋을 것입니다.

우리는 우리의 특정 사용 사례에 매우 잘 맞는 내부 구현을 구축했으며 이를 업스트림할 수 있습니다. 위험은 실제로 우리의 사용 사례에 너무 구체적이고 다른 누구도 추가 복잡성에 관심을 갖지 않는다는 것입니다.

다음은 우리 디자인의 하이라이트입니다.

• 서버의 여러 다른 앱에 대한 .asar.gz 파일 배포
• 특정 앱에 대한 코드를 번들로 묶지 않는 단일 빌드의 atom-shell을 사용자에게 배포합니다.
• 앱 시작 시 적절한 .asar.gz 파일을 다운로드합니다(없거나 서버에 최신 파일이 있는 경우). 압축을 풀고 포함된 앱을 실행합니다.
• 우리의 atom-shell 빌드는 다운로드/실행할 앱을 지정하기 위해 --app 인수를 허용합니다.

원자 껍질 사람들이 염두에 두었던 것이 그런 종류입니까? 그런 것이 다른 사람들에게 유용할까요?

JRE와 마찬가지로 .eapp 파일(전자 앱)이 있는 ERE(전자 런타임 환경)일 수 있습니다.

.eapp의 경우 -1

+1 필요해요!

Windows에서 우리는 atom-runtime을 위한 설치 프로그램과 자동 업데이트 프로그램을 제공할 수 있으며, 열릴 .asar 파일 유형을 등록할 수 있습니다.

Windows에 Steam을 설치하고 게임 바로 가기를 만드는 방법을 확인하십시오. 실제로 프로토콜 처리기를 사용합니다. 비교적 영리합니다.

:+1: Steam 모델에서.

이를 구현하는 데 기술적 장애물은 없으며 모든 것이 Electron 앱 자체일 수 있습니다. 그러나 문제는 모든 세부 사항을 고려하여 구현하기가 쉽지 않다는 것입니다. 소규모 팀이 풀 타임으로 작업해야한다고 생각합니다. 실현 될 것인지 확실하지 않습니다.

그러나 문제는 모든 세부 사항을 고려하여 구현하기가 쉽지 않다는 것입니다. 소규모 팀이 풀 타임으로 작업해야한다고 생각합니다. 실현 될 것인지 확실하지 않습니다.

확실히 극복할 수 없는 것은 아니지만 이 계획을 어렵게 만드는 많은 질문이 내 마음에 있습니다. 예를 들어 "App 1"에는 0.30.x가 필요하고 0.31.x에서 실행할 수 없으며 "App 2"에는 그 반대가 필요합니다. 이 시나리오의 승자는?

개발자 복잡성을 희생시키면서 디스크 공간과 대역폭과 같은 가장 큰 문제가 아닌 것을 최적화하는 데 많은 노력과 인프라/어려움이 있는 것 같습니다(즉, 이제 개발자는 처음 설치/ Electron을 확인한 다음 앱을 설치하십시오)

아이디어를 미워하려는 것이 아닙니다! 저는 이 작업을 수행하는 데 시간을 할애하여 대신 큰 문제에 사용할 수 있다고 생각합니다. 새로운 개발자가 코드의 첫 줄부터 사용자에게 배송

@paulcbetts 하지만 이점은 그만한 가치가 있지 않습니까? 앱을 업데이트할 때 사용자는 ~70mb 대신 1mb 미만을 다운로드해야 합니다. 즉, 자동 업데이트 프레임워크와 모든 것이 필요하지 않으며 몇 개의 파일이 포함된 micro-zip 아카이브를 다운로드하고 추출하기만 하면 됩니다.

나는 속도가 128kbps 미만인 외딴 지역에서 지난 3개월을 보냈고 나를 믿으십시오. 업그레이드 크기는 엉덩이에 큰 고통입니다. 최악의 부분은 여전히 ​​비슷한 상황에 있는 사람들이 많다는 것입니다.

즉, 자동 업데이트 프레임워크와 모든 것이 필요하지 않으며 몇 개의 파일이 포함된 micro-zip 아카이브를 다운로드하고 추출하기만 하면 됩니다.

나는 그것이 사실이라고 생각하지 않습니다. 왜냐하면 거의 확실하게 어느 시점에서 당신은 최신 버전의 Electron으로 업데이트한 다음 kerplowie로 옮기고 싶을 것이기 때문입니다. 당신은 비슷한 상태에 있습니다. )

패키지 안에 엄청난 양의 비디오가 없는 한 기본 앱은 이제 30~50메가입니다. 나는 그것이 대부분의 사람들이 다운로드하기에는 무리가 있다고 생각하지 않습니다. 평균 유튜브 동영상은 30~40MB 사이라고 생각합니다.

여기에 메모를 하고 싶습니다. 중국의 연결 속도는 평균 약 20kB/s입니다(내 도시의 ~92%보다 느린 연결이 있다는 점은 인정합니다.) wget -c '잉. taobao 거울을 사용하지 않는 한.

버전 호환성을 위해 전자 개발은 포괄적인 버전을 가지기에는 너무 빨리 진행됩니다. 앱이 시작될 때 요청된 주요 버전을 사용/다운로드하는 데 일종의 래퍼/도우미를 사용할 수 있습니까?

20kb/s? 어떻게 살아남을 수 있습니까? 그것이 얼마나 어려운 일인지 상상할 수 없습니다!

@steelbrain 내 의도가 아닙니다

@RIAEvangelist 빠른 시간과 많은 인내심을 가지고 시작합니다. 속도는 밤늦게까지 정말 빨라지므로 잠자는 동안 다운로드를 실행하거나 예약된 상태로 두십시오. :삼

어쨌든, (기본) 제3자 래퍼를 작성하는 것은 너무 많은 일이 아닐 것이라고 생각합니다. 시도하고 싶은 사람이 있습니까?

그러나 .asar 파일은 전자 버전을 쉽게 선언할 수 없습니다. 아마도 다른 프로그램 설명자 시스템이 필요할까요?

(필요한 경우 다운로드하고) 런처가 앱에 필요한 런타임 버전을 필요로 하는 일종의 런타임 버전 디스패처는 어떻습니까? 이를 위해 package.json에 항목을 추가할 수 있습니다.

@YuriSolovyov 런타임이 기본적으로 .json 파일을 처리한다고 말할 수 없다는 점을 제외하고. asar 파일을 먼저 읽고 package.json을 볼 수 있다고 가정하지만 약간 느려질 것입니다.

@Tribex 예, 논리 흐름은 다음과 같습니다.

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

이상적으로는 런타임 모드가 Steam 또는 Chrome 앱 런처 처럼 작동해야 합니다. 주요 문제는 런타임이 새 버전으로 업그레이드될 때 앱을 처리하는 방법입니다.

Electron 앱은 Electron, 특히 노드 네이티브 모듈의 업그레이드로 어려움을 겪습니다. C++ ABI 문제로 인해 Electron을 업그레이드할 때마다 네이티브 모듈을 다시 빌드해야 합니다.

Steam의 모든 게임은 독립 실행형 프로그램이기 때문에 Steam은 고통을 겪지 않습니다. 실제로 Steam 클라이언트 없이 게임을 시작할 수 있습니다. Chrome 앱 실행도 되지 않습니다. Chrome 앱은 일종의 해석 언어인 HTML/JS/CSS로 작성되었기 때문에 Chrome의 다른 버전에서 실행되는 간격이 없습니다.

@hokein 제거된 전자 버전에 의존하는 앱을 만날 때마다 여러 언어를 다운로드하는 모국어로 가벼운 "클라이언트"가 있는 것은 어떻습니까? 그것은 사본을 다운로드한 다음 특정 전자로 각 앱을 실행합니다.

일주일에 한 번 정도 새로운 Electron 릴리스가 있으므로 2개의 앱에 동일한 버전의 Electron이 있을 가능성은 희박합니다.

런타임 접근 방식을 지원하려면 릴리스를 LTS(장기 지원) 버전과 최신 버전으로 분리해야 할 것입니다. LTS는 프로덕션용이고 최첨단은 개발 및 테스트용입니다. LTS는 버그 수정 및 주요 io.js 및 콘텐츠 셸 버전을 대체하지 않는 일부 변경 사항만 얻을 수 있으므로 기본 모듈은 계속 작동해야 합니다.

@etiktin 이 말한 것을 감안할 때 사용자 시스템에 많은 전자 앱이 있지 않는 한 항상 대부분의 런타임을 다운로드해야 하므로 다운로드 시간에 이점이 없을 것입니다.

2주 동안 나는 전자를 보고 있었고 지금은 4개의 릴리스를 본 것 같습니다.

@etiktin 이상적으로는 electron이 semver를 따르는 경우 앱은 버전 ^0.31을 선언할 수 있고 최신 0.31.x 릴리스를 사용합니다. 조금 도움이 될 수 있습니다.

다음을 수행하는 semver 자동 업데이트 메커니즘을 사용하여 프로덕션 중인 앱이 있습니다.

1. 앱의 현재 버전(0.3.0, 0.3.1 등)과 플랫폼(darwin-x64, win32-ia32, win32-x64 등)을 제공하는 서버에서 간단한 HTTP 끝점을 가져옵니다.
2. 서버는 "304 Not Modified"를 반환하거나 최신 버전이 있는 경우 JSON 매니페스트를 반환합니다.
3. JSON 매니페스트는 기본적으로 최신 버전의 폴더, 파일 및 심볼릭 링크의 중첩 목록입니다.
4. JSON 매니페스트의 폴더 항목은 [이름, 자식 항목 배열]과 같습니다.
5. JSON 매니페스트의 파일 항목은 [이름, 콘텐츠 해시, 64KB 청크로 분할된 콘텐츠 해시 배열, 파일 실행 가능 여부를 나타내는 정수 플래그]와 같습니다.
6. JSON 매니페스트의 심볼릭 링크 항목은 [이름, 대상 경로]와 같습니다.
7. 이러한 JSON 매니페스트는 각 버전에 대해 서버에서 생성되고 캐시됩니다. JSON 매니페스트의 각 파일에 대해 서버는 콘텐츠 종속 청크를 사용하여 파일을 가변 길이 청크로 분할한 다음 SHA256을 사용하여 청크를 해시하는 간단한 중복 제거 알고리즘을 실행합니다. 이렇게 하면 콘텐츠가 몇 바이트씩 이동하더라도 동일한 파일의 다른 버전에 대한 대부분의 청크 해시가 동일하게 유지됩니다. 평균 청크 길이는 최적의 중복 제거 + 압축 효율성을 위해 대략 64KB입니다. 청크가 더 크면 중복 제거도 되지 않고 청크가 더 작으면 압축도 되지 않습니다. 메타데이터에 너무 많은 청크 해시가 포함되지 않도록 매우 큰 파일의 경우 평균 청크 길이도 증가합니다.
8. 앱이 서버에서 새 JSON 매니페스트를 수신하면 사용 가능한 디스크 공간을 확인하고 보편적으로 고유한 ID로 새 임시 디렉터리를 만듭니다. 이전 로컬 매니페스트를 시작점으로 사용하여 로컬 파일에서 청크를 복사하거나 서버에서 누락된 청크를 다운로드하여 새 매니페스트를 다시 만듭니다. 새 버전을 만든 후 모든 파일 내용의 디렉터리 구조와 서명을 확인합니다. 다운로드에서 손상된 것이 있으면 업데이트를 제거합니다.
9. 새 업데이트가 매니페스트에 대해 성공적으로 확인되면 새 업데이트 경로에서 앱의 새 버전을 시작합니다.
10. 이전 버전은 다른 버전이 실행 중임을 감지하고 자체적으로 종료됩니다.
11. 새 앱은 이전 버전이 종료될 때까지 기다렸다가 다른 임시 디렉토리에 복사하고 이전 버전의 이름을 아카이브 디렉토리로 바꾸고 임시 디렉토리의 이름을 이전 버전의 위치(/Applications/Ronomon.app)로 바꿉니다. 그런 다음 다시 실행되지만 이제는 이전 버전(/Applicatons/Ronomon.app)의 위치에서 실행된 다음 아카이브 디렉토리를 정리합니다.
12. 전환 중에 문제가 발생하면 이름 바꾸기 호출로 전환될 때까지 이전 버전이 표준 경로에 남아 있습니다.

전반적으로 프로덕션에서 매우 잘 작동합니다. 중복 제거 및 압축은 일반적인 주요 버전 업데이트에 대해 약 33%만 다운로드하면 되며, 부 업데이트에는 앱에 따라 1-2MB만 필요합니다. 자동 업데이트는 Electron 및 앱 코드를 하나의 원자 단위로 처리하며 프로세스에서 코드 서명을 위반하지 않습니다.

+1 아이디어로
+1 asar 의 이름을 바꾸려면

나는 이것에 대해 문제를 제기하기 위해 왔습니다. 이것이 이미 존재한다는 것을 알았으므로 여기에 + :100:을 추가하겠습니다.
JRE, .NET 또는 Adobe Air와 같은 솔루션이 완전히 필요합니다. 런타임을 각 앱과 함께 포장하면 앱이 정말 커지기 때문입니다.

앱과 런타임을 분리하는 것에 대한 업데이트가 있습니까?

솔루션이 개발되어 닫혀 있습니까?

@PierBover 이 문제는 열려 있습니다.

이것은 - https://github.com/KeitIG/museeks/issues/48 - 폐쇄되었습니다. 다른 사람의 저장소에 있습니다.

오 @championswimmer 에게 감사하고 혼란을 드려 죄송합니다.

독립 런타임에 대한 소식이 있습니까? 이것은 작업 중인 것입니까?

@PierBover 현재 버전 조각화로 인해 곧 발생하지 않을 것입니다(같은 정확한 버전을 사용하는 2개의 전자 앱을 찾기가 어렵습니다). 아마도 v1이 출시된 후일 것입니다.

@jorangreef 모든 플랫폼에서 차등 업데이트 메커니즘을 사용합니까? 해당 코드를 독립형 모듈로 출시할 수 있다면 정말 좋을 것입니다.

@championswimmer 네, 제 앱을 위한 빌드 스크립트를 만들 수 있었으므로 이제 앱을 배포하는 데 문제가 없습니다. 하지만 흥미로울 것 같아서 계속 지켜보고 있습니다.

@etiktin 예, 차등 자동 업데이트는 현재 모든 플랫폼에서 작동합니다. 다운로드를 수행하는 최소 설치 프로그램도 포함되어 있으면 설치 프로그램을 여러 앱에서 공유할 수 있으며 이미 사용 가능한 경우 캐시된 버전의 Electron을 사용할 수 있습니다. 이렇게 하면 설치 속도가 훨씬 빨라집니다. 사람들이 관심이 있다면 소스를 공개하고 싶고 앞으로 몇 달 안에 코드를 공개하려고 노력할 것입니다.

예를 들어 "App 1"에는 0.30.x가 필요하고 0.31.x에서 실행할 수 없으며 "App 2"에는 그 반대가 필요합니다. 이 시나리오의 승자는?

그런 다음 두 버전을 설치해야 하고 VS C++ 2008이 2005와 공존하는 것처럼 두 개의 런타임이 있을 것입니다. VS C++ 런타임이 설치되는 방식이 정말 마음에 듭니다. 설치 프로그램이 없는 경우 필요한 버전을 설치하고 나머지는 다음에 의존할 수 있습니다. 나중에 다른 런타임이 공존할 수 있습니다. 버전 요구 사항의 적용도 설치 프로그램에서 더 쉽게 수행되는 것 같습니다.

@louy2 Visual C++ 예제(출시간 3년)와 Electron(최소 월 3회 출시)에는 차이가 있습니다.

대부분의 경우 여기에 '이것은 고장난 시스템입니다'라는 인용문으로 말하겠습니다.
Electron 생태계의 앱은 +- 0.0.1 또는
0.1.0 버전 차이

2016년 2월 20일 18:55 Pierre de la Martinière <
[email protected]>은 다음과 같이 썼습니다.

@louy2 https://github.com/louy2
Visual C++ 예제(릴리스 간 3년) 및 Electron(당 3개 릴리스)
최소 한달)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/atom/electron/issues/673#issuecomment -186595285.

+1

fpm 을 사용하여 전자를 .deb 패키지로 패키징했습니다. 이것은 Linux(적어도 Debian 또는 RPM 기반)에서 공정한 출발점이 될 수 있습니다. 여기에서 살펴볼 수 있습니다: iamale/electron-deb ; 또한 예제 앱이 있습니다 . (asar에서도 작동합니다. 런타임 패키지에 MIME 항목을 추가하기만 하면 됩니다.)

우리가 다른 플랫폼에도 그런 것을 가지고 있다면 정말 좋을 것입니다! 아마도 Windows 용으로 패키지를 시도 할 수 있지만 더 이상 적극적으로 사용하지 않으며 실제로 사용 경험이 많지 않습니다.

(이 스레드를 알려준 @louy2 에게 감사드립니다!)

그건 그렇고, .asar의 MIME 유형은 무엇입니까? application/x-asar 하시겠습니까?

@iamale fpm 대신 AppImageKit 를 살펴보았습니까? 주요 이점은 여러 라이브러리와 모두를 만드는 대신 하나의 실행 파일로 모든 Linux 배포판을 대상으로 지정할 수 있다는 것입니다. 또한 실행 파일과 함께 번들로 제공되므로 더 이상 사용자에게 종속성을 설치하도록 요청할 필요가 없습니다. 좋은 프로젝트입니다, 봐주세요.

그리고 마임은 어떻습니까 application/x-electron ?

@steelbrain 좋은 생각입니다. 그러나 이것은 원래 문제를 해결하지 못합니다. Electron 런타임은 각 앱과 함께 패키징되어야 합니다(이미지는 자체 포함되어야 하기 때문에). 이것이 바로 이 문제에 대한 것입니다. 비록 내 생각에 Electron 앱에서 AppImages를 만드는 것이 상대적으로 쉬워야 한다고 생각하지만, 전통적인 패키지 관리를 사용할 수 없을 때(드문 배포판이나 특권이 없는 사용자) 이것이 좋을 것이라고 생각합니다. 지적해주셔서 감사합니다!

그런데 application/x-electron 는 훌륭하게 들리지만 아마 계속 사용할 것입니다.

추가된 asar 지원! 아직 저장소에 없으며 오늘이나 내일 중 다시 빌드할 예정입니다. 지금 은 transfer.sh에서 패키지를 받을 수 있습니다(링크는 다음 2주 동안 유효합니다).

.asar 안에 asar.json이 있어야 다음과 같이 알 수 있습니다.

• 추천 버전
• 호환되는 버전
  완료되면 전자(모든 버전)를 사용하여 웹에서 (1) 자체 업데이트(검사기) 및 (2) 컴퓨터의 기존 버전을 확인하는 하나의 앱이 필요합니다. 그런 다음 호환되는 버전이 있으면 구문 분석합니다. 열린 .asar의 여는 경로, 그렇지 않으면 권장 버전을 다운로드하고 다시 확인하십시오. 앱 자체는 Electron 또는 Python으로 작성할 수 있습니다(최소한의 UI만 필요하거나 전혀 필요하지 않음).

아이디어는 다음과 같습니다. 필요한 전자 버전이 다운로드되었는지 확인하는 앱은 필요한 전자 버전과 아무 관련이 없습니다.

필요한 경우 default_app의 콘텐츠와 앱을 제외한 나머지 앱을 업데이트할 수 있습니다.

그리고 거기에 app.setPath("userData", __dirname + "/ElectronVersions"); 로 버전을 저장한 다음 해당 버전을 그대로 두고 필요에 따라 새 버전을 설치할 수 있습니다.

fpm 대신 AppImageKit 을 살펴보았습니까?

https://bintray.com/probono/AppImages/Atom/_latestVersion#files 에서 Atom의 AppImage를 사용할 수 있습니다. chmod a+x 다운로드하고 너무 오래되지 않은 x86_64 Linux 배포판에서 실행하기만 하면 됩니다.

문제는 리눅스에만 있는 것이 아니라 크로스 OS로 만드는 방법이 필요합니다. 즉, Linux, Windows 및 Mac OSx에서 실행할 수 있어야 합니다.

런타임이 사용 가능하고 asar 패키지와 최신/호환되는지 조회하는 일종의 OS별 런처

(수년 후) 토론을 요약하자면 다음과 같습니다.

1. @zcbenz 는 로컬 Electron 인스턴스를 관리하는 런타임을 제안 하므로 .asar 패키지만 배포되고 Electron 바이너리 번들을 피할 수 있습니다. 런타임은 .asar 패키지의 실행도 관리합니다.
2. @YurySolovyov 는 런타임에서 .asar 패키지에 사용할 버전을 알 수 있도록 추가 정보(예: 필수 Electron 버전)가 포함된 매니페스트 파일의 개선을 제안 합니다. 이 접근 방식에 대한 개요가 여기 에 나와 있습니다.
3. @joshuawarner32 는 여러 런타임 버전, 바이너리 패키징(예: .deb ) 및 .asar 패키지에 대한 자동 업데이트에 대한 아이디어를 소개합니다. 또한 배포 서버에 대한 아이디어도 고려됩니다.
4. @paulcbetts 는 Steam 모델을 살펴보고 유사한 것을 구현하도록 제안 합니다. 그는 다른 Electron 버전 등을 지원하는 로컬 런타임 아이디어와 관련된 복잡성 을 지적 합니다.
5. [사람들은 중국의 인터넷 속도와 어린 시절 문제에 대해 토론합니다]
6. @hokein 은 런타임이 업그레이드될 때의 복잡성을 지적 합니다. 특히 wrt. Electron 헤더에 대해 다시 빌드해야 하는 기본 모듈.
7. @etiktin 은 LTS 및 최신 버전을 원하므로 프로덕션 준비 앱은 최신 버전이 아닌 LTS를 사용합니다.
8. @Tribex 는 시맨틱 버전 관리 를 고수한다면 _all_ 버전의 로컬 인스턴스가 필요하지 않고 호환되지 않는 버전만 가질 필요가 있다고 말합니다.
9. @jorangreef 는 자체 애플리케이션을 위해 이미 프로덕션 단계에 있는 차등 자동 업데이트 시스템의 예를 제공합니다.
10. @iamale 은 .asar 패키지를 실행하기 위해 Electron의 fpm 패키지를 구축 했습니다.

_면책 조항: 논의의 주요 요점만 포함하려고 했습니다. 제가 놓친 부분이 있다면 양해 부탁드립니다!_

여기까지의 토론을 읽고 요점 을 요약하고 그 중 일부를 다루려고 했습니다. "깊은 플랫폼 통합"이 포함된 런타임 아이디어는 단순한 로컬 인스턴스를 넘어선 것입니다. 시스템 전체 런타임으로 작동하는 최소 실행 가능한 제품을 정의해야 합니다. 또한 유용할 수 있는 있으면 좋은 기능을 추가했습니다. 마지막 섹션에서는 구현해야 하는 변경/기능에 대해 설명합니다.

이론적 해석:

대부분의 개발자가 수행하는 작업(예: Electron 바이너리 번들)은 모든 공유 라이브러리를 정적으로 연결하는 것과 같습니다! 그것은 우리가 판매하는 모든 피자와 함께 오븐을 배달하는 것과 같습니다.

MVP:

• 환경 관리자 : 로컬에서 사용 가능한 Electron 인스턴스를 추적합니다. 어떤 패키지가 어떤 인스턴스와 호환되는지 결정하는 데 사용할 수 있습니다(향상된 package.json 사용[아래 참조]). 또한 실행할 패키지에 대한 올바른 환경 변수를 설정해야 합니다.
• 업데이트 관리자 : 자동 업데이트(+ 알림) 및 차등 자동 업데이트의 가능성이 논의되었습니다. 로컬 인스턴스를 최신 버전으로 업데이트하는 데몬으로 사용하면 좋을 것입니다.

가져서 좋다:

• 패키지/종속성 관리자 : Atom의 apm 와 마찬가지로 .asar 패키지(GitHub 또는 주어진 URL 등에서)를 다운로드하고 로컬에 설치하려면 패키지 관리자가 필요합니다( apt-get 와 비교 가능). Ubuntu의 brew ).

요구 사항:

• 향상된 매니페스트 파일 : package.json 에는 필요한 Electron 버전을 나타내는 semver (또는 semver 범위)도 포함되어야 합니다.
• 정의된 설치/제거 절차 : ATM .asar 패키지에는 응용 프로그램을 실행하는 데 필요한 모든 것이 들어 있습니다. 그러나 설치 시 소스 및 다운로드 종속성 모듈만 제공하는 것이 가능합니다. 우리가 너무 용기를 낸다면 모든 애플리케이션에 대한 종속성을 포함하는 일종의 _global_ 디렉토리를 가질 수 있습니다(npm 3의 평면 구조 가 도움이 될 수 있음). 그러나 이것은 매우 복잡하고 빨라질 수 있습니다(예: 앱 제거 시).
• 다중 로컬 런타임 : 지금까지 시맨틱 버전 관리가 적용된 경우 0.x 및 1.x 두 가지 호환되지 않는 버전만 있습니다. 부 버전과 패치는 이전 버전과 호환 되어야 하므로 시스템에 최신 버전의 0.x 및 1.x 만 있으면 됩니다.

영감:

• 환경/종속성 관리자: Python의 virtualenv , Ruby의 rbenv 및 ruby-build 참조.
• 패키지 관리자: Python의 pip , Atom의 apm .
• 업데이트 관리자: Chromium의 zygote 프로세스 에는 _무음, 백그라운드_ 업데이트에 대한 흥미로운 접근 방식이 있습니다.
• 코드 번역기(새 API에 적응하기 위해): Pythons 2to3 .

epm (전자 패키지 관리자)는 이미 이름으로 사용되는 것 같습니다...
런타임 elec 및 앱 .tron 을 호출할 수 있습니까? TRON에는 상표권 문제가 있을 수 있지만 멋지게 들릴 것입니다. ;)

아마도 uepm (범용 전자 패키지 관리자)일 수 있습니다. Electron이 지원하는 모든 OS에서 실행되기 때문입니다... 또는 epmc (전자 패키지 관리 센터) 및 파일 .epack (전자 패키지). 확장 프로그램은 최소한 .tron 보다 더 나은 소리를 내고 영화와 혼동될 수 없습니다("저 트론을 내놔, 친구" _영화를 건네줌_).

전자와 관련된 이론 물리학 분야에도 많은 단어가 있습니다.

• 페르미온
• 렙톤
• 요금
• 쿨롱
• 파울리

그리고 직접적인 관련은 없지만 패키지 관리자에서 일어나는 일에 따르면

• 보손
  ;)
  (나는 광자가 이미 촬영되었다고 믿는다)

@kapouer +quark? 찍은 것인지 확실하지 않다.

Quark는 가져갔고 나머지는 모릅니다. 그러나 이 제안 목록이 현상 유지를 권장하지 않을 때 현상 유지를 유지해야 하는 이유는 무엇입니까? 그러나 우리가 그것에 있기 때문에 Hauldron이라는 이름을 짓지 않겠습니까? LHC에서 촬영. Collider는 좋은 생각이 아닙니다. 제품에 부정적인 영향을 미치고 있습니다. 그 의미는 전쟁과 밀접하게 연관되어 있기 때문입니다...

Particle(s) ? 꽤 길지만.
Wiki의 입자 목록

명명이 중요하지만 런타임/업데이트/패키징/배포 의미를 먼저 조사해야 한다고 생각합니다.

lepton 는 전자가 속한 입자군이기 때문에 완벽해 보입니다.

약간 범위를 벗어난 아이디어: 보다 일반적인 런타임 관리자가 훨씬 더 훌륭할 것입니다(실제로 구현하기가 더 어렵지는 않음). 예를 들어 @nwjs 바이너리도 포함하고 동일한 버전 관리자에서 관리할 수 있습니다(@asdf-vm과 같지만 GUI 런타임용).

빠르고 더러운: https://github.com/iamale/lepton. 지금은 고정 버전만 지원하고(semver는 다음 작업임) 앱의 압축이 풀립니다(예: 아직 .asar-s 없음).

멋진!

+1

.asar, @iamale 이 없더라도 어떤 파일을 열어야 하는지 알 수만 있다면 괜찮을 것 같습니다. 예를 들어, package.json 에 연결하는 json 코드가 있는 file.something 를 가질 수 있으므로 무엇을 열어야 하는지 알 수 있습니다...

이것은 아주 미친 생각이지만 package.json 의 electron 필드를 사용하여
모든 (물론, ANY와 같지는 않지만 준비된) npm 패키지 실행 가능?
처럼:

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

이것은 electron 에 npm 패키지를 설치하고 호스트 시스템에서 실행 가능하고 볼 수 있도록 하는 기능을 추가하여 달성할 수 있습니다.
처럼

electron install atom

이것이 작동하려면 electron 명령과 실제 런타임 번들을 분할해야 합니다.

하지만 package.json의 이름을 package.electron 로 바꾸고 내용을 다음과 같이 변경하는 것은 어떻습니까?

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

이 예에서는 전자 1.2를 사용하는 것이 좋습니다. 찾을 수 없으면 1.2.1과 1.2.5 사이의 버전이 있는지 확인하고, 1.3.1을 확인하지 않으면 1.3.0.1을 확인하고, 그렇지 않으면 1.3.0.1을 확인합니다. 1.1의 경우, 그렇지 않은 경우 1.2를 다운로드합니다.

권장 버전을 자동으로 다운로드하는 것과 같은 것이 있을 수 있지만 그렇지 않은 경우 호환되는 버전을 확인합니다. 그리고 호환되는 것을 하나하나 가져와서 확인하고 아무 것도 안되면 호환되지 않는 버전을 사용하지 않을 것인지 사용자에게 물어보고 no 를 누르면 호환되지 않는 버전으로 실행됩니다. PC에서 찾았고, 아무것도 발견되지 않으면 호환되지 않는 버전을 사용하라는 메시지 대신 Electron 설치가 감지되지 않았다는 오류 팝업을 표시합니다.

@sapioit 별도의 매니페스트를 갖는 것은 나에게 좋은 생각처럼 들립니다. 사용자 지정 파일 확장자를 사용하면 작업이 상당히 간소화됩니다. (.electron이 조금 길어 보이지만.)

@iamale 의 lepton에 따르면 아마도 .lept?

package.json 를 사용하지 않음으로써 어떤 이점도 보지 못합니다. 전자 장은 절연 부분을 수행합니다. Babel과 ESlint는 이 기술을 사용하고 잘 작동합니다.
이렇게 하면 npm에 직접 앱을 게시하거나 npm을 통해 훨씬 쉽게 앱을 게시할 수 있습니다.

예, 두 번째 @YurySolovyov - package.json 에 넣는 것이 더 적절하다고 생각합니다.

@YurySolovyov 추가 파일의 장점은 런타임이 추가 파일 확장자에 대한 처리기를 등록하고 파일의 기본 오프너로 자동 실행할 수 있다는 것입니다. package.json을 사용하여 이 작업을 수행하려면 모든 JSON 파일에 대한 처리기를 등록해야 하므로 사용자에게 고통이 될 것입니다.

@Tribex 공정한 포인트.
아마도 package.electron은 런타임 "Hey, take a look at package.json, it should contain the info on how to launch it" 를 알려주는 일종의 링크일 수 있습니다. 이것은 "미친" 아이디어였습니다. 그래서 네, 저는 그것을 조정하는 것이 좋습니다.

@tribex 에 동의합니다. 별도의 파일이 필요하거나 package.json의 이름을 변경해야 합니다. 다른 것에.

@wurysolovoyov 당신은 그렇게 할 수 없습니다. 파일을 열 수 있는 유일한 방법은 파일에 확장자가 첨부되어 있는 것입니다. 이 경우 모든 확장자는 동일한 소프트웨어로 열립니다. 따라서 electron 이외의 다른 것으로 $ .json 을 열 수 없는 것이 문제가 되지 않는 한(적절한 전자 앱이 열리지 않으면 오류가 발생함) 여전히 그렇게 할 수 있습니다. 그러나 .json 파일을 열 수 있도록 하려는 사람은 파일을 열 때 사용하는 프로그램으로 열 수 있습니다.

그렇지 않으면 편집기를 먼저 열거나 1분마다 .json 를 열 항목을 변경하지 않고는 파일을 편집할 수 없습니다.

@wurysolovoyov 가 아니라 @YurySolovyov 를 의미합니다.

명확하게 언급하지 않았을 수도 있습니다. package.electron 의 목적은 이 디렉토리가 앱이라는 표시자 역할을 할 뿐이므로 런타임이 동일한 폴더에 있는 package.json 를 참조할 수 있습니다. , 앱을 실행합니다. package.json 를 직접 열면 OS에서 .json 와 연결된 모든 항목에서 열립니다.

바로 가기 시스템과 같은 종류입니다.

@YurySolovyov 이 경우 해당 정보를 package.json 또는 package.electron에 정의하는지 여부는 취향의 문제일 뿐입니다. 나는 그것이 나에게 더 깨끗해 보이기 때문에 개인적으로 그것을 별도로 보관할 것입니다. 아마도 package.json의 엔진 속성이면 충분할 것입니다.

@Tribex npm에 앱을 게시하기 위한 요구 사항이기도 합니다. 유효한 package.json 가 있어야 합니다.

@YurySolovyov 맞습니다. package.electron을 사용했다면 package.json은 여전히 ​​존재합니다. .electron은 런타임 정보를 정의하는 데만 사용되거나, 제안의 경우 마커가 될 수 있습니다.

기본적으로 package.electron 는 실행 가능한 _marker_ 로만 존재하므로 package.json은 여전히 ​​자체 데이터와 함께 존재하지만 이것이 별도의 파일이 필요한 이유입니다. _ 더블 클릭은 앱을 엽니다 _. 나는 여전히 package.electron 의 이름을 my-app.electron 또는 my-app.electron 로 바꿀 수 있기를 원합니다.

@sapioit 확실히, 그것이 .electron 파일을 갖는 요점입니다. .electron 확장자가 있는 한 원하는 이름을 지정할 수 있습니다.

런타임 핸들러가 *.electron을 살펴본 다음 package.json에서 실행할 전자의 버전을 결정한 다음 package.json을 다시 읽도록 하는 것은 여전히 ​​그다지 깨끗하지 않은 것 같습니다.

@Tribex 왜 package.json이 두 번 읽힐 것이라고 생각합니까?

• 런타임 정보를 .electron 파일에 넣으면 런타임은 모든 것이 올바르다고 가정하고 package.json 를 사용하여 앱을 시작하고 그렇지 않은 경우 페일패스합니다.
• 런타임을 package.json 직접 또는 electron 섹션 아래에 넣는 경우에도 읽기가 1회만 필요합니다. 이렇게 하면 .electron 파일(아이디어?)에 무엇을 넣어야 할지 잘 모르겠습니다. 비어 있어도 괜찮을 것입니다.

@tribex .electron 는 package.json 를 가리킬 수 있습니다. 어떤 이유로 package.json의 이름이 바뀌는 경우를 대비해서입니다. 이런 식으로 NPM package.json 를 가질 수 있고 Electron에 대해 다른 package.json (아마도 electron.json )를 가질 수 있습니다. 왜요? 앱에 package.json이 패키지 관리자로 가져올 항목을 알려 주기를 원할 수 있지만 일단 가져온 후에는 파일을 이동하거나 이름을 바꿀 필요 없이 앱을 실행하고 싶을 수 있습니다.

_ app.electron _

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

또는

_ myapp.electron _

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

또는 모든 것을 package.json 에 넣으면 .electron 만 앱을 여는 데 사용하려는 .json 에 대한 링크를 가질 수 있습니다.

_ app.electron _

{
  "package": "package.json"
}

또는

_ myapp.electron _

{
  "package": "electron.json"
}

또한 같은 디렉토리에 두 개의 런처(하나는 클라이언트용, 다른 하나는 서버용)를 갖고 싶을 수도 있습니다. 클라이언트는 서버 파일을 사용하여 플레이어가 하나만 있는 로컬 서버를 시작합니다. 이렇게 하면 파일의 99%(500MB 이상의 파일을 사용하는 게임이 있다고 가정)와 5-6개의 다른 파일을 모두 복제할 필요가 없으며 두 개의 별도 디렉토리에 둘 필요가 있지만 하나의 추가 디렉토리만 있으면 됩니다. 자체적으로 서버를 시작할 수 있는 파일입니다. 말 그대로 동일한 디렉토리에 여러 실행 파일이 있는 것과 같습니다.

별도의 package.electron 는 package.electron.json 또는 .json 확장자를 갖는 이름으로 지정되어야 합니다. 이는 편집기와 IDE가 구문을 올바르게 결정할 수 있도록 하기 위함입니다.

@StreetStrider 차라리 .electron 가 실제로 유효한 .json 임을 IDE에 가르쳤습니다.
그리고 이것은 우리가 @sapioit 와 .json 연관에 대해 논의 했음을 지적합니다. 인기있는 OS는 이중 확장 연결을 지원하지 않는다고 생각합니다. ( .foo.bar )

편집할 때 .json 확장자를 추가할 수 있습니다. 또는 마우스 오른쪽 버튼을 클릭하고 편집기로 열 수 있지만 기본적으로 실행기로 파일을 열어 사용자가 편집기로 파일을 열 수 있도록 하는 Adobe Air와 마찬가지로 문제가 발생하지 않습니다.

@sapioit 공정한 요점, 나는 package.json을 가리키는 것에 대해 당신의 의견에 동의한다고 생각합니다.

나에게 런타임과 플레이어는 별개의 것입니다. 이것은 이제 플레이어로서 더 많이 나옵니다. 그리고 패키지 관리자의 개념에 익숙한 기술적으로 기울어진 커뮤니티 외부에서 널리 사용되지 않을 것 같습니다.

당면한 문제는 런타임을 만드는 것입니다. JRE 및 .Net과 비슷합니다. 선수가 아닙니다.

@baconface 자세히 설명해 주시겠습니까? 당신이 여기서 구별하는 것이 무엇인지는 불분명합니다.

@baconface 예, 하지만 JRE와 .Net도 설치할 수 있습니다.
JRE가 없으면 .jar 파일은 electron 런타임이 없는 패키지만큼 쓸모가 없습니다.

이상적으로 이 도구는 전자를 설치하는 기본 방법으로 배포되거나 이상적으로 확산 문제를 완화하는 방법으로 배포됩니다.

이를 위해서는 .electron 대치된 특정 파일을 실행하는 실행 파일을 만드는 작은 도구만 있으면 됩니다. 간단합니다.

.lept 멋지네요. 감사합니다!

개인적으로 새로운 구성을 만들 필요가 없다고 생각합니다. pkg.engines 여기에서는 매우 간단해 보입니다(하지만 1.x || >=2.5.0 || 5.0.0 - 7.2.3 from npm's docs 와 같은 일부 복잡한 semver 표현식을 허용해야 하므로 { recommended, compatible, etc } - @sapioit 의 예와 같은 구조라고 생각합니다). ( lepton 필드를 추가했지만 scripts.run 는 일반적으로 npm start 에 의해 호출되고 lepton은 자체 $VARIABLES 를 추가하여 의미 체계를 다소 깨뜨립니다. .)

또는 모든 것을 package.json에 넣으면 .electron이 앱을 여는 데 사용하려는 .json에 대한 링크만 가질 수 있습니다.

나에게도 좋은 아이디어가 아닌 것 같다. 여러 진입점이 있는 패키지가 있는 경우 지금 scripts 맵이 있는 것처럼 여전히 하나의 package.json에 모두 포함할 수 있습니다. 나는 다음과 같이 생각하고 있습니다.

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

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

그런 다음, 이것을 실행 파일로 정말로 원한다면 Linux / macOS에서는 간단한 셸 스크립트(#!shebang 포함 3줄)를 사용할 수 있고 Windows에서는... 음... ¯_(ツ)_/¯

먼저, Release.Breaking.Feature.Fix 또는 Semantic Version을 Explicit Versioning으로 대체해야 하는 이유 와 같이 거의 모든 것과 여전히 호환되는 동시에 semver에 대한 더 나은 대안을 제공하는 이 기사를 살펴보고 싶을 수도 있습니다.

둘째, 문제는 그것들을 실제로 어떻게 구별할 것인가이다. 내 말은, server.js 가 이미 --debug 인수를 수락했다면 왜 그걸로 귀찮게 하고 사람들이 자신의 파일 구성을 가지도록 허용하지 않겠습니까? 2.2-2.4 에서 작업하는 클라이언트와 1.4-1.9.2.1 에서만 작동하는 서버와 같이 서버에는 클라이언트와 다른 구성이 필요할 수 있습니다.
당신이 제안한 대로 우리는 더 제한적일 것입니다.

또한 --debug 뿐만 아니라 더 많은 변수를 사용하는 것은 어떻습니까? 이와 같은 더 많은 변수를 사용하여 어떻게 실행합니까? 그렇게 하는 것이 안전합니까? 결국, 하나의 파일이 그렇게 하기를 원했다면 별도의 파일을 가지고도 할 수 있었지만, 이렇게 하면 매개변수가 있는 .lept 파일을 실행했을 때 발생할 수 있는 결과가 엉망이 됩니다.

디버그 매개변수를 사용하여 서버를 실행하려면 --debug 인수를 사용하여 .lept를 실행하면 되지 않을까요? 또는 --debug 인수를 사용하여 해당 파일을 실행하는 다른 파일을 만들 수 있습니다. 너무 간단하지 않습니까?
내가 이해하기를 바랍니다...

먼저, semver에 대한 더 나은 대안을 제공하는 이 기사를 살펴보는 것이 좋습니다.

좋은 아이디어 같아요! 나는 Electron이 이 버전 체계로 전환할 것이라고 생각하지 않습니다. 또한 최종 사용자 제품에는 훌륭하지만 라이브러리, 엔진, 런타임 및 기타 항목에는 실제로 필요하지 않다고 생각합니다. 이상적으로는 사용자가 실행 중인 Electron의 버전조차 알 수 없어야 합니다 (원하지 않는 한).

서버에 클라이언트와 다른 구성이 필요할 수 있습니다.

이것은 문제가 될 수 있지만 둘 이상의 런타임 버전이 필요한 프로젝트는 상상할 수 없습니다.

디버그 매개변수를 사용하여 서버를 실행하려면 --debug 인수를 사용하여 .lept를 실행하면 되지 않을까요?

예, 왜 안되나요?

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

이 이중 구성 package.json은 서버가 a) 클라이언트와 많은 코드베이스를 공유하고 b) 최종 사용자가 실행하도록 의도된 경우에 좋습니다. 다른 경우에는 각각 고유한 package.json이 있는 두 개의 저장소/패키지로 모두 분리하는 것이 좋습니다.

Electron을 위한 것이 아니라 빌드하는 프로젝트를 위한 것입니다. Electron은 필요에 맞게 Semantic Versioning에서 파생된 자체 시스템을 갖고 있으며 변경할 가능성은 거의 없지만 Lepton 및 기타 프로젝트의 경우 아직 _ development hell _, 시맨틱 버전 관리를 완전히 건너뛰는 것이 좋습니다.

디버그 매개변수를 사용하여 서버를 실행하려면 --debug 인수를 사용하여 .lept를 실행하면 되지 않을까요?

예, 왜 안되나요?

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

아니요, 구성을 의미하는 것이 아니라 실행기를 통해 의미합니다. 그래서 이거:

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

그러나 파일을 열지 않고 --myoption=5 인수를 사용하여 .lept 를 시작합니다. 런처를 통해 인수를 "_push_"할 수 있다고 확신하기 때문에 원하는 경우 사용자 정의 인수로 실행할 것이기 때문에 --debug 에 대한 필요성도 제거할 수 있습니다.

그러나 한 가지는 우리가 동의할 수 있다고 생각합니다. 사용자는 지원을 받고 있는 안정적인 버전을 원합니다. 사람들이 많은 숫자를 기억할 가능성이 낮지만 일반적으로 첫 번째 숫자를 기억하기 때문에 " 릴리스 "를 자체 번호로 만들었습니다.

@sapioit "Release" 필드가 최종 사용자를 위한 것이라면 다른 필드는 무엇을 위한 것입니까? 최종 사용자의 경우 새 버전이 사용 가능하고 업데이트된 런타임(package.json의 범프를 통해)이 필요한 경우 런타임도 업데이트되어야 합니다.

문제는 다음과 같습니다.

1. 사용자는 지원 이 제공되는 버전을 알고 싶어합니다.
2. 그들은 _쓸모없는 숫자_를 많이 기억하고 싶지 않기 때문에 버전을 기억하기로 선택하면 버전 1.7 13 버전을 기억할 가능성이 더 큽니다(예:).
3. 어떤 사람들은 Thunderbolt 호환성이 추가된 이후로 그래픽 카드가 무작위로 배출되기 때문에 많은 nVidia 드라이버 가 업데이트되지 않는 것과 같은 특정 일이 발생할 때까지 업데이트를 원하지 않습니다(사용자/케이스에 따라 , 컴퓨터 부팅 후, 게임을 연 후 또는 게임을 시작한 지 몇 분 후). 이것은 사용자가 최신 버전의 제품을 사용하지 못하게 하는 이유(그러나 KMPlayer의 광고 또는 locked on 자동 업데이트 와 같은 다른 많은 이유가 있음)의 좋은 예입니다. 이렇게 하면 복잡성을 제거하여 변경 로그를 더 쉽게 볼 수 있습니다.

그 이유 중 일부에 불과합니다... 더 자세히 설명할 수 있다면 더 자세히 설명하고 왜 그러한 선택을 했는지 더 잘 설명할 수 있습니다.

@sapioit >= 12.1 와 같은 semver 범위는 지원을 선언하기에 충분히 유연하지 않습니까?
사용 가능한 새 버전의 런타임이 있고 버전 범위를 충족하는 경우 앱의 모든 다음 실행은 가능한 최신 런타임을 사용해야 합니다.

그들은해야합니까? 그러나 기술적인 제한(KMPlayer의 광고 및 nVidia 드라이버와 같은)으로 인해 그렇게 하지 않기로 결정하면 어떻게 될까요?

@sapioit 그런 다음 런타임 범위를 올바르게 명시했는지 확인하십시오.

@sapioit @YurySolovyov 이 토론이 여기에 관련이 있습니까? 런타임 관리자는 전자가 사용하는 버전 관리 시스템을 따라야 합니다. 나는 전자가 사용해야 하는 버전 관리 시스템에 대한 논의는 다른 문제에 속한다고 생각합니다.

@Tribex 다소. 이미 기본적으로 해결된 것들을 너무 복잡하게 만들어서는 안 된다고 말하고 싶었습니다. 그러나 런타임 관리자는 이와 관련하여 가장 간단한 작업을 수행해야 한다는 데 동의합니다.

@yurysolovyov 그렇다면 단순히 플레이어가 원하는 만큼 버전 번호의 섹션을 허용하지 않는 이유는 무엇입니까?

@sapioit

Electron을 위한 것이 아니라 빌드하는 프로젝트를 위한 것입니다.

Lepton에는 아직 할당된 버전 체계가 없으며 패키지(앱)는 원하는 버전 체계를 사용할 수 있습니다. 이를 처리해야 합니다(예: Lepton 자체를 통해 앱 업데이트를 지원하려는 경우).

런타임은 이상적으로는 제품이 아니므로 semver를 사용해야 하지만 다시 3-숫자 버전 관리가 이제 지원됩니다(개발자는 범위 지정에 주의해야 함). 명시적 버전 지정 제안과 같이 3개 이상의 숫자를 지원해야 하는 경우 파서를 확장해야 합니다(파이썬의 경우 k-bx/python-semver 또는 podhmo/python-semver — 전자를 분기하는 것이 좋습니다. 더 최근에 업데이트되었지만 전자는 node-semver API를 더 밀접하게 따르고 현재 사용하고 있습니다.

nodejs 프로젝트를 위해 파이썬으로 작성된 런타임 패키지 관리자를 갖는 것은 단지 나쁜 생각이라고 말할 수 있습니까?
그냥 하지 맙시다. 그것이 무엇이든, 렙톤이든 뭐든. 노드에 작성하거나 다른 것을 사용합시다. 그리고 당신이 잘 생각한 의미론적 버전 체계보다 어떻게 당신이 더 잘 안다고 생각하는지에 대해 불필요한 메일로 이 문제를 스팸 메일로 보내지 맙시다.

@championswimmer 전자 패키지가 포함된 런타임 관리자와 다른 버전이 다운로드될 때 표시되는 UI를 구축하는 것은 흥미로울 것입니다.

@championswimmer iamale/lepton 은 일종의 폐기 참조 구현입니다. 이 스레드 주위에 떠도는 다양한 아이디어를 테스트하기 위해 올렸습니다. 그 이상은 아닙니다.

@iamale 그러면 혼동을 피하기 위해 readme에 명시해야 합니까?

@YurySolovyov 완료!

실제 구현의 경우 두 가지 옵션이 있습니다. node.js를 사용하거나 C/++ 또는 Go와 같은 컴파일된 언어를 사용합니다. 노드의 경우 node.js를 번들로 묶어야 합니다(또는 다운로드한 전자 인스턴스 중 하나에서 실행할 수도 있습니다. 하지만 _모든_ 정상적인 전자 버전에서 실행되는지 확인해야 함).

@iamale 실제로는 그렇지 않습니다. 기본 설치된 버전을 실행하기만 하면 됩니다. 그 후 업데이트는 현재 위치에서 최신 버전으로 전환할 수 있습니다.

필요한 경우 모든 것을 업데이트할 수 있기 때문에 특정 버전 하나를 사용하는 것이 좋습니다.

Lepton 은 이제 이미지 형식 이기 때문에 그다지 좋은 이름이 아닐 수 있습니다.

그래서... 우리는 그것을 지금 뭐라고 부르나요? Hadron ?

쿼크? 누군가 "Muon"이라는 이름을 사용하고 싶다면 내 프로젝트 중 하나의 이름을 바꿀 수 있습니다.

여기에서 이름 지정이 실제로 가장 덜 중요한 부분이 아닙니까?
설치/업데이트/런타임 의미 체계에 동의했습니까?

그냥 electron 가 아닌 이유 ...

7월 15일 작품 2016 om 13:22 heft Joshua Bemenderfer [email protected] het volgende geschreven:

쿼크? 누군가 "Muon"이라는 이름을 사용하고 싶다면 내 프로젝트 중 하나의 이름을 바꿀 수 있습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

@yurisolovyov 우리가 동의했다고 생각합니다... 다소간.
@job-v 그것이 내가 줄곧 제안해 온 것입니다. 하나만 선택해서 붙이도록 합시다.

@zcbenz 이 스레드를 관찰하고 있습니까?
그렇다면 여기에서 몇 가지 지침을 얻기 위해 이것이 어떻게 작동해야 하는지에 대한 비전을 갖는 것이 좋을 것입니다.

안녕
이 전자 런타임 에 대한 업데이트가 있습니까?
@zcbenz 다음에 대한 모든 토론에 대해 어떻게 생각하세요?

• 전자 버전 선택
• 적절한 버전 설치
• win, linux, mac에서 작동하도록 준비하십시오.
• 어떤 도구를 사용하여 빌드합니까(python, node, go, C++)?
  @YurySolovyov @sapioit 멋진 아이디어에 감사드립니다
  @iamale 은 데비안 기반 destros '우분투 ...'에 대한 솔루션 작업입니다.

@alnour-altegani
예, 외부 패키지에 의존하지 않기 때문에 모든 dpkg 기반 배포판에서 작동합니다. RPM 패키지는 비슷한 방식으로 생성할 수 있습니다. 왜 안 될까요?

나는 모든 Electron에 대한 중앙 저장소를 시작할 생각입니다. 즉, 다음을 실행할 수 있습니다.

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

@iamale 나는 전자를 deb 패키지로 만들고 수동으로 설치하거나 많은 전자 버전 deb 패키지의 중앙 저장소에서 설치할 응용 프로그램의 종속 항목으로 사용한다고 생각합니다.
그런 다음 설치 후 이 패키지를 사용하여 사용자 응용 프로그램을 실행합니다.

누군가이 작업을 시작하면 여기에 링크 할 수 있습니다 ...

@sapioit 저는 Linux(APT/RPM) 솔루션 작업을 시작했습니다. .asar를 업로드하면 패키지로 변환되어 리포지토리에 추가되는 간단한 서비스입니다. Windows 및 macOS로도 확장할 수 있어야 하지만 현재로서는 이에 대한 약속이 없습니다.

@iamale 멋지다! Windows에서 작동하게 되면 알려주세요.

Linux용 Flatpak 런타임을 만드는 것은 어떻습니까? 이렇게 하면 여러 앱 간에 런타임을 공유할 수 있고 샌드박싱도 얻을 수 있습니다.

Flatpak이 systemd 에 대한 종속성을 제거하면 업스트림 패키징을 위해 Linux에서 보편적이 될 것입니다.

여러 앱 간에 런타임을 공유할 수 있습니다.

Flatpak으로는 불가능하다고 생각했는데..?

@iamale Flatpak은 런타임을 공유하도록 설계되었습니다. 앱 개발자는 런타임을 선택하고 해당 런타임용 SDK를 설치한 다음 flatpak-builder 또는 이와 유사한 것으로 앱을 빌드합니다. 그런 다음 사용자가 앱을 설치하면 Flatpak이 관련 런타임을 설치합니다.

@moosingin3space 설명 감사합니다! 그때는 확실히 고려해 볼 가치가 있습니다.

Flatpak에 대해 내가 좋아하는 또 다른 점은 사용자가 런타임 개발자 및 앱 개발자가 실행하는 저장소를 (투명하게) 추가하고 업데이트를 자동으로 만드는 사용 사례를 중심으로 설계되었다는 것입니다.

내가 볼 수있는 유일한 문제는 보안과 관련된 것입니다. Flatpak의 "포털"인터페이스를 사용하여 샌드박스를 안전하게 종료할 수 있도록 시스템 라이브러리를 수정해야 합니다.

여기 Flatpak에 대한 작업이 있는 것으로 보입니다: https://github.com/endlessm/electron-installer-flatpak

참고로 Flatpak은 파일 시스템 트리에 대한 콘텐츠 주소 지정을 수행하는 OSTree 프로젝트를 기반으로 합니다. 즉, 체크섬이 동일한 파일은 디스크에서 자동으로 중복 제거되고 업데이트는 정적 델타를 사용하여 수행됩니다. 즉, Electron은 독립적으로 업데이트하고 여러 애플리케이션에서 공유할 수 있는 공유 런타임을 제공할 수 있을 뿐만 아니라 동일한 파일을 기반으로 구축된 애플리케이션이 자동으로 디스크에서 파일을 공유하고 애플리케이션 및/또는 런타임이 설치되면 업데이트됩니다. 전체 다운로드가 필요하지 않습니다.

다소 순진한 부분이 있더라도 양해 바랍니다. 런타임 환경의 자연스러운 논리적 진행으로 데스크탑 환경을 구축할 가능성을 고려했는지 궁금합니다. 렌더러의 새 인스턴스를 생성하거나 재사용하여 다른 전자 앱을 시작할 수 있는 기능과 함께 시작 시 전자가 로드되는 시작 앱(예: atom 대신)이 있다는 아이디어입니다. 새 탭에서 앱이 열립니다.

내 이해에 OS에서와 같이 Chrome은 정확히 이것인 것 같습니다(그러나 웹 앱으로 제한됨). nodejs(chromeAPI의 제한 사항과 반대)를 통해 전체 fs 액세스 권한이 있는 데스크톱 앱을 Linux 상단의 런타임 환경으로 전자를 사용하는 것(또는 Windows의 초기 explorer.exe에서 교체하거나 최소한 증대)은 매우 흥미진진할 것입니다. 나는 이것이 실제로 런타임인 것을 로드한 다음 브라우저 엔진을 로드한 다음 앱을 호스팅하는 ChromeOS보다 더 깨끗한 솔루션이라고 생각합니다. 많은 혁신적인 전자 브라우저 프로젝트가 야생에 있습니다).

다시 말하지만, 이것이 고려되었는지 또는 이미 이것을 수행하는 프로젝트가 있는지 궁금합니다. 그렇지 않다면 요정이 주도권을 잡기 위해 Github 경영진의 귀에 한마디 해줄 수 있을까요????

추신: 여기서 제안하지 않은 한 가지는 OS.js(그 자체로 귀여운 작은 프로젝트)를 전자로 이식하지만 전자 앱을 위한 환경을 만드는 것입니다(OS.js에서 코드 재사용을 반대하지는 않겠지만).
PPS: 충분히 가치가 있다고 판단되거나 런타임 환경 문제에 주의를 산만하게 하는 경우 별도의 문제를 만들겠습니다.

내장된 런타임 환경이 Electron 앱을 훨씬 더 좋게 만들 것이라고 생각합니다. 나는 그것들을 포장하는 것이 파일을 압축하고 확장자의 이름을 asar 로 바꿔야 한다고 생각하지만, 그 아카이브에는 기본 런타임 폴더의 내용과 함께 asar 라는 두 개의 폴더가 있어야 합니다. 기본 구성을 덮어써야 하는 파일과 함께 enviroment 라고 합니다.

예를 들어 새 앱을 실행하면 임시 폴더에 필수 버전의 Electron을 복사하고 런타임( asar 폴더의 내용)을 기본 파일 위치로 이동하는 반면 선택적 enviroment 폴더는 ( 3개의 하위 폴더, windows , linux , macosx )에는 기본 폴더 위에 붙여넣어 내용을 덮어쓸 파일이 포함되어야 합니다.

이런 식으로, 우리는 앱에 대한 .asar 확장을 평가하기 위한 앱 또는 무언가만 필요하고 해당 앱이 다운로드한 Electron(아카이브) 버전이 있는 폴더에 액세스하고 임시 폴더에 복사(추출)합니다. , .asar 의 내용을 사용하여 필요한 것을 수정한 다음 해당 임시 폴더에서 Electron 인스턴스를 실행하고 임시 폴더를 강제로 삭제하기 위해 죽을 때까지 기다립니다. 우선, 지원되는 모든 운영 체제에서 사용자 지정 확장 기능이 있는 아카이브와 함께 작동하도록 기본 구성을 얻는 것만으로도 이미 가지고 있는 것보다 훨씬 더 많은 도약이 될 것입니다. 그 후, 현재 구성 설정을 유지할 세 번째 폴더 config 가 있는지 걱정할 수 있습니다. 기본 구성 설정을 위해 그 안에 _config 폴더가 있을 수 있습니다(필요한 경우 ).

Chrome 패키지 앱이 곧 단계적으로 중단됨에 따라 사람들은 대안을 찾게 될 것입니다. 런타임은 항상 빌드/릴리스를 사용할 수 없는 소규모 프로젝트에 적합합니다. 앱은 Chrome 앱과 마찬가지로 웹 기술로 만들어지기 때문에 사용자가 단순히 소스에서 앱을 실행하는 것이 유용할 것입니다. 사용자가 실행할 수 있는 유일한 방법이 각 개별 스크립트 또는 앱에 대한 대규모 바이너리 릴리스를 다운로드하고 사용자가 최신 커밋을 빌드하거나 Electron을 다운로드하지 않고는 최신 커밋을 실행할 수 없는 경우 수많은 사소한 프로젝트를 Electron으로 이식하는 것을 정당화할 수 없습니다. IDE 자체.

안녕하세요. 제가 JS 중심의 세계에 있지 않더라도 최근에 _Electron_(이는 우연히 알게 되었지만 개발에는 사용하지 않음)과 매우 유사한 아이디어를 가지고 있었지만 더 많은 청중을 대상으로 했습니다. 아주 간단한 방법으로 말하자면: _웹 기술을 GUI로 제한하고 API를 제공하십시오._

따라서 의미론적 버전의 공유 라이브러리/런타임(_Blink_, _Skia_ 등을 기반으로 구축됨, 아마도 – "modern" – _C++_에 있음)을 계속 사용하고 개발자가 바인딩을 사용하여 언어를 선택하게 하십시오…
예를 들어 _JS_를 원하면 _Node.JS_를 사용하십시오. _C++_을(를) 원합니다. 문제 없습니다. 표준 _CPython_을 사용하면 _Python_이 가능해야 합니다. 다른 것? _SWIG_이(가) 도움이 될 수 있습니다. (거의) 어떤 경우에도 우리가 이깁니다.

공유(OS 종속) 라이브러리/런타임이 있으면 주요 문제를 해결하고 나머지를 제공하는 것이 가장 좋다고 생각하는 방법을 자세히 설명할 수 있습니다(나머지 사용자를 위한 GUI 프로그래밍 방식을 혁신/현대화하는 것 제외). 큰 진전!).

따라서 시작점은 _Electron_ 프로젝트의 "분할"이어야 합니다(물리 관련 이름도 있어야 합니다. 정말 신경 쓰는 것 같다는 사실을 감안할 때). :)

우리는 심지어 Electron에 대한 애드온을 완성할 수 없지만 많은 광고가 없다면 그렇게 많은 성공을 거두지 못할 것이라고 생각합니다.

@dezzeus 이전에 이 라인에 대한 노력이 있었습니다. 침해 브라우저 를 호스팅하기 위한 추력 런타임 을 살펴보십시오.

나는 이 방향에서 더 많은 추진력을 보고 싶기 때문에 이 길고 매혹적인 스레드를 두 번 읽었습니다. 다음은 @zcbenz 의 마지막 진술입니다. 여전히 관련성이 있다고 생각합니다.

이를 구현하는 데 기술적 장애물은 없으며 모든 것이 Electron 앱 자체일 수 있습니다. 그러나 문제는 모든 세부 사항을 고려하여 어느 쪽도 구현하기가 쉽지 않다는 것입니다. _소규모 팀이 풀타임으로 작업해야 한다고 생각합니다. 실현될지는 모르겠습니다.

(추가 강조) - 내가 해석하는 방법은 솔루션이 구축될 예정이라면 커뮤니티의 노력 및/또는 GitHub 및 이해 관계가 있는 기타 조직의 비즈니스 요구 사항에 달려 있다는 것입니다.

@yan-foto의 간결한 개요 는 명확한 목표/요구사항이 있는 합리적인 접근 계획처럼 보입니다. @iamale 의 lepton이라는 참조 구현/프로토타입이 있으며 Electron을 대상으로 하는 "범용 런타임 버전 관리자"를 제안합니다. @jorangreef가 차등 업데이트, 중복 제거(두 가지가 동일한지 확실하지 않음) 및 압축을 사용하여 "semver 자동 업데이트 메커니즘을 사용하는 프로덕션 중인 앱"에 대해 설명하면서 @jorangreef 의 의견 은 흥미로웠습니다. 그가 설명한 많은 기능은 적응/채택에 완벽해 보였습니다.

이것들은 탐색과 진보의 확실한 단계이며, 이 과정에서 생산 가치가 있는 일반 솔루션이 탄생할 것이라는 희망을 줍니다.

여전히 인간에 대한 믿음을 가진 사람들이 있다는 것이 좋습니다.

이것이 제품이 되는 것을 막는 유일한 것은 이 제품(컨셉)을 만들면서 열리는 즉각적인 비즈니스 기회가 없다는 것입니다.

@eliot-akira 네, 그렇습니다. 내가 작성한 코드는 파일 내에서 몇 바이트만 변경될 때 다운로드를 최소화하기 위해 파일 내에서 파일별 콘텐츠 기반 중복 제거(가변 크기 청크)를 수행합니다. 또한 버전 간에 변경되는 파일만 업데이트하고 애플리케이션 전체에 대한 업데이트는 오류에 직면하여 원자적입니다. 새 버전이 시작되거나 이전 버전이 그대로 유지됩니다.

코드를 오픈 소스화하고 싶고, 전체적인 아이디어를 위해 아직 코딩해야 할 몇 가지 사항이 있습니다. 여러 Electron 앱이 단일 자동 업데이트 감독자 프로세스를 공유할 수 있다면 좋을 것입니다(여러 독립 Electron 앱에서 중복 제거를 위한 로컬 공유 불변 캐시 사용).

이 전체 접근 방식의 목표는 Electron 앱을 설치 및 업데이트하는 데 필요한 전체 다운로드 대역폭을 최소화하는 동시에 Electron 앱을 서로 완전히 격리하는 것입니다(여러 앱에는 자체 Electron 바이너리가 있음). 비목표는 디스크 공간을 최소화하는 것입니다.

첫 번째 Electron 앱 설치는 전체를 다운로드해야 하지만 이후의 Electron 앱 설치는 로컬 공유 불변 캐시의 이점을 누릴 수 있습니다.

자동 업데이트가 되었기 때문에 버전 관리 문제와 여러 버전 관리 시스템이 버전 관리에 서로 다른 자릿수를 사용하는 것 같다는 사실을 가져와야 합니다. 저는 일단 명시적 버전 관리 를 사용하고 있습니다.

여기에 업데이트해야 하는 두 가지 유형이 있습니다.

• Electron 버전 관리 를 사용하는 Electron 자체 및
• 일반적으로 API가 없기 때문에 SemVer 또는 기타에 대해 신경 쓸 필요가 없는 앱(어떤 종류의 애드온 시스템을 사용하지 않는 한).

여러 버전 시스템을 지원해야 하는 경우 package.json "breakingVersionComponents": 1 및 명시적 버전 또는 Electron 버전의 경우 2 와 같은 일부 설정이 있을 수 있습니다.

(또 다른 옵션은 버전에 다른 구분 기호를 추가하는 것입니다 1.3:3.7 는 깨지는 부분과 깨지지 않는 부분을 구분합니다. 그러면 Semver는 x:y.z 및 Electron Versioning x.y:z 됩니다. 하지만 모든 단일 도구를 깨뜨릴 수 있다고 생각합니다.)

@jorangreef 모든 앱에 여전히 자체 Electron 바이너리가 있는 경우 여러 Electron 앱을 열 때 과도한 RAM 사용 문제가 해결되지 않습니다.

내가 간과했던 @joshuawarner32 의 오래된 댓글 을 발견했습니다. 그는 아직 범용 솔루션이 아닌 이미 작동 중인 예를 언급하지만 요약은 다음과 같습니다.

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

@jorangreef 의 예와 함께(추가 설명 감사합니다 - 편집: 오, 각 앱에 내가 생각했던 것과 다른 모델인 자체 Electron 바이너리가 있다는 것을 몰랐습니다), 사람들이 이미 공유 런타임 문제에 대한 고유한 솔루션 - 일종의 앱 실행기/관리자 기능도 제공합니다. 언급된 이러한 기능 중 일부를 범용 모듈로 분류하기 위해 일부 수렴을 보는 것이 좋습니다.

런타임 서버, 버전 관리, 차등 업데이트와 같은 다운로드 메커니즘과 같이 활용할 수 있는 기존의 Electron 관련이 아닌 모듈이 있는지 궁금합니다. 다른 사람들이 이미 이러한 영역 중 일부를 "해결"한 경우 처음부터 모든 것을 구축하는 것은 약간 벅차게 보입니다. @iamale , Lepton 에 대한 작업에 감사드립니다. 제 눈에는 이것이 솔루션 방향의 구체적인 구현입니다.

또 다른 아이디어는 npm에 앱을 게시하고 앱을 설치하고 실행할 수 있는 특별한 npm 래퍼를 만드는 것입니다. 그러면 배포하기가 정말 쉬울 것이고 아마도 사용하기도 쉬울 것입니다(래퍼의 품질에 따라 다름). 여러분은 어떻게 생각하세요?

oss 프로젝트의 경우 npm을 호스팅으로 사용할 수 있고, 비공개 소스의 경우 패키지 관리자가 다운로드할 .asar 파일과 추가 메타데이터를 가리킬 수 있어야 합니다. 문제는 이런 종류의 관리자가 어떻게 생겼는지(그리고 부름)입니다.

또한 앱을 설치하기 위해 별도의 명령이 정말로 필요한지 궁금합니다.
electron install atom 충분할까요?

Node Weekly에서 이것을 보았습니다.

Electrino는 인기 있고 강력한 Electron의 실험적인 페더급 대안입니다. Electron에서 사용 가능한 API의 아주 작은 부분을 구현하지만 출력 앱 크기는 훨씬 작습니다.

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

https://github.com/pojala/electrino

@YurySolovyov 비공개 소스 프로젝트는 npm으로 게시하는 데 문제가 없어야 합니다. 이미 몇 가지 Node.js 프로젝트가 있습니다. 즉, enclose . (기술적으로, 그것은 npm이 아니라 로더일 뿐입니다. 하지만 어쨌든 나는 .asar를 사이드로딩하는 것이 여전히 압축을 풀 수 있기 때문에 어떻게 도움이 될지 알 수 없습니다.)

어떻게 하면 기존 생태계를 최대한 재사용할 수 있을까 하는 생각이 들었습니다.

우리가 원하는지 확실하지 않습니다 ...

@jorangreef 모든 앱에 여전히 자체 Electron 바이너리가 있는 경우 여러 Electron 앱을 열 때 과도한 RAM 사용 문제가 해결되지 않습니다.

@Jop-V 아니요, 그렇지 않습니다. 나는 물건을 합성하고 괴물로 끝나는 것을 원하지 않습니다. 아이디어는 이 문제를 연 댓글에서 대부분의 문제를 해결하는 훌륭한 설치 프로그램/자동 업데이트 프로그램을 사용하는 것입니다. https://github.com/electron/electron/issues/673#issue -44580957

문제는 디스크에 여러 바이너리가 있는 것이 아니라 동일한 바이너리의 여러 복사본을 다운로드하고 자동 업데이트해야 하는 사용자에 대한 네트워크 영향입니다.

메모리 사용량을 해결하는 것은 확실히 가치가 있습니다. 다양한 방법이 있다고 생각하지만 중복 제거 설치 프로그램/자동 업데이트 프로그램과 함께 번들로 제공할 필요는 없습니다.

디스크 공간도 문제인 경우 이를 지원하는 시스템의 하드 링크를 통해 해결할 수 있지만, 이는 앱 간의 격리 개념을 침해하기 시작할 수 있습니다(예: 한 앱이 다른 것과 공유되는 하드 링크에 쓰기로 결정한 경우).

또는 적어도 중기적으로 macOS에서 APFS는 내부에서 투명한 중복 제거를 통해 참조로 파일을 복사하여 디스크 공간을 최소화합니다. 이것은 격리를 그대로 유지하기 때문에 하드링크보다 나을 것입니다(기록 중 복사).

@jorangreef 앱에 별도의 Electron 바이너리를 사용하는 이유는 무엇입니까? 어떤 고립을 말씀하시는 건가요? 어리석은 질문이라면 죄송하지만 이해가 되지 않습니다.

@iamale 일부 앱은 다른 공식 버전의 Electron을 대상으로 하거나 수정된 ​​소스에서 컴파일된 미리 빌드된 Electron을 배포할 수 있습니다. 이 접근 방식은 그들 모두와 함께 작동합니다. 바이너리의 주요 차이점(JS 및 자산 변경과 반대)이 있더라도 중복 제거는 다운로드 요구 사항의 70% 이상을 제거하므로 다른 바이너리를 대상으로 하는 앱은 여전히 ​​이점을 누릴 수 있습니다.

이 접근 방식을 사용하면 Electron 앱뿐만 아니라 모든 종류의 패키지(JSON 매니페스트에 의해 정의된 모든 파일 및 디렉토리 세트)를 배송할 수도 있습니다. Python 앱일 수도 있습니다. 개발자가 앱을 구성하거나 패키징하는 방법(파일 대 asar 등)에 대해 선택하려는 모든 선택에 불가지론적입니다.

주요 아이디어는 더 많은 앱이 동일한 설치 프로그램/자동 업데이트 프로그램을 사용함에 따라 생태계가 매우 작은 설치/업데이트 델타의 이점을 누릴 수 있다는 것입니다. 오늘날 모든 앱은 자체 감독 자동 업데이트 프로그램을 실행하고 있으며 필요하지 않습니다.

@jorangreef 감사합니다! 나는 그것이 고전적인 APT/RPM 리포지토리와 매우 흡사하다고 생각합니다. 단지 더 "스마트"합니다(종속성 등을 선언할 필요가 없음).

문제는 이런 종류의 관리자가 어떻게 생겼는지(그리고 부름)입니다.

Minifitron (소형 전자)는 어떻습니까?

아카이브 파일(예: .asar )에는 전자의 바이너리가 있는 폴더의 내용이 포함되어야 하므로 표준에서 벗어난 파일을 추가하거나 교체할 수 있습니다. 폴더 또는 아카이브에 각 버전이 있고 실행되는 동안 새 임시 폴더에 복사합니다.

앱을 설치하거나 축소할 수 있는 옵션이 있어야 합니다. 설치 시 해당 앱을 전자의 새 인스턴스로 남겨두는 반면, 축소된 앱은 md5를 사용하여 .asar 의 아카이브 해제로 변경되지 않은 파일을 삭제합니다.

다른 생각을 하자면: 각 Electron 앱에 자체 런타임 복사본 이 포함되어 있지만 실행 시 이미 실행 중인 Electron 인스턴스(및 해당 버전)가 있는지 확인할 수 있다면 - 호환 가능한 경우(semver 범위 내) 등), 앱은 앱과 통신하고 동일한 인스턴스를 사용할 수 있습니다. 호환되지 않는 경우 앱은 자체 Electron 인스턴스를 시작할 수 있습니다. 메모리 사용량을 줄이는 문제를 해결하는 것 같습니다.

(그런 다음 다시, 앱이 실행될 즈음에는 어쨌든 런타임의 여러 인스턴스가 이미 있을 것이라고 생각합니다. 그래서 논리적이지 않을 수 있습니다..)

@eliot-akira 이 스레드를 읽는 동안 매우 비슷한 생각을 했습니다.

(그런 다음 다시, 앱이 실행될 즈음에는 어쨌든 런타임의 여러 인스턴스가 이미 있을 것이라고 생각합니다. 그래서 논리적이지 않을 수 있습니다..)

글쎄, 그것은 이것을 확인하기에 충분할 만큼만 로드할 수 있고, 런타임을 공유할 사용 가능한 "전자 메이트"가 없는 것을 확인한 후 나머지를 로드합니다.

이것은 많은 보안 문제를 야기할 것입니다. 악의적인 앱은 수정된 버전의 런타임을 다른 사용자에게 제공하고 해당 데이터에 액세스할 수 있습니다. 공유 메모리 세그먼트를 사용하여 읽기 전용으로 만들 수 있으며 "사용자" 앱(이전에 실행된 앱의 런타임을 사용하는)이 런타임을 체크섬할 수 있지만 모든 대상 OS에 대해 이를 개발하는 것은 악몽일 수 있습니다( 나는 이것이 Windows에 존재하는지조차 모릅니다; 나는 그것이 있어야 한다고 가정합니다).

단지 호기심을 위한 것이라면 말이 안 되는 것입니까? 별도의 공유 런타임보다 많거나 훨씬 더 많은 작업이 필요합니까? 다른 추가 문제가 발생합니까?

나중에 추가됨: 이것은 먼 이야기일 수 있지만 RAM에서 동일한 페이지를 중복 제거하는 기술이 있습니다. 가상화 환경과 하이퍼바이저에서 주로 사용됩니다. 이것이 내가 오늘날의 OS가 이것을 사용하는지 확인하기 위해 내가 생각하고 실행한 첫 번째 것입니다. 그러면 이 기능을 이용할 수 있는 방식으로 전자를 설정하는 방법이 있을 수 있지만 분명히 그렇지는 않습니다.

@jorangreef 개발자가 Electron 바이너리를 수정했다면 풀 리퀘스트를 생성해야 하지 않을까요?

@Jop-V 그들은 할 수 있지만 자신의 포크도 유지할 수 있습니다. 그들은 원하지 않는 경우 소스를 공개하지 않을 수도 있습니다. MIT 라이선스는 이에 대한 의무를 부과하지 않습니다.

@jkurei 아이디어를 더 탐구하기 위해 작동할 수 있는 몇 가지 방법을 상상합니다.

1) Electron 또는 앱 자체를 둘러싼 얇은 기본 래퍼("런처"). 이미 실행 중인 Electron 인스턴스와 해당 버전을 확인합니다. 호환되는 경우 나머지 시작 프로세스를 해당 인스턴스로 넘기고 종료합니다. 그렇지 않은 경우 Electron의 자체 인스턴스를 계속 시작하십시오.

2) 앱 자체가 런처로 메인 프로세스로 가져올 수 있는 JavaScript 라이브러리. 위와 유사한 프로토콜을 구현할 수 있습니다. Electron 인스턴스의 존재를 브로드캐스트하고 다른 앱(동일한 라이브러리 사용)이 이를 찾고 통신할 수 있는 방법 - 아마도 네트워크 포트를 통해 ..?

@eliot-akira 그건 그렇고, 당신이 말하는 일종의 원시적인 "프로토콜"이 이미 있다고 생각합니다. app.makeSingleInstance 뒤에 있는 것은 이미 실행 중인 Electron 프로세스와 동일한 앱인지 아닌지(아마도 전체 실행 경로를 가져옴) 감지하는 것입니다.

@iamale 이 메서드는 Chromium의 기본 ProcessSingleton 클래스를 사용하여 현재 앱 디렉터리(고유 식별자로?)를 등록합니다. 예, app.on('ready') 전에 초기화되는 이와 같은 것을 그리고 있었습니다. 따라서 해당 특정 앱의 기존 인스턴스를 확인하는 대신 Electron의 모든 인스턴스를 확인할 수 있습니다. 그런 다음 호환되는 경우 "실행 프로세스를 넘겨줍니다".

다른 각도에서는 별도의 Node.js 프로세스 간에 통신할 수 있는 node-ipc 라는 모듈을 찾았습니다. 순전히 JS 레이어에서 시작 프로세스를 관리하는 데 사용할 수 있습니다.

다음은 프로세스 간 통신에 node-ipc 를 사용하여 여러 앱 간에 단일 Electron 인스턴스를 공유하는 기본 예입니다. https://github.com/eliot-akira/singletron-example.

IPC 허브는 node-ipc 주위의 얇은 래퍼인 자체 모듈 입니다. 초기화는 메인 프로세스, main.js 맨 아래에 있습니다.

앱이 시작되면 먼저 기존 Electron 인스턴스와 연결을 시도합니다. 없는 경우 프로세스 간 요청을 수신하는 "서버"를 시작합니다. 앱의 모든 후속 인스턴스는 첫 번째 인스턴스와 연결되고 해당 "구성"(Chrome, Node, Electron 버전)을 수신하고 예를 들어 자체적으로 새 창을 요청하기 위해 메시지를 교환할 수 있습니다.

처음에는 순진한 구현이지만 이 접근 방식에서 내가 좋아하는 것은 서버/클라이언트가 협상해야 하는 방법(호환성 확인, 새 창 열기 여부, 다른 구성 전달 등)을 처리하는 것은 앱에 달려 있다는 것입니다.

@eliot-akira 이 시점에서 기본 서버 ID를 지정하는 것은 _정말로-정말-나쁜_ 생각이라고 생각합니다. 누군가 자신의 목적으로 이것을 사용하기 시작하면 자신의 필요에 맞게 예제 코드를 수정하고 프로토콜을 중단할 가능성이 높습니다( 따라서 이에 의존하는 다른 앱을 중단).

그 외에는 깨끗하고 좋아 보입니다. 감사합니다!

Re: 보안 문제: Electron 앱은 이미 사용자 권한으로 실행 중이며 하나의 프로세스 트리에 배치하면 실제로 다른 Electron 인스턴스에 액세스할 수 있습니다(또는 얻을 수 있음). 그러나 우리가 그것을 완화하려는 경우 패치된 Electron 인스턴스를 제공할 수 있는 모든 사람이 확실히 도움이 되지 않을 것이라고 생각합니다.

@iamale 피드백 감사합니다. 일부 앱이 모든 Electron 앱에 대한 공통 프로토콜이 아닌 자체 프로토콜을 구현하려는 경우에 대비하여 서버 ID를 설정하는 옵션을 노출했습니다. 사실, 아직까지는 그러한 공통 프로토콜이 없습니다. 따라서 이 시점에서 알 수 없는 앱이 연결되어 실행 프로세스를 넘겨주는 것은 그러한 목적에 실용적이지 않습니다. 이는 개념 증명을 위한 것이므로 이를 언급하도록 문서를 업데이트하겠습니다. 어떻게 하면 더 실용적으로 만들 수 있을지 계속 연구하겠습니다.

새로 오시는 분들이 반년 전에 했던 것과 같은 요약을 다시 하면 도움이 될 것 같아요.

또한 최종 사용자는 무엇을 합니까?

내가 최종 사용자라면 (부분적으로는 ofc입니다) Portableapps.net 설치 프로그램과 유사한 방식으로 작동하는 단일 .exe/.app/.deb 패키지를 원할 것입니다. 해당 exe 파일은 작아야 하며 설치되지 않은 경우 런타임과 함께 소프트웨어의 최신 업스트림 버전을 자동으로 다운로드해야 합니다. 간단한 설정 과정에서 시스템 링크(데스크톱, 시작 메뉴 등)를 만들기 위한 확인란과 함께 "런타임 위치"(고급 옵션 확인란 사용)를 수동으로 설정할 수 있어야 합니다.

다음 소프트웨어를 다운로드할 때 가능한 경우 이전 런타임(idc가 무엇이든 간에)을 재사용해야 합니다.

개발자로서 (기껏해야) 한 번의 클릭으로 다운로드 가능한 패키지를 만들 수 있기를 원합니다. 이 한 번의 클릭으로 내 코드를 일부 저장소(play/web/app 스토어와 유사)에 업로드하고 전 세계와 공유할 수 있는 .exe/.app/.deb 패키지를 생성해야 합니다.

저는 C#용 Electron 및 Electron-Edge를 사용하여 작은 모드 설치 프로그램을 만들고 있기 때문에 아직 Electron과 관련이 없습니다.

내가 순진할 수도 있지만, +-0.1 버전과 호환되지 않는 유일한 "진짜" 이유는 .node 파일이 모든 버전의 Electron에 대해 다시 작성되어야 한다는 것입니다. 일종의 클라우드 솔루션을 사용하여 설정하는 동안 이러한 .node 파일을 빌드할 수 없습니까?

또한 반년마다 하나의 큰 Electron LTS를 만드는 것이 정말 그렇게 큰 일입니까? 저는 개발자들이 모든 새로운 Electron 릴리스의 모든 최신 기능을 실제로 사용하고 있는지 의심스럽습니다. 따라서 (일종의) 한 버전을 더 오래 사용하도록 강제하면 일이 훨씬 쉬워질 것입니다.

Imo, 유일한 문제는 모든 사람이 의지할 수 있는 LTS 버전의 Electron이 준비되어 있지 않다는 것입니다.

그 lts 버전을 사용하면 빌드 자동 업데이트, 중복 제거, 버전 관리 및 기타 모든 작업이 케이크 조각이 되어야 합니다.

내가 제안한 설치 프로그램 솔루션에는 사용자가 실제로 소프트웨어의 폴더를 볼 수 없다는 추가 이점이 있으므로 .whatever로 패키지하고 안전한 곳으로 옮기라고 말할 필요가 없습니다. 또한 설치하는 동안 여러 "하위 실행 파일"을 추가할 수 있습니다(예: 멀티플레이어 게임, 여러 "프로필" 등). 이러한 실행 파일은 somelaunchername.electron이라고 해야 하지만 소프트웨어를 시작하는 방법에 대한 정보(예: 로드할 index.html 등)에 대한 정보가 포함된 Json 형식이어야 합니다. node_modules는 실행 파일 간에 공유되어야 합니다(개발자가 각 실행 파일에 대해 다른 버전의 모듈을 사용해야 하는 경우 제외). 이것은 세 개의 node_modules 폴더를 사용하여 달성할 수 있습니다. 각 실행 파일에 대해 하나씩, 둘 다에 대해 하나씩. package.json에는 일반 정보만 있을 것입니다. 각 .electron 파일은 (imo) package.json의 값을 덮어쓸 수 있어야 합니다.

이러한 .electron 파일은 "runtime --appname" 또는 steam과 같은 사용자 지정 프로토콜을 사용하여 시작 메뉴 및 기타 위치에 추가할 수 있습니다. 어느 것이 더 나은지 확실하지 않지만 과거에는 스팀이 몇 번이나 저를 화나게 했습니다.

이제 개발자가 실제로 수정된 런타임을 제공하려는 경우 현재 수행되는 방식으로 계속 패키징할 수 있습니다.

결론적으로:
제 생각에 다음 단계는 안정적인 lts 버전을 만들고 개발자에게 쉬운 패키징 솔루션을 제공하여 개발자를 참여시키는 것입니다. 설치 프로세스는 나중에 개선할 수 있습니다. 현재는 이러한 .electron 파일에 대한 런타임과 실행 프로그램을 다운로드하는 것으로 충분합니다.

여러분은 어떻게 생각하세요?

@CiriousJoker 전자 빌더는 휴대용 앱과 웹 설치 프로그램을 만들 수 있습니다. 내가 아는 한 Windows 공유 DLL 이 솔루션입니다. Shared DLL은 또한 사용하지 않는 전자 런타임을 자동으로 제거하기 위해 참조 카운팅을 지원합니다. 현재, 하나의 큰 exe(node.dll 제외)의 Windows에서 전자 런타임. dll로 나눌 수 있다면 전자 빌더 측 솔루션은 구현하기가 매우 쉽습니다. 디스크 공간뿐만 아니라 메모리도 절약됩니다.

@zcbenz @paulcbetts 공유 dll 사용을 고려하셨습니까? exe의 크기를 줄이고 모든 전자 코드를 dll로 이동할 수 있습니까(따라서 exe에는 최소한의 코드만 유지)? 전자 1.7.5 이후 공유 C 런타임이 node.dll 및 exe에서 제거된 것이 좋습니다. 이제 30MB의 코드가 이미 DLL 파일에 있으므로(하지만 exe는 여전히 80MB임) 실험을 시작할 수 있습니다.

@develar imo, 진짜 문제는 dll을 공유하는 방법이 아니라 lts 버전의 전자를 얻는 방법입니다.

Chromium은 이전 버전에 대한 보안 수정도 수행합니까? 나는 그들의 정책이 "보안을 위해 최신 버전으로 업그레이드"한다는 것을 강하게 느낍니다. Chromium의 보안 업데이트가 없으면 Electron의 LTS는 먼 이야기처럼 보입니다.

@sedwards2009 근데 정말 위협이 그렇게 많나요? 물론 여기에서 내가 순진할 수도 있지만 우리는 개방형 인터넷이 아닌 (대부분) 로컬 앱으로부터 사용자를 보호하고 있습니다. .exe 파일을 실행하는 것은 10000배 더 위험하고 .exe 바이러스를 작성하는 것도 AVG에서 내 합법적인 전자 앱 설치 프로그램을 바이러스라고 불렀을 때 10000배 더 쉽습니다.

그래서 나에게는 6개월 정도마다 해당 보안을 "갱신"하면 충분합니다. 또한 모든 개발자가 자체 패키지 버전의 크롬을 사용하도록 하는 것이 더 안전하지 않은 방법으로, 어쨌든 우리가 막을 수 없는 더 나쁜 일을 할 수 있습니다(공유 런타임 또는 기타 사용)

예, 앱이 fs 및 네트워킹에 대한 원시 액세스 권한을 얻는 곳에서 보안이 종료됩니다.
앱 공급업체를 신뢰하거나 멀리하십시오. <- 폐쇄 소스 앱용입니다.
OSS의 경우 대부분이 적어도 나쁜 의도는 없지만 버그가 포함될 수 있습니다.

자, 그럼 lts 버전을 얻는 것이 얼마나 쉽습니까? 현재 버전을 선택하고 lts 버전으로 선언할 수 없었습니까?

더 큰 문제는 나중에 개발자가 이 특정 버전용 앱을 빌드하도록 설득할 때 나타날 수 있지만 어쨌든 마지막 단계입니다. 공유 런타임을 빌드하려면 먼저 런타임을 선택하기만 하면 됩니다.

어떤 런타임 버전 앱이 작동해야 하는지 파악하는 것은 개발자의 결정이라고 말하고 싶습니다.
npm 엔진 필드 와 같은 종류입니다.
여기서 런타임의 작업은 필요한 dll 또는 무엇이든 가져와서 앱이 실행되도록 하는 것입니다.

그러나 호환되지 않는 수십 개의 거의 동일한 런타임 중 하나를 선택하도록 허용하면 요점을 완전히 놓치게 되지 않습니까? 단순히 중복을 제거하는 것이 아니라 여러 런타임을 사용하지 않으려고 합니다. 누군가 처음에 언급했듯이 동일한 런타임이 동일한 시스템에서 다시 사용될 가능성이 20분의 1인 경우 런타임 중복 제거는 의미가 없습니다.

아니면 대부분의 런타임을 공유하고 필요에 따라 다른 부분으로 전환한다는 의미입니까? 이해가 되지만 구현하기 어렵다고 생각합니다.

런타임을 공유할 수 있는 방법을 알 수 없습니다. 주요 크기 소비자는 Chromium과 Node이며 밀접하게 통합되어 있으며 둘 이상의 버전에서 서로 작동하도록 만들 수 있는지 의심됩니다.

노드에는 다음과 같은 것이 있다고 생각합니다.

• 일부 개발자는 최신 v8을 원했고 파손을 용인했습니다.
• 대기업은 안정성과 장기적인 지원을 원했습니다.

전자 팀이 두 가지를 모두 지원할 수 있는 충분한 리소스가 있는지 확실하지 않지만 제가 틀릴 수 있습니다.
어쨌든 이것은 버전 지정 범위와 충돌하지 않으며 어떤 버전이 "LTS"인지 나타내기만 하면 됩니다.

모든 전자 앱이 동일한 런타임을 사용하고 해당 런타임을 위해 특별히 빌드된 .asar 패키지와 함께 제공된다면 문제가 해결되지 않을까요?

네, 하지만 가끔은 최신 Chrome과 Node를 원하시죠?

예, 하지만 6개월 동안 동일한 노드/크롬을 사용하면서 살 수 있습니다. Node에는 어쨌든 LTS 버전이 있으며 크롬은 내가 알아차린 것과 크게 다르지 않습니다. Imo, 모든 앱 설치 시 100MB를 절약할 수 있는 이점은 Chromium/Electron의 새 버전이 출시될 때마다 약간의 속도 향상을 보완합니다. 또한 일단 개발자가 참여하면 새 버전의 런타임 사이의 시간을 줄이는 것이 너무 어렵지 않아야 합니다. 그런 다음 최신 버전의 런타임과 하나 또는 두 개의 이전 버전을 지원할 수 있습니다.

6개월마다 .node 파일을 다시 빌드하는 것도 그렇게 어렵지 않아야 합니다.

Electron-builder는 모든 nsis 대상에 대한 새로운 옵션인 useSharedElectronRuntime을 지원합니다. 현재로서는 기존의 모든 dll이 될 것입니다. exe의 크기를 줄이고 코드를 dll로 옮기는 것이 가능하다고 생각하지만 나중에 할 수 있으므로 30Mb를 절약하는 것이 이미 좋은 목표입니다.

1. 모든 전자 dll에 대해 서명된 어셈블리를 만들고 GitHub 릴리스에 게시합니다(bintray는 신뢰할 수 없기 때문에 옵션이 아닙니다).
2. Nsis 설치 프로그램은 아직 설치되지 않은 경우 어셈블리를 다운로드하여 설치합니다. 보안 — 어셈블리가 서명되었습니다. Electron-builder는 기계당 설치도 지원합니다. 그리고 Windows는 시스템별로 어셈블리를 설치하는 경우 추가 보안 수준을 제공하므로 필요한 경우 활성화할 수 있습니다. 어떤 경우에도 기계당 조립품을 설치하기 위한 추가 옵션이 추가됩니다. 아직 명확하지 않음 — 기본적으로 true 또는 false여야 합니다. 기본적으로 전자 앱을 관리자 없이 설치할 수 있도록 하기 위해 거짓이라고 생각합니다.
3. 사용하지 않는 전자 런타임에 대해 걱정할 필요가 없습니다. 공유 dll은 참조 카운팅을 지원합니다. 앱 제거 시 어셈블리가 제거되고 다른 앱에서 더 이상 사용하지 않는 경우 Windows에서 제거합니다.

@CiriousJoker Re: 보안. 응용 프로그램 자체가 악의적 인 보안 문제는 생각하지 않았습니다. 신뢰할 수 없는 콘텐츠를 빨아들이고 사용하는 전자 앱을 생각하고 있었습니다. 즉, 전자 앱이 열린 웹의 웹 페이지를 webview 또는 이와 유사한 형식으로 표시할 때마다.

많은 앱이 개방형 웹에 노출되지 않으며 이전 전자에서 잘 실행될 것입니다. 그러나 다른 극단은 웹 브라우저로서 자신을 노출시키는 것 외에는 아무것도 하지 않는 Brave와 같은 것입니다. :-)

@sedwards2009 ye, 하지만 우리가 모든 사람과 그들의 엄마를 돌보기 시작한다면 우리는 아무 진전도 없을 것입니다. 뭔가를 하지 않는 데에는 항상 이유가 있습니다. 개발자를 100% 참여시키지 못하는 것은 우리가 치러야 할 희생일 뿐입니다. 보안이 정말로 필요하거나 원하는 경우 수동으로 가질 수 있습니다.

LTS를 선택하는 것과 관련하여 가장 합리적인 선택은 Nodejs LTS에 바인딩하는 것입니다. 즉, 노드 LTS에 해당하는 전자 버전이 사실상 전자 LTS입니다. 이것은 우리가 집단적으로 앞으로 나아갈 수 있고(이 커뮤니티를 부정하는) 자유로운 선택이나 논쟁(우리를 아무데도 이끌지 않음)으로 남겨두지 않고 어느 정도 확신을 가질 수 있도록 약간의 조화와 합의를 가져올 수 있습니다.

@CxRes 하지만 어떤 버전의 Electron을 지원합니까? 내 프로젝트에서 주요 문제는 특정 버전의 Electron(Node가 아님)에 대해 .node 파일을 다시 빌드하는 것이었습니다.

최신 Electron 버전을 lts로 설정하거나 가장 널리 사용되는 버전을 사용할 수 있습니다.

내가 여기에서 뭔가를 놓치고 있습니까? 아이고, 문제는 Node가 아니라 Electron입니다.

좋아요, 예를 들어 다시 설명하겠습니다.

• 노드 LTS는 현재 6.11.1에 있습니다.
• 따라서 우리는 <=6.11.1 >=6.0.0 조건을 충족하는 가장 높은 버전의 노드로 공식적으로 구축된 가장 높은 버전의 전자를 사용하기를 원합니다.
• 노드 6을 사용하여 구축된 전자의 최상위 버전은 노드 6.5.0으로 구축된 전자 1.4.15입니다.
• 따라서 전자 1.4.15는 전자 LTS를 분기하고 6.11.1로 다시 빌드합니다(새 Node v6 릴리스가 있을 때까지 계속).

노드 LTS가 v8로 이동하면(LTS는 짝수만 있음) 아직 출시되지 않은 전자로 함께 이동합니다. 이 전자는 노드 v8을 사용하여 구축되거나 전자 버전이 출시될 때까지 현재 LTS 포크에 남아 있습니다.

최신의 최고를 원하는 개발자는 어떻습니까?

@CxRes @CiriousJoker 여기서는 주제를 벗어나지 않도록 합시다. 다른 Electron 버전의 사용을 방해하는 기술적인 이유는 없습니다. 단편화는 어떤 경우에도 발생합니다(개발자가 1년 전에 앱을 출시하고 잊어버렸고 최근에 출시된 다른 개발자의 다른 앱이 다른 버전을 사용함).

@YurySolovyov LTS의 전체 아이디어는 최신이 아니라 가장 안정적이라는 것입니다. 그리고 우리가 하나의 솔루션에 집중하는 데 동의할 수 없다면, 어떤 그룹도 모든 버전을 다시 빌드하고 버그를 선별할 시간과 능력이 없기 때문에 런타임이 없는 Pareto 차선책으로 고통을 겪을 운명입니다.

또한 위의 @CiriousJoker 주석을 참조하십시오.

네, 하지만 우리가 모든 사람과 그들의 엄마를 돌보기 시작한다면 진전이 없을 것입니다.

@develar 알겠습니다 . 그러나 당신이 지적했듯이 이것은 기술적인 문제가 아니라 정치적인 문제입니다(부담이 공유되도록 일관되게 대부분의 사람들에게 작동하는 빌드에 동의하는 것).

이제 우리는 무엇을 합니까? lts 버전을 선택하고 시작하거나 모듈식 dll을 사용하여 만능 런타임을 구축하여 모든 사람이 사용할 수 있는 솔루션을 찾 습니까 ?

@CiriousJoker 특정 전자 버전에 대한 병렬 어셈블리. 예: ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar Google에서 전자런틴어셈블리를 찾을 수 없습니다. 링크나 smth를 제공할 수 있습니까?

Imo, 속도를 높이려면 임의의 Electron 버전을 lts 버전으로 선택하고 시작해야 합니다. 어쨌든 나중에 언제든지 버전을 변경할 수 있습니다.
@develar 여전히 병렬 어셈블리가 무엇을 의미하는지 모르지만 크로스 플랫폼에서 작동해야 하며 나중에 구현할 수도 있다고 생각합니다.

우리(또는 실제로 여러분)는 이 문제에 대해 몇 년 동안 이야기해 왔지만 아무도 시작하지 않으면 아무 것도 바뀌지 않을 것이며 아이디어를 논의하고 시작하지 않는 방법을 찾는 데 또 3년 동안 앉아 있을 것입니다.

전자 개발자들이 하루 빨리 실행 환경과 응용 프로그램의 분리를 해결하여 전자 응용 프로그램을 크게 촉진하고 밝은 미래를 볼 수 있기를 바랍니다.

그들은 나에게 몇 년처럼 보이는 동안 그것을 해결하지 않았기 때문에 나는 그것에 대해 약간 비관적입니다. 물론 굉장하겠지만 그들은 심지어 그것에 대해 적극적으로 일하고 있습니까?

@CiriousJoker 위에서 언급했듯이 저는 전자 빌더의 창에 대한 공유 전자 런타임 지원 작업을 하고 있습니다. 진행 상황을 추적하기 위해 https://github.com/electron-userland/electron-builder/issues/1942 를 제출했습니다. 1개월 안에 사용할 수 있기를 바랍니다.

@develar 내 나쁜, 그것을 간과했을 것입니다.. 그렇다면 행운을 빕니다, 당신이 그것을 만들 수 있다면 굉장할 것입니다!

https://github.com/electron/electron/issues/673#issuecomment -157980607의 스레드에서 앞서 언급한 하위 파일 content-defined-chunking 중복 제거에 관심이 있는 사람이 있는 경우 이를 오픈 소스로 지정했습니다: https:// github.com/ronomon/deduplication

이 긴 스레드는 지난 몇 달 동안 휴면 상태였지만 이 스레드가 해결하는 문제는 여전히 조사할 가치가 있다고 생각합니다. 주말 동안 나는 파일 이름을 대량으로 바꾸기 위한 작고 최소한의 한 페이지 유틸리티를 만들었습니다. 전자 빌더가 포함된 최종 Mac .app 파일은 121mb ...

나는 최근에 이 문제에 대해 생각하고 있었다. 그런 다음 내 스마트폰을 살펴보았습니다. Facebook 앱은 600MB 크기입니다. Chrome은 325MB, Mesenger는 300MB... 그래서 데스크톱의 120MB 앱은 별로 신경 쓰지 않습니다...

오늘날 크기는 문제가 되지 않습니다. 램과 소비전력입니다.

_편집: 동의하지 않는 경우 이유를 자유롭게 공유하세요_

Windows 플랫폼의 경우 @develar 의 electron-builder(electron-userland/electron-builder#1942) 노력은 공유 런타임 달성에 가까워 보입니다.

또한 웹 앱을 독립 실행형 Electron 앱으로 패키징하는 앱 웹 카탈로그가 앱 크기를 대폭 줄이기 위해 공유 런타임 사용 문제를 해결한 것으로 나타났습니다: webcatalog/webcatalog/issues/171. 앱 간에 공유 리소스를 심볼릭 링크 하여 패키지 프로그램에서 수행되었습니다.

프로그레시브 웹 응용 프로그램(PWA)은 이 문제에 대한 부분적인 솔루션입니다. Android에서는 PWA를 홈 화면에 추가할 수 있으며 실제 APK처럼 작동합니다. Chrome 팀은 현재 데스크톱에 PWA를 설치할 수 있도록 작업 중입니다(http://www.androidpolice.com/2017/12/05/google-want-progressive-web-apps-replace-chrome-apps/), Microsoft 또한 PWA 지원(https://www.windowscentral.com/faq-progressive-web-apps-windows-10)에 관심을 보이며 Firefox와 Safari가 곧 따라잡기를 바랍니다. 개발자가 관심을 보이면 누락된 API(예: 기본 파일 시스템 액세스)가 추가됩니다.
대부분의 웹 기반 Electron 애플리케이션은 PWA로 쉽게 변환할 수 있지만 Atom, VSCode와 같은 애플리케이션은 확실하지 않습니다. 네이티브 코드는 아마도 WebAssembly에서 다시 작성해야 할 것입니다.

@develar 는 이 아이디어에 대해 진전이 있습니까?

출시되면 사용하겠습니다!

최근에 이것을 발견하고 나는 단지 내 의견을 던지고 싶었습니다. 하지만 전체 문제를 읽지 않았기 때문에 나도 모르게 몇 가지를 반복할 수 있습니다.

Electron 프로그램의 크기가 지금은 그렇게 큰 문제가 아닌 것처럼 보일 수 있지만 사용자 정의 계산기와 같은 매우 간단하고 작은 프로그램을 배포할 때 실제로 보기 시작하므로 이와 같은 것이 매우 중요하다고 생각합니다. 이 경우 5-10MB 정도가 적당합니다. 60MB 이상이면 말도 안됩니다. 더 큰 프로그램의 경우 Electron 자체의 크기는 더 무시할 수 있지만 여전히 성가실 수 있습니다.

그러나 이제 이러한 런타임 모드에는 현재 릴리스 속도를 고려하여 일부 유형의 LTS 릴리스 시스템이 필요합니다. 그런 다음 개발자는 LTS 릴리스에 의존하도록 권장할 수 있으며 사용 중인 가장 일반적인 버전 목록을 앱 디렉토리에 표시하여 필수 기능이 부족한 경우가 아니면 가장 일반적인 버전을 사용하도록 권장할 수 있습니다.

런타임 모드 자체는 IMO에 다른 버전의 Electron 라이브러리를 설치하기 위한 내장 시스템도 있어야 하므로 사용자가 다른 버전이 필요한 애플리케이션을 설치하도록 요청하면 런타임 프로그램이 자동으로 다운로드할 수 있습니다. 설치 프로세스 내의 단계입니다.

Electron 앱의 RAM 사용량도 이를 통해 개선될 수 있지만, 이를 적용하는 데 필요한 변경 사항은 훨씬 더 중요할 수 있습니다. 공유 런타임을 사용하면 동일한 버전을 사용하는 Electron 앱이 메모리 내에서 일부 리소스를 공유할 수 있습니다.

어쨌든, 나는 어쨌든 Electron 프로젝트의 전체 소스에 대해 매우 새롭기 때문에 불분명한 것이 있거나 불필요하게 무언가를 반복했다면 죄송합니다. 그러나 이것이 구현되기를 진심으로 바랍니다. Electron이 훨씬 더 많은 유형의 프로그램을 위한 훨씬 더 유망한 플랫폼이 될 것이기 때문입니다. :+1:

@octacian PWA가 더 나은 옵션이라고 생각하기 시작했습니다. 보편적인 것은 아니지만 PWA를 사용하여 _모든 것을_ 할 수는 없지만 사용자 정의 계산기와 같은 경우에는 충분해야 합니다.

이제 데스크톱에서 PWA 지원 이 나타날 때까지 기다려야 합니다.

또한 이러한 시스템을 사용하면 1- 임베디드/소형 시스템으로 배송하는 것이 더 쉬울 것이고 2- 미래에는 모바일 장치용 전자 같은 운영 체제 기반이 만들어질 수 있다고 생각합니다.

@yasinaydin 이미 LG WebOS가 있습니다. (Firefox OS도 있었지만 단종됨)

@KeitIG ​​선생님, Electron의 유일한 문제가 크기라면 귀하의 주장은 절대적으로 적절할 것입니다. 약간 더 큰 프로그램을 가지지만 개발자를 위한 복잡성과 실패 가능성을 단순화하는 것(우리는 Electron이 개발자들에게 엉망이 될 여지 없이 앱을 구축하는 표준화된 방법을 제공하는 데 탁월하다는 것을 부정할 수 없습니다) 굉장할 것입니다. 아아, 각 앱에 대해 별도의 라이브러리 버전을 사용하면 RAM 사용량이 증가하고 보안 문제가 분산되고 수정하기 더 어려워집니다. 내 중복 문제 에서 이것을 더 잘 설명했지만 간단히 말해서 공유 런타임 라이브러리는 자체적으로 업데이트하고 다른 Electron 앱 간에 공유할 수 있다고 생각합니다("라이트" 버전도 제공됩니다. JVM에서 사용할 Java 파일을 배포하고 .exe 번들로 묶은 일부 개발자는 실제로 Electron의 거래 차단기이며 엄청난 작업량이 될 것이라는 것을 이해하지만 슬프게도 아직 개발자의 계획에 없다는 것입니다. 그들이 미래에 그것을 하기를 바랍니다.

@dre-hh 제안의 좋은 의도는 인정하지만 무엇보다도 지나치게 제한적입니다. 예를 들어, 저는 고용주를 위해 상업용 전자 앱을 개발했으며 고도로 규제된 환경(인터넷 연결 없음, 추적 가능성/감사 요구 사항 등)에서 사용됩니다. 고객은 소프트웨어 자동 업데이트와 같은 작업을 수행하도록 허용할 수 없습니다. 대중을 위한 일반적인 웹 앱과는 매우 다른 세상입니다. 에버그린 브라우저와 OS 보안 업데이트의 자동 설치는 대부분의 경우 대부분의 사람들에게 좋은 아이디어라고 생각합니다. 때로는 소프트웨어 변경으로 인한 중단의 위험이 특히 다른 보안 완화 기술이 있는 통제된 환경에서 오래된 버전의 소프트웨어를 실행하는 것과 관련된 위험보다 훨씬 더 큽니다. 따라서 오래된 버전의 전자(또는 실제로는 모든 라이브러리)를 사용하여 응용 프로그램 실행을 차단하는 것과 같은 극단적인 조치를 취하는 것은 이상적인 솔루션이 아닙니다. (게다가 관리자는 이미 실행할 수 있는 프로그램을 제한하는 많은 제어 기능을 가지고 있으므로 새로운 OS 기능 없이도 이를 구현할 수 있습니다.)

또한 대부분의 보안 문제와 마찬가지로 대부분의 문제는 위험을 인식하지 못하거나 어떤 이유로든(예: 시간 부족) 사용 중인 도구에 대한 보안 지침을 따르지 않기로 선택한 개발자에서 비롯됩니다. (예: 보안, 기본 기능 및 귀하의 책임 ) 우리는 개발자로서 모두 우리 작업의 품질(보안 포함)에 대한 책임을 져야 합니다.

마지막으로, 이러한 문제를 해결하기 위해 Microsoft와 같은 상용 소프트웨어 기업을 찾는 것은 실수라고 생각합니다. 이는 부분적으로는 방금 언급한 것처럼 보안 의식이 없는 개발자를 통해 보안 응용 프로그램을 생성할 것으로 기대할 수 없기 때문입니다. 더 중요한 것은 적어도 내 생각에 Electron의 아름다운 점 중 하나는 일반적으로 상용 소프트웨어 공급업체에게 높은 우선순위가 아닌 오픈 소스 및 다중 플랫폼 특성이라는 것입니다. 잘 생각하고 성공적인 진행을 위해서는 전체 개발자 커뮤니티의 어느 정도 수준의 합의와 노력이 필요할 것입니다. 물론 영리 단체의 기여는 물론 감사합니다.

@jacobq 혹시 모르시 겠지만, 마이크로소프트는 Electron의 소유주입니다.

혹시 모르니 Microsoft가 Electron의 소유주입니다.

@Jop-V 이에 대한 인용을 추가하십시오. 나는 그것이 옳지 않다고 생각한다. electronjs.com 첫 페이지 에 다음과 같이 나와 있습니다.

Electron은 GitHub와 활발한 기여자 커뮤니티에서 유지 관리하는 오픈 소스 프로젝트입니다.

Microsoft는 Electron의 소비자(Visual Studio Code와 같은 제품에서 사용)이자 기여자이기도 하지만 소유권은 없습니다. 라이선스 파일 에는 Microsoft가 언급되어 있지 않으며 Wikipedia 기사 에서도 Microsoft가 소유권을 갖고 있다고 제안하지 않습니다.

@jacobq Microsoft는 GitHub를 인수할 예정이므로 현재 GitHub에서 Electron을 유지 관리하고 있다면 내가 말할 수 있는 한 곧 Microsoft에서 유지 관리할 것입니다.

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

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

Microsoft의 Github 인수는 Electron에 아무런 의미가 없습니다. Github은 자체 제품과 프로젝트가 있는 별도의 회사입니다. 나는 마이크로소프트가 아톰의 소유권을 가져가는 것을 보는 것처럼 마이크로소프트가 전자의 소유권을 가져가는 것을 보지 않는다.

나는 이 논쟁이 문제의 초기 요점에 실제로 도움이 되지 않는다고 생각합니다.

https://github.com/GoogleChromeLabs/carlo

Carlo는 꽤 흥미롭게 보입니다. 나는 그것을 회전시켜 보았고 매우 직관적입니다. pkg 로 실험해본 사람이 있습니까?

최종 사용자의 하드 드라이브 및 메모리 팽창을 줄이기 위한 모든 제안이 실행되지 않는 이유는 무엇입니까? 이것은 4년이 지난 지금도 여전히 아이디어일 뿐인 환상적인 아이디어입니다. 왜 이런 종류의 것들이 프로젝트 우선 순위의 맨 위에 있지 않은지 이해할 수 없습니다.

@danielo515 또 다른 부지런한 프로젝트를 만드는 대신 https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app이 있기 때문입니다.

무슨 얘기를하는 건가요? 이것은 이미 엄청난 프로젝트입니다. 또한 가장 널리 사용되고 사용되므로 이 프로젝트의 일부여야 하는 기능에 대해 다른 프로젝트에 대해 사람들을 지적하는 것은 나에게 옳지 않은 것 같습니다.
또한 Carlo는 다른 접근 방식이며 설치된 Chrome을 사용하므로 Electron의 데몬 버전과 다릅니다.

왜 이런 종류의 것들이 프로젝트 우선 순위의 맨 위에 있지 않은지 이해할 수 없습니다.

그것을 현실로 만드는 것은 어렵기 때문입니다(예: "정말" 어렵습니다).

만족스럽지 않다면(완전히 이해할 수 있음), 자유롭게 Electron을 포크하고 PR을 제출하십시오.

오해하지 마세요. 이 문제에 대한 쉬운 해결책이 있었다면 이미 구현되었을 것입니다.

@danielo515

... 사람들에게 이 프로젝트의 일부여야 하는 기능에 대해 다른 프로젝트를 지시하는 것은 옳지 않은 것 같습니다.

요점은 각 프로젝트마다 장단점이 있고 Carlo는 공간이 제한된 경우에 적합하다는 것입니다. 내 사용 사례의 경우 100MB 앱 크기가 완벽하므로 이 기능이 구현되는 것을 보고 싶지만 다른 전자 기능이 훨씬 더 중요합니다.

@jacobq 네, 맞습니다. 사용 사례에 따라 다양한 도구가 필요합니다.

관심 있는 사람이 있으면 데스크톱에서 js 앱을 개발하기 위한 유사한 도구 목록을 만들었습니다.

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

나는 수십 개의 100MB 앱을 업데이트할 여유가 없기 때문에 Electron을 사용하지 않습니다. 앱을 업데이트해야 하는 방법을 알고 있습니다(이에 대해 다른 의견이 있지만 공유하면 도움이 되지 않습니다).
carlo의 접근 방식에 대해 내가 정말 좋아하는 것은 설치된 브라우저를 사용하는 아이디어입니다.
더 좋은 점은 puppeteer가 다른 브라우저도 관리할 수 있기 때문에 carlo는 크롬뿐만 아니라 사용 가능한 모든 브라우저를 사용할 수 있다는 것입니다. OSX에서는 Safari, linux epiphany(webkitgtk) 또는 firefox 등에서 생성됩니다...
따라서 실제로 앱을 얻으려면 nodejs와 앱만 설치하면 됩니다.
이제 질문은 다음과 같습니다. 시스템 설치 라이브러리와 기본 애드온을 사용하는 데 pkg가 얼마나 좋은가요?
예를 들어 현재 개발 중인 앱을 패키징해야 한다면 postgresql, sharp(및 vips), webkitgtk 및 exiftool이 필요합니다. linux debian, fedora 또는 ubuntu 사용자에게만 앱을 배포할 수 있기를 원합니다. 나는 "미친 번들"에서 벗어나 그 배포판에서 수행한 힘든 작업을 무료로 활용하고 싶습니다.

@kapouer ... 설치된 브라우저 사용 ...

이론상으로는 여러 브라우저에 대한 지원에 집중해야 하므로 웹 측에서 응용 프로그램을 코딩하는 데 어려움을 겪을 수 있습니다. Chromium에서 찾을 수 있는 것과 같은 것을 완벽하게 지원하지 않습니다. 또한 사용자의 브라우저가 최신 상태인지 확인하고 여러 브라우저 공급업체가 업데이트로 애플리케이션을 중단시키지 않도록 해야 합니다.

많은 사용자가 델타 업데이트로 전환하거나 패키지 관리자가 .asar 파일 또는 리소스 폴더만 업데이트하도록 하여 대규모 50Mb 업데이트를 수행했습니다. 그리고 필요할 때만 대규모 Electron 업데이트를 수행하십시오. 이것이 우리가 회사에서 하는 일이며 훌륭하게 이루어졌습니다.

순진한 사용자의 관점에서 Electron app-shell을 Shared Runtime으로 사용하면 배포와 사용이 정말 쉬워집니다. 예를 들어 단일 시스템에 5개의 전자 앱이 있으면 5개의 app-shell 인스턴스가 있고 약 300MB입니다. 그렇죠?

나는 전자가 데스크탑 UX의 미래이며 이것은 웹 기술을 더 강력하게 만드는 큰 단계가 될 것이라고 굳게 믿습니다.

Electron에는 이미 개발용 런타임이 있습니다. 그렇지 않나요? "전자 ." 명령, 내 말은. 사용자 측에서 재사용하지 않는 이유는 무엇입니까?

Electron의 다른 버전에 따라 여러 앱을 처리하기 위해 .NET core가 사용하는 접근 방식을 사용할 수 있습니다. 여러 버전의 런타임을 나란히 설치하고 앱이 필요한 최소(또는 최대) 버전을 선언하도록 하십시오.

나는 개념 증명 런처를 만들었습니다: https://github.com/ProPuke/electron-shared

크기가 1MB 미만인 단일 실행 파일입니다. 앱 디렉토리 또는 asar 패키지를 전달하면 package.json devDependencies에서 전자 버전 요구 사항을 확인하고 올바른 버전으로 다운로드/실행합니다.

Electron 런타임은 AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac)에 저장되므로 앱 간에 공유할 수 있습니다.

경로를 지정하지 않으면 app 디렉토리 또는 app.asar (있는 경우)가 자동으로 실행됩니다. 따라서 이 파일과 app.asar 만으로 앱을 배포할 수 있습니다. 또는 이것은 .asar 파일과 연관될 수 있으며 asar만 배포될 수 있습니다.

또한 --downloadOnly 및 --silent 를 포함한 몇 가지 명령줄 매개변수가 있으므로 설정 프로세스 중에 설치 프로그램 내에서 호출할 수 있습니다.

자동 업데이트를 처리하지 않습니다(Electron의 호환 버전이 컴퓨터에서 아직 사용 가능하지 않은 경우에만 다운로드됨). 그러나 이것은 실행 시 또는 백그라운드 서비스에 의해 주기적으로 수행될 수 있습니다(런타임이 다음 위치에 있는 한 앱이 실행될 때 최신 위치를 찾아 사용합니다.

런타임의 오래된 복사본을 삭제할 때를 아는 것은 까다로울 수 있습니다. 시간이 지나면 쌓일 수 있습니다. 설치된 앱이 어떤 버전을 사용했는지(따라서 더 이상 필요하지 않은 앱) 추적하거나 각 런타임 버전에 대해 마지막으로 사용한 날짜를 저장하고 사용하지 않은 경우 자동 삭제해야 합니다. 잠시 후.

어쨌든, 개념/제안 증명. 이와 같은 것이 문제를 해결합니까? 내가 눈에 띄고 분명한 것을 놓친 적이 있습니까?

@ProPuke 의 전자 공유 를 사용해 보았고 전자 빠른 시작 데모를 실행할 수 있었습니다. 그러나 전자 웹 사이트에 설명된 앱을 실행할 수 없었습니다( 대부분의 앱이 일부 셸 스크립트를 사용하여 앱을 시작하고 내가 이해하는 대로 package.json 뿐만 아니라). 그러나 나는 이 _개념 증명/제안_이 다음 큰 업그레이드에 대한 포인터가 될 수 있다고 믿습니다.

전자는 현재 "electron.exe 경로" 명령을 지원하기 때문에 명령줄에서 여러 asars를 호출하여 열 수 있다고 생각합니다. 현재로서는 그냥 아이디어일 뿐입니다. 누군가가 할 수 있기를 바랍니다. 이 소프트웨어에 대해 방금 만졌기 때문입니다.
______________ 중국어 번역 버전__________
나는 아이디어가. 현재 전자는 "electron.exe 경로" 명령을 지원하기 때문입니다. 명령줄을 사용하여 여러 asar를 호출하여 열 수 있다고 생각합니다. 저는 현재로서는 그저 아이디어일 뿐입니다. 이 소프트웨어에 이제 막 참여했기 때문에 누군가가 그것을 볼 수 있기를 바랍니다.

전체 대화(및 여러 "앱"과 같은 다른 토론)를 대충 살펴본 후 요약하겠습니다. 여러 바이너리로 시작하는 대신 기본적으로 여러 asar를 호출하는 것은 오랜 역사를 가지고 있지만 지원되지는 않습니다. 그러나 전자의 default_app은 명령줄을 사용하여 구현됩니다(당분간은 모르겠습니다). 전자를 통해 cmd를 호출하면(가능한 것 같습니다) 이 기능 호환성을 달성할 수 있어야 한다고 생각합니다.
모든 대화(및 여러 "앱"과 같은 기타 토론)를 대충 살펴보면 여러 바이너리 대신 여러 Asar에 대한 기본 호출이 시작된다는 결론을 내렸습니다. 이는 오랜 역사를 가지고 있지만 지원되지는 않습니다. 그러나 Electron의 default_app은 명령줄을 활용하는 구현(그리고 아마도 한동안은 모르겠습니다.) 나는 전자를 통해 cmd를 호출하고 싶습니다(가능한 것처럼) 이 기능 호환성 막대를 달성할 수 있어야 합니다.

최악의 시나리오에서는 .bat 파일 또는 Windows가 아닌 OS에 해당하는 파일을 만들고 Electron에서 실행해야 합니다.

유용한 링크:

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

9718

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

app.asar나 app ​​폴더가 없을 때만 커맨드 전자인 것 같습니다. 유효한 exe 경로

오, 그래서 당신은 모든 것을 설정하는 데 사용되는 전자 내부의 exe 경로를 실행하기 위해 전자가 필요합니다. 사용하는 모든 앱에 대해 전자 설치보다 여전히 낫습니다. 앱에 필요한 모든 전자 버전에 대해 하나의 전자 설치만 필요합니다. 실행하려는 앱과 권장 버전(즉시 실행), 호환 버전(실행 또는 권장 버전을 설치하고 백그라운드에서 권장 Electron 버전을 다운로드) 또는 권장 버전을 다운로드할 수 있도록 다운로드 진행률 표시줄만 표시합니다.

아니면 내가 뭔가를 잘못 이해했습니다.

이 아이디어는 아마도 동일할 것입니다. bat는 현재 말하기 쉽기 때문에 예를 들어 내용은 electron.exe app1.asar이고 실행 후 electron은 app1.asar의 내용을 엽니다. 아마도 그것이 작동하는 방식이지만 bat에서 다음 문장 electron.exe app2.asar를 작성할 때 app1.asar의 전자가 끝날 때만 수행할 수 있습니다. 그리고 배트가 꺼지면 전자도 꺼집니다. 하지만 저는 electron.exe app3.asar|electron.exe-v 또는 electron.exe app3.asar|start 등을 작성합니다. 박쥐를 닫으면 전자는 살아남을 수 있지만 다른 asar를 계속 열 수는 없습니다. bat는 여전히 다소 제한적이기 때문에 이 독립 실행형 프로그램이 이 프로그램보다 나을 수 있다고 생각합니다.

임시 폴더를 사용하는 경우에는 그렇지 않습니다.

전자 버전 폴더에 (아카이브 또는 아카이브되지 않은) 버전이 있습니다. 여기에서 권장 버전 또는 사용 중인 버전을 임시 폴더에 복사하여 다운로드한 최신 호환 버전을 사용하고 완료한 후 폴더를 삭제합니다.

로컬에 저장된 파일의 경로는 전자 폴더에 있거나 사용 중인 파일 옆에 있습니다. 지난 24시간 동안 내가 언급한 내용이 포함된 아카이브에서 사용하는 경우 저장된 데이터 파일을 아카이브로 다시 이동하거나 임시 전자 인스턴스 폴더를 삭제하기 전에 전혀 이동하지 않아야 합니다.

SSD?

???

임시 전자 폴더를 삭제하는 이유는 앱이 이론적으로 설계에 따라 실행 중인 전자 설치 파일을 변경할 수 있기 때문입니다. 내 말은, 아카이브에는 임시 전자 설치 내에서 쓰거나 덮어써야 하는 파일과 폴더가 포함될 수 있습니다.

따라서 설치를 사용한 후에는 실행한 앱에 의해 손상된 것으로 처리될 수 있으므로 재활용할 수 없으므로 삭제해야 합니다. 그러나 우리가 만들려고 하는 런타임 전자 앱의 electron_versions 폴더에서 기반으로 사용된 그때까지 손상된 설치 버전은 여전히 ​​손상되지 않았습니다.

실제로 앞서 언급한 고유한 확장자를 가진 아카이브가 읽기 전용인 경우 이론적으로 사용된 데이터를 %appdata%로 이동할 수 있습니다. 따라서 우리가 만들려고 하는 런타임 모드 전자 내부에서 실행되는 앱은 실제로 이식 가능(자체 포함)되므로 해당 파일을 복사하면 해당 앱의 구성을 가져오기에 충분합니다.

그러나 우리는 아마도 그 파일 유형에 대한 업데이트 기능을 추가해야 할 것입니다. 이는 새 설치 파일에서 이전 설치 파일의 사본으로 파일을 복사하고 덮어쓰고 새 설치 파일을 가지고 있던 데이터. 우리가 만들려고 하는 런타임 모드 전자가 사용하는 파일에 다운로드 링크가 있으면 모든 작업이 자동으로 수행될 수 있습니다.

준비가 완료되면 추가 작업을 수행하려는 경우 앱을 업데이트할 git 클라이언트를 추가할 수도 있습니다. 하지만 이를 위해서는 github 및 bitbucket을 사용하여 아카이브 컴파일된 파일을 호스팅해야 할 수도 있습니다.

"curl, wget, aria2c" 다운로드 파일을 사용할 수 있으며 사용자는 git을 설치할 필요가 없습니다.，오， "gzip,7z" 압축 풀기 zip을 사용해야 합니다.

electron-builder 와 유사하게 작동하는 electron-runtime 도구를 만들고 있습니다. app.asar 파일만 간단한 sh 스크립트와 함께 번들로 제공됩니다(나중에 이것은 Electron 다운로드의 진행 상황을 보여주는 UI가 될 것입니다). 현재는 macOS에서만 작동합니다.

electron-runtime 패키지로 된 앱을 실행하면 기본적으로 해당하는 메이저 버전의 Electron을 다운로드 하지만, Electron의 브레이킹 체인지는 메이저 버전 증분에서만 발생하기 때문에 마이너 및 패치의 경우 최신 버전입니다.

electron-quick-start 앱은 62KB에 불과합니다. 스크린샷:

관심이 있으시면 별, PR 또는 이슈를 남겨주세요.

electron-builder 를 사용하여 빌드할 수 있도록 패키지를 약간 업데이트 했습니다(작동 방식은 다음과 같습니다 ). 이제 Visual Studio Code도 빌드할 수 있습니다! (그러나 여전히 macOS에서만).

electron-global 의 첫 번째 버전을 성공적으로 출시했습니다! ( electron-runtime 를 가져갔기 때문에 변경했습니다.) electron-builder 내 npm 패키지를 사용하여 앱을 빌드할 수 있습니다. 또한 Electron 다운로드 진행률을 표시하기 위해 진행률 표시줄이 있는 UI를 추가했습니다. 전자를 더 좋게 만들기 위해 더 대중화되기를 바랍니다.

죄송합니다. 저는 Windows 시스템을 사용하고 있고 MacOS를 사용할 돈이 없습니다. 하지만 귀하의 프로젝트는 매우 성공적일 것이라고 믿습니다.

@nwdxlgzs Windows, macOS 및 Linux를 지원합니다...

이 프로젝트는 MAC만 지원한다고 생각했습니다.
나는 이 훌륭한 프로젝트를 시도하는 데 시간을 할애할 것입니다.

만들어 주셔서 감사하고 최신 정보를 유지해 주셔서 감사합니다!
저도 윈도우를 사용하고 있습니다.
변경되면 코드를 살펴보겠습니다.

음, electron-global 업스트림을 통합하고 새 기본값으로 만드는 것은 어떻습니까 😏