Three.js: ES6 JSM 라이브러리와 함께 JS 라이브러리에 대한 계속 지원

내가 올바르게 이해한다면 계획은 "/build/three.module.js" 외에 "/build/three.js"를 계속 포함하는 것입니다.

네. 그러나 이러한 접근 방식이 타당한지는 의문입니다. examples/js 가 제거되면 three.js 및 three.min.js 가 여전히 유용한 몇 가지 사용 사례만 남습니다.

npm 패키지의 main 진입점을 변경할 수 있으므로 three.js 및 three.min.js 를 제거하는 것이 실제로 도움이 됩니다(#19575 참조).

그렇게 쉽게 할 수 있다면 빌드 프로세스의 일부로 ES6 번들러 스크립트를 통해 자동으로 생성하여 /examples/js를 계속 지원하는 것이 합리적이라고 생각합니다.

아이디어는 examples/jsm 를 클래스와 같은 보다 현대적인 JavaScript 언어 기능으로 옮기는 것입니다. examples/js 는 여전히 이전 브라우저에서 작동해야 하므로 코드 변환 기능을 사용하여 새(예제) 빌드를 구성해야 합니다. 게다가, 우리는 여전히 중복 코드 기반( examples/js vs examples/jsm )을 유지합니다. 이는 제 관점에서 잘못된 접근 방식입니다. 유지 관리가 더 복잡해집니다.

필요한 경우 사용자가 ES6에서 ES5로의 변환을 처리해야 한다고 생각합니다. 코드 축소 또는 기타 빌드 관련 작업에서도 동일합니다.

나는 당신이 옳다고 믿습니다. 내가 올바르게 이해한다면 계획은 " /build/three.module.js " 외에 " /build/three.js "를 계속 포함하는 것입니다.

진실

/examples 폴더에서 채우기의 문제는 /build/three.js 를 사용할 때 /examples/js $의 파일을, $ /build/three.module.js 를 사용할 때 /examples/jsm 의 파일을 사용해야 한다는 것입니다. /build/three.module.js , 일명 로드 방법의 일관성 유지.

왜요? 모듈 가져오기를 사용할 때 기본 THREE 개체는 더 이상 일반 js 개체 THREE = {} 가 아니라 봉인된(확장할 수 없는) 내부 브라우저의 모듈 개체이므로 /examples/js 의 파일 THREE 개체에 새 속성을 쓰려는 # /examples/js 는 실패합니다.

따라서 import * as THREE from '/build/three.module.js 와 THREE.WhateverExample = function() ... 를 혼합할 수 없습니다.

한 가지 가능한 방법은 가져온 lib의 이름을 THREE 이외의 다른 이름으로 변경하고 예제를 작성할 일반 js THREE 전역 개체를 다시 만드는 것입니다...

이것은 일반적으로 다음의 문제입니다.

기존 JS에는 다음이 포함됩니다.

전역 공간 명명을 더럽히고 로드된 파일의 이름을 수정할 수 없기 때문에 다음과 같은 오류가 발생할 수 있습니다.
반면에 모듈을 사용하면 가져오는 동안 사용자가 이름 지정 권한을 얻게 되며 결과 이름을 선택하는 것은 더 이상 라이브러리 작성자가 아닙니다...

전:

<script>
// a script you can't modify already use the name THREE
var THREE = document.getElementById('div-nb-3')
</script>

<script type="module">
import * as foo from '/build/three.module.js'

THREE.appendChild( new foo.WebGLRenderer().domElement )
</script>

@Mugen87 100% 맞습니다. /examples/js 를 버리면 three.js 및 three.min.js 가 기본적으로 애드온 모듈과 호환되지 않기 때문에 버리는 것이 좋습니다. 그들의 사용 사례는 틈새 시장이 될 것이고 이것은 혼란을 야기할 것이 거의 보장됩니다.

@devingfx 모듈에 장점이 있고 잠재적인 전역 이름 충돌을 제거한다는 말이 맞습니다. 수년 동안 나는 THREE 전역 변수와 충돌하는 것이 없었고 이것이 있을 법하지 않은 시나리오라고 생각하지만 귀하의 요점은 기술적으로 정확합니다.

내 관점에서 볼 때 나쁜 접근 방식입니다. 유지 관리가 더 복잡해집니다.

필요한 경우 사용자가 ES6에서 ES5로의 변환을 처리해야 한다고 생각합니다. 코드 축소 또는 기타 빌드 관련 작업에서도 동일합니다.

@ Mugen87 모듈 외에 전역 변수를 사용하는 전통적인 js 포함을 유지하는 것이 정말 끔찍합니까? 많은 라이브러리가 둘 다 지원하며 기존 JS 버전이 종종 모듈 버전만큼 널리 사용된다고 말할 수 있습니다. 둘 다 장단점이 있으며 그 중 일부는 선호도에 따라 결정됩니다. 개발자에게 모듈이 아닌 컨텍스트에서 라이브러리를 사용할 수 있는 옵션을 제공하는 것이 좋지 않습니까?

three.module.js 및 /examples/jsm 에서 three.min.js, three.js 및 /examples/js 를 자동으로 생성하는 데 필요한 코드 변환 기능을 생성/테스트하는 일을 기꺼이 처리하겠습니다. 변환 워크플로가 수정된 후에는 최소한의 유지 관리가 필요할 수 있지만 != 두 개의 병렬 버전을 유지 관리해야 합니다. 대부분의 경우 코드는 모듈 파일에서 업데이트하기만 하면 되며 가끔씩만 일부 트랜스파일 문제를 수정해야 합니다.

나는 전통적인 전역 구문에 의존하는 충분한 프로젝트를 가지고 있으며 어쨌든 모듈의 번역을 자동화하는 작업을 수행할 예정입니다. 최소한 package.json에 명령을 포함하고 모듈을 원본과 유사하게 동작하는 three.min.js, three.js 및 /examples/js 로 변환하는 "legacy-build"라고 부를 수 있다고 생각합니다. 지금 파일. 이러한 파일은 리포지토리에 커밋하거나 기본적으로 생성할 필요도 없습니다. 우리는 또한 레거시 지원을 위한 것이라고 경고할 수 있습니다. 작동이 보장되지 않습니다. 대신 모듈을 사용하는 것이 좋습니다.

현실적으로는 저장소에 보관하고 빌드 시 트랜스파일을 통해 자동으로 생성되도록 하는 것이 더 합리적이라고 생각합니다.

package.json에 명령을 입력하고 모듈을 변환하는 "legacy-build"라고 부릅니다.

합리적인 것 같습니다. 최근에 babel이 병합되지 않았습니까? 그래서 나는 이것이 그대로 할 수 있다고 생각합니다.

편집: 명확히 하기 위해, 해당 빌드를 원하는 사용자를 제외한 다른 사람이 새 명령을 실행할 수 없다고 말했습니다.

모듈 외에 전역 변수를 사용하는 전통적인 js 포함을 유지하는 것이 정말 끔찍합니까?

이를 유지 관리하는 복잡성이 과소 평가되고 있다고 생각합니다. 불행히도 프로젝트에서 예제가 설정되는 방식이 그렇게 간단하지 않다고 생각합니다.

GLTFLoader를 예로 들어 보겠습니다. 현재 모든 GLTFLoader는 단일 파일에 포함되어 있어 HTML 파일 상단에 쉽게 포함할 수 있습니다. 모듈의 장점 중 하나는 GLTFLoader가 종속성으로 가져올 수 있는 더 큰 파일 중 일부를 별도의 파일로 나눌 수 있다는 것입니다. GLTFLoader가 4개의 외부 파일에 의존하고 그 중 일부가 공유되면 빌드된 전역 스크립트가 포함해야 하는 모양은 무엇입니까? 빌드된 전역 스크립트의 사용자는 이제 이러한 모든 예제 js 파일을 개별적으로 포함해야 합니까? 아니면 함께 번들로 사용할 수 있는 파일 목록과 그렇지 않은 파일 목록을 수동으로 유지 관리해야 하는 일부 파일이 함께 번들로 제공됩니까?

나는 유일하게 설정하고 잊어 버리는 경우가 모든 예제 js 파일을 합리적이지 않다고 생각하는 단일 모놀리식 blob으로 묶는 것이라고 생각합니다. 이러한 솔루션을 사용하면 다른 릴리스 및 문서 오버헤드도 발생할 수 있다고 생각합니다.

아마도 더 나은 방법이 있을 수 있지만 이전 버전과의 호환성을 유지하거나 최소한 기존 js 파일에 대한 일관된 구조를 유지하는 롤업 빌드를 만들려고 할 때 이러한 문제가 발생했습니다.

내가 올바르게 이해한다면 계획은 "/build/three.module.js" 외에 "/build/three.js"를 계속 포함하는 것입니다.

네. 그러나 이러한 접근 방식이 타당한지는 의문입니다.
examples/js가 제거되면 three.js 및 three.min.js가 여전히 유용한 몇 가지 사용 사례만 남습니다.

@Mugen87 @mrdoob

남자 이름,
사실 "three.min.js"를 최소 2년 더 유지하는 것은 필수입니다.
내 모든 샘플이 이를 기반으로 하기 때문이 아닙니다.
그러나 수천 개의 파일과 Google 최고의 개가 이를 기반으로 하기 때문입니다!
예: https://www.google.com/search?source=hp&q=webgl+benchmark

반면에 "three.min.js"는 더 빠른 개발 및 테스트를 의미합니다.
오프라인에서 작동하고 localhost가 필요하지 않다는 것은 말할 것도 없습니다.
모든 파일을 폴더 어딘가에 넣고 Firefox를 사용하여 HTML 파일을 두 번 클릭하십시오.
나는 항상 개발을 위해 그것을 좋아했습니다!

Ricardo는 이 모든 것에 대해서도 생각해야 합니다.
건배

three.js 및 three.min.js 제거는 examples/js 가 없어졌을 때 논의하고 계획할 수 있는 것입니다. 더 이상 examples/js 에서 파일을 가져올 수 없을 때 중요성이 상실되었음을 강조하는 것이 중요했습니다.

이를 유지 관리하는 복잡성이 과소 평가되고 있다고 생각합니다. 불행히도 프로젝트에서 예제가 설정되는 방식이 그렇게 간단하지 않다고 생각합니다.

나는 당신이 제기하는 포인트를 정말 좋아합니다. 번들링에는 전혀 예상치 못한 복잡성이 있으며 중첩 모듈의 예가 좋은 예입니다. 당신의 요점에 따르면, 우리는 그 때가 되었을 때 중첩 모듈을 묶는 방법에 대해 합리적인 결정을 내릴 수 있다고 생각합니다. 나는 번들러 스크립트가 그것을 설정하고 상황을 잊어 버릴 것이라고 말하는 것이 아니라 단지 유지 관리가 더 낮을 것이라는 것입니다.

유지 관리가 너무 어려운 시기가 되면 언제든지 중단할 수 있지만 아직 발생하지 않은 문제 때문에 시도를 할인하는 것은 어리석은 일이라고 생각합니다. /examples/jsm 과 examples/js 사이에 여전히 1:1 패리티가 있는 동안 지금 구현하는 것이 가장 쉬울 것입니다. /example/jsm 모듈 계층 구조를 대대적으로 재구성하지 않을 가능성이 높으며 그렇게 할 때 번들러를 점진적으로 업데이트할 수 있다고 생각합니다. 나는 계속해서 그들이 말하는 대로 내 입이 있는 곳에 내 돈을 두기 위해 (이미 추가되었기 때문에 babel을 사용하여) 이것에 대한 작업 증명 작업을 시작할 것입니다.

Mugen의 요점에 따르면, 이는 three.js 및 three.min.js 에 대한 관련성을 유지하는 데 도움이 되는 동시에 계속 유지하는 데 도움이 됩니다. 또한 비 모듈 기반 THREE 구현과 호환되는 업데이트를 찾고 있는 수백 개의 사이트에 도움이 될 수 있습니다. 모듈을 사용하기 위한 THREE 프로젝트의 리팩토링은 수행 중인 작업을 알고 있더라도 상당히 광범위할 수 있습니다.

다른 공동 작업자에 대해 말할 수는 없지만 이 주제에 대해 마음을 바꾸지는 않을 것입니다. 여기 #18749에서 논의되고 커밋된 대로 2020년 12월 릴리스와 함께 examples/js 를 삭제하는 데 투표합니다.

여기 #18749에서 논의되고 커밋된 대로 2020년 12월 릴리스와 함께 examples/js를 삭제하기로 투표합니다.

나는 그것에 아무런 문제가 없습니다.
"three.min.js"를 몇 년 더 사용할 수 있는 한 ...

Mugen 입력에 감사드립니다. 해당 스레드를 읽었지만 결정에 대한 설명이 아니라 발표에 더 가까운 것으로 보입니다. 내 가정은 단순화된 개발이 이 방향으로 나아가는 주된 이유라는 것입니다. 다른 이유가 있습니까?

/examples/js 스타일 포함을 생성하기 위해 실행할 수 있는 변환 스크립트가 있는 것은 여기에서 적절한 절충안이 되어야 한다고 생각합니다. 여기에 필요한 유지 관리/복잡화의 양을 크게 줄여야 합니다. 직접 실행해야 하는 package.json의 명령이고 기본적으로 파일이 생성되지 않는 경우에도 괜찮습니다. 어쨌든 트랜스파일해야 하는 일부 개발자와 다른 개발자에게는 이점이 있습니다. 공동 작업을 더 잘 수행할 수 있도록 기본 리포지토리에 무언가를 보관할 수 있을 때 우리 모두가 별도로 번역/번들 워크플로를 만들지 않았으면 합니다. :)

나는 그 스레드를 읽었지만 결정에 대한 설명과는 반대로 발표에 더 가깝습니다.

불행히도 우리는 항상 모든 유효한 주장을 단일 스레드에 고정할 수 없습니다. 디자인 변경의 실현이 수년에 걸쳐 여러 논의에서 천천히 진행되기 때문이거나 단순히 동일한 주제에 대한 여러 스레드가 계속해서 생성되기 때문입니다(예: ). 공동 작업자는 노이즈와 세분화를 최소화하려고 노력하지만 항상 가능한 것은 아닙니다.

내 가정은 단순화된 개발이 이 방향으로 나아가는 주된 이유라는 것입니다. 다른 이유가 있습니까?

내가 본 가장 큰 것은 중복 코드를 최소화하고 재사용 가능한 구현을 만드는 하위 모듈을 사용하고 가져오는 기능입니다.

예를 들어, 대부분의 로더는 일종의 데이터 구문 분석 구조/클래스를 생성해야 합니다. 이는 각 로더가 example/js 파일을 재사용할 수 있도록 자급자족해야 하기 때문입니다. 그러나 비 모듈식 제한을 완전히 제거하면 DataParser 클래스의 단일 인스턴스를 만들고 모든 로더에서 해당 표준 구현을 가져올 수 있으므로 개발이 즉시 쉬워지고 중복 코드도 제거됩니다. 모든 로더.

네, 좋은 지적입니다. 우리는 이미 Pass 클래스(모든 FX 패스의 기본 클래스)를 EffectComposer 에 포함시키는 것과 같은 더러운 해킹을 만들어 레거시 코드가 손상되지 않도록 해야 합니다.

아주 좋은 점들이 두루두루 만들어졌습니다.

사람들을 추적/최신 상태로 유지하고 유지하는 것은 (내 경험에 따르면) 어려운 문제처럼 들립니다. 이것에 대해 생각을 좀 해보려고 합니다.

사실 "three.min.js"를 최소 2년 더 유지하는 것은 필수입니다.

Babel을 사용하여 ES5 빌드를 생성하는 것은 항상 가능합니다. 이에 대해 우리가 대답해야 할 질문은 이에 대한 책임이 우리에게 있는지 아니면 three.js를 사용하는 개발자에게 있는지입니다.

예제 파일의 ES5 버전을 만드는 것은 개발자에게 달려 있다고 이미 결정했으므로 빌드 파일에 대해서도 동일한 작업을 수행하는 것이 합리적일 것입니다. 내 생각에는 간격을 두는 것보다 한 릴리스에서 전체 라이브러리에 걸쳐 이 작업을 수행하는 것이 합리적이지만 three.min.js를 조금 더 오래 유지하는 것도 좋습니다.

그러나 수천 개의 파일과 Google 최고의 개가 이를 기반으로 하기 때문입니다!
예: google.com/search?source=hp&q=webgl+benchmark

이것은 그 검색에서 나에게 나타나는 최상위 사이트이고 그들은 R53을 사용하고 있으므로 이 변경이 그들에게 너무 나쁜 영향을 미칠 것이라고 생각하지 않습니다: https://www.wirple.com/bmark/

보시다시피, three.js의 이전 버전은 여전히 ​​잘 작동합니다. 모듈로 전환한 후 Babel을 사용하지 않고 ES5 빌드를 원하는 사람은 누구나 ES5 파일을 제거하기 전의 마지막 버전을 사용하도록 지시할 수 있습니다. 그들은 해당 릴리스의 전체 리포지토리를 확인하고 해당 버전의 문서도 사용할 수 있습니다.

@looeeee 좋은 점을 만지셨습니다. 위에서 언급했듯이 여기에서 ES5 three.min.js 및 three.js 를 동시에 사용하지 않는 것이 합리적이라는 데 동의합니다. 아마도 그것은 자신의 별도 토론이어야합니까?

어느 쪽이든 나는 구식 ES5 스타일 /js/example 파일을 생성하는 데 사용할 수 있는 기본 저장소에 babel 스크립트를 포함하는 것에 대한 합의에 도달하고 싶습니다. 이것은 누군가가 이 지원을 제공할 책임이 있는지 여부에 관한 것이 아닙니다. 저처럼 이 기능이 필요한 기여자가 있습니다. 어쨌든 트랜스파일해야 하는 일부 개발자와 다른 개발자에게는 이점이 있습니다. 공동 작업을 더 잘 수행할 수 있도록 기본 리포지토리에 무언가를 보관할 수 있을 때 우리 모두가 별도로 번역/번들 워크플로를 만들지 않았으면 합니다.

나는 우리가 babel ES6에서 ES5 트랜스파일러 스크립트로 함께 작업할 수 있도록 메인 리포지토리에 하나의 파일을 허용하는 것이 공정한 타협이라고 생각합니다. 거기에 정말 문제가 있습니까? 기고자가 기본 리포지토리에서 필요한 기능에 대해 함께 작업할 수 있도록 허용하시겠습니까?

이 작업을 수행하는 데 협력자에게 도움이나 리소스를 요청하는 것이 아닙니다. 필요한 사람들이 기본 리포지토리에서 함께 작업할 수 있도록 허용해 달라는 것일 뿐입니다. 내가 이것을 위해 PR을 하고 그것이 효과가 있다면, 당신은 정말로 그것을 거부하기 위해 투표하시겠습니까?

내가 이것에 대한 PR을 만들고 작동한다면

내 말은, 이것이 시작되는 것을 보니 기쁩니다

당신은 정말로 그것을 거부하기 위해 투표하시겠습니까?

린팅 패스에 실패하면 모든 베팅이 취소됩니다 😂

거기에 정말 문제가 있습니까?

예, 저장소가 더 이상 사용되지 않는 코딩 패턴을 홍보해서는 안 되기 때문입니다.

예, 저장소가 더 이상 사용되지 않는 코딩 패턴을 홍보해서는 안 되기 때문입니다.

three.js + three.min.js (ITT는 우리도 그것들을 해고해야 한다는 합의를 인정함)를 하지 않고 직접 수동으로 실행해야 하는 babel 스크립트가 있는 경우 공식적으로 아직 사용되지 않습니다. 거의 빛나는 지지. 나는 우리가 사람들이 대신 모듈을 사용하도록 확실히 권장하고 babel 스크립트와 이에 대해 생성된 파일에 경고를 표시해야 한다는 데 동의합니다. 나는 기여자들이 더 이상 사용되지 않는 코딩 패턴을 조장하는 이유로 모듈을 사용할 수 없는 상황에 있는 사람들을 위해 함께 babel 스크립트 작업을 하는 것을 허용하지 않습니다. 주로 모듈을 사용하는 것이 불가능하거나 비실용적인 상황이 여전히 있기 때문입니다. 문서는 이러한 필요성을 인정합니다. 함께 작업하는 데 필요한 사람들을 위해 하나의 파일을 안전하게 추가할 수 있다고 생각합니다.

여기에서 ES5 three.min.js와 three.js를 동시에 사용하지 않는 것이 합리적이라는 데 동의합니다.

나는 examples/js, three.min.js, three.js를 동시에 더 이상 사용하지 않아야 한다는 것을 의미했습니다. 즉, 여러 릴리스에 퍼뜨리기보다 한 릴리스에서 모든 ES5 코드를 제거해야 합니다.

@무겐87

예, 저장소가 더 이상 사용되지 않는 코딩 패턴을 홍보해서는 안 되기 때문입니다.

Windows 10에서 DOS 게임을 계속 실행할 수 있습니다.
그렇다고 해서 Microsoft가 "사용되지 않는 코딩 패턴"을 홍보하고 있다는 의미는 아닙니다.

이 프로젝트에서 유지 관리되는 예제 js 모듈을 명확히 하기 위해 사용할 노드, npm 또는 빌드 프레임워크가 필요하지 않습니다.

프로덕션 준비 애플리케이션을 구축한다는 것은 코드를 묶는다는 것을 잊지 말자 :)

사용 가능한 Rollup과 같은 번들 도구에 감사하지만 몇 가지 질문을 고려해야 한다고 생각합니다.

• 개발자가 프로덕션에서 THREE를 사용하려면 이러한 번들 도구 중 하나를 사용해야 한다고 가정하는 것이 공정합니까?
• examples 폴더에서 ES5/UMD 모듈에 대한 업데이트에 의존하는 다른 라이브러리에 대한 지원을 중단하는 것이 공정합니까?

이에 대한 개인적인 느낌:

이 도서관은 10년이 넘었습니다. ES5/UMD로 작성된 examples 폴더의 모듈에 의존하는 거대한 생태계가 있습니다. 전체 생태계에 대한 지원을 중단하는 것은 공정하지 않다고 생각합니다.

사람들이 모듈 번들링 패턴 없이 ES6을 사용할 수 있다는 사실을 잊은 것 같습니다. 나는 매일 ES6을 사용하지만 프론트엔드 애플리케이션에서는 모듈 번들링 패턴을 사용하지 않습니다. 저는 빌드 도구가 필요에 따라 매우 맞춤화되고 모듈 번들링 패턴을 통합할 수 없는 엔터프라이즈 상점에서 일했습니다.

우리는 무엇을 해야 합니까?

각 릴리스 이후에 주어진 배포에 대해 ES6 모듈을 ES5/UMD 모듈로 컴파일해 보겠습니다.

예, 저장소가 더 이상 사용되지 않는 코딩 패턴을 홍보해서는 안 되기 때문입니다.

삶의 거의 모든 것에 대해 솔루션은 여전히 ​​오래된 패턴, 기술 및 도구를 사용하여 우수한 품질을 유지할 수 있습니다.

비유하자면 - 여가 시간에는 포인트 끌로 돌 조각을 즐깁니다. 도구와 기술은 전동 공구와 다르지만 결국 조각품은 여전히 ​​고품질입니다. 나는 포인트 끌을 사용하는 것을 좋아하고 나 자신이나 다른 사람들이 만족하는 무언가를 생산하는 데 필요한 기술을 가지고 있기 때문에 포인트 끌을 사용하는 것을 개인적으로 선호했습니다.

ES5/UMD 모듈에 대해서도 마찬가지입니다. 저는 정말 고품질의 코드 기반을 유지하는 패턴, 기술 및 도구를 찾을 수 있었고 계속해서 개인 취향을 실행하고 싶습니다.

각 릴리스 이후에 주어진 배포에 대해 ES6 모듈을 ES5/UMD 모듈로 컴파일해 보겠습니다.

looee님 말씀에 동의합니다.

가정하는 것이 공정합니까 [...]

뭐라고 요? 우리는 우리가 선호하는 접근 방식에 대해 이야기하고 있습니다. '가정'은 나중에 옵니다. 선호는 다른 사람들이 모듈을 사용하도록 권장하는 것으로 보이지만(일부 사람들은 여전히 ​​오래된 3개를 원할 것이라고 가정) 실제로 원하는 사람들을 위한 경로를 제공합니다.

각 릴리스 이후에 주어진 배포에 대해 ES6 모듈을 ES5/UMD 모듈로 컴파일해 보겠습니다.

이것은 누구나 할 수 있습니다. 그 비용은 three.js 유지 관리자가 부담할 필요가 없습니다. 위에서 @gkjohnson 이 말한 것을 반복하고 싶습니다 examples/js 및 examples/jsm 디렉토리를 모두 유지 관리하는 비용이 높습니다. 우리는 이것을 무기한으로 할 수 없으며 ES6 모듈이 두 가지 접근 방식 중 더 현대적이라는 것이 분명합니다. 다음 비용을 고려하십시오.

• 자동화 생성 및 유지 관리
• 자동화 중단 시 릴리스 실패 디버깅
• 모든 풀 요청이 생성된 파일이 아닌 소스 파일을 업데이트하도록 합니다.
• 두 워크플로의 사용 방법을 설명하는 문서 유지 관리
• CJS 및 ES6 워크플로를 모두 사용하려는 사용자의 버그 보고서 및 지원 질문에 답변

마지막 항목이 아마도 가장 클 것입니다. 이 리포지토리에서 모든 항목에 대한 두 개의 복사본을 사용할 수 있는 한 둘 다 완전히 지원되는 것으로 표시됩니다. 두 가지 작업 흐름을 혼동하거나 복잡한 방식으로 실패하는 CJS 핵심 라이브러리와 함께 ES6 모듈 로더를 사용하려고 하는 사용자를 돕기 위해 정기적으로 시간을 할애합니다.

문제를 간단하게 바꿔 말할 수 있습니다. three.js 라이브러리의 중요하지만 선택적인 부분인 모든 예제는 현재 모듈 구문을 전혀 사용하지 않습니다. UMD도 아니고 CommonJS도 아니고 ES6 모듈도 아닙니다. 그들은 단순히 THREE 전역 네임스페이스를 패치합니다. 대신 ES6 가져오기/내보내기 구문을 사용하여 업데이트하고 싶습니다. 이 변경이 계획되었다는 조기 경고가 많이 있었습니다.

ES5/UMD로 작성된 examples 폴더의 모듈에 의존하는 거대한 생태계가 있습니다. 전체 생태계에 대한 지원을 중단하는 것은 공정하지 않다고 생각합니다.

three.js 생태계의 어떤 것도 글로벌 THREE.* 네임스페이스에 너무 의존적이어서 가져오기/내보내기 구문을 사용하거나 ES5로 변환하도록 업데이트할 수 없다고 말하는 것은 공정하지 않다고 생각합니다. 번들러를 사용합니다. 여기에는 여러 가지 해결 방법이 있으며 사용자에게 적합한 옵션을 찾는 데 도움이 되도록 기꺼이 도와드리겠습니다.

examples/js 및 examples/jsm 디렉토리를 모두 유지 관리하는 비용이 높습니다.

이에 대해 조금 더 파고들고 싶습니다. 저는 많은 사용자 정의 도구를 작성하고 프론트 엔드 애플리케이션을 위한 자동화 스크립트를 작성했으며 제가 할 수 있는 모든 방법으로 기꺼이 도와드리겠습니다.

자동화 생성 및 유지 관리
자동화 중단 시 릴리스 실패 디버깅

유지세를 조금 더 이해하도록 도와주세요. 이것은 THREE 코드베이스만의 고유한 것입니까? 내 경험에 따르면 이러한 유형의 코드는 일반적으로 최소한의 유지 관리가 필요한 가장 오래 지속됩니다. 이것들은 한 번 작성하고 오랜 시간 동안 다시 보지 않는 스크립트입니다.

모든 풀 요청이 생성된 파일이 아닌 소스 파일을 업데이트하도록 합니다.

릴리스 워크플로에서 작은 스크립트나 테스트가 도움이 될 수 있습니다.

두 워크플로의 사용 방법을 설명하는 문서 유지 관리

나는 또한 전역 네임스페이스에 대한 문서를 삭제하는 데 투표할 것입니다. 두 가지 워크플로에 대한 문서를 지원하는 것은 어리석은 일이라고 생각합니다. 이것은 나쁜 일이 아닙니다. 다른 컨텍스트에 대한 코드를 번들로 제공하는 대부분의 라이브러리인 UMD/ES6 모듈에는 문서 세트가 하나만 있습니다.

CJS 및 ES6 워크플로를 모두 사용하려는 사용자의 버그 보고서 및 지원 질문에 답변합니다.

이와 관련된 이슈의 양은 THREE의 인기에 비례한다고 생각합니다. 당신과 나는 스택 오버플로에서 항상 이러한 유형의 문제를 봅니다. 두 워크플로를 구분할 수 없는 사용자는 라이브러리에서 영감을 얻은 새로운 프로그래머일 가능성이 있으며 일반적으로 프로그래밍의 기본을 배우려고 합니다.

목표가 특히 두 워크플로 간의 혼동과 관련된 문제 의 양을 줄이는 것이라면 ES5 코드를 제거하는 것이 도움이 될 것입니다. 그러나 전반적인 문제의 양이 바뀔지는 의문입니다. 새로운 프로그래머는 항상 라이브러리와 관련되거나 관련되지 않을 수 있는 다음 질문에 갇힐 것입니다.

전체 문제의 양을 줄이는 방법은 무엇입니까?

실제 목표가 전체 문제의 양 을 줄이는 것이라면 보다 엄격한 문제 정책이 도움이 될 수 있습니다. 이미 Help (please use the forum) 와 같은 태그를 사용하고 있지만 이러한 유형의 항목이 더 많이 필요할 수 있습니다.

일반적으로 3명의 기여자가 현재 전체 볼륨에 압도되고 있는지 여부를 논의하고 조사하려는 몇 가지 유형의 문제 범위를 설명하는 것이 가장 좋습니다.

몇 가지 아이디어:

• suggestions 및 enhancements 작성 당시 (271)개의 미해결 문제가 있습니다. 이 레이블은 많은 소음을 발생시키는 것 같습니다. 실제 제안으로 전달된 PR 준비/확인만 수행할 수도 있습니다. 다른 모든 것을 인스타 닫고 Discussion (please use the forum) 로 표시하십시오.

• loaders 작성 당시 (61) 개의 미해결 문제가 있습니다. 이 레이블도 많은 소음을 발생시키는 것 같습니다. suggestions 및 enhancements 또는 잘못된 형식의 버그 보고서와 관련된 이 레이블에 많은 문제가 있습니다. 아마도 잘 구성된 버그 보고서와 PR 준비/제안을 위해 통과된 검사만 받을 수 있습니다. 다른 모든 것을 인스타 닫고 그에 따라 표시하십시오.

three.js 생태계의 모든 것이 글로벌 THREE.* 네임스페이스에 너무 의존적이어서 가져오기/내보내기 구문을 사용하거나 ES5로 변환하거나 번들러.

무엇이든 업데이트할 수 있다는 점에는 동의하지만 지속 가능한 방식으로 이러한 사용자를 계속 지원하기 위해 약간의 작업을 수행할 수 있는 방법을 찾을 수 있다면 @Bug-Reaper가 다음과 같이 말하는 데 동의합니다.

공동 작업을 더 잘 수행할 수 있도록 기본 리포지토리에 무언가를 보관할 수 있을 때 우리 모두가 별도로 번역/번들 워크플로를 만들지 않았으면 합니다.

우리는 이러한 사용자들이 응용 프로그램/라이브러리를 업그레이드하고 시스템 및 문서를 구축하는 데 드는 엄청난 시간을 집합적으로 절약할 것입니다.

이에 대해 조금 더 파고들고 싶습니다. 저는 많은 사용자 정의 도구를 작성하고 프론트 엔드 애플리케이션을 위한 자동화 스크립트를 작성했으며 제가 할 수 있는 모든 방법으로 기꺼이 도와드리겠습니다.

좋은.

전체 문제의 양을 줄이는 방법은 무엇입니까?

계속 진행해 주세요. 다른 스레드에서 더 논의하게 되어 기쁩니다. 그것은 다소 내 이전 의견 과 관련이 있습니다.

나는 @Bug-Reaper의 말에 동의합니다.

나는 우리 모두가 번역/번들 워크플로를 만들지 않았으면 합니다. [...]

나는 우리 모두가 이것에 동의한다고 생각합니다.

장점과 단점을 공유해주신 모든 분들께 감사드립니다. 정보에 입각한 결정을 내릴 수 있도록 이러한 정보를 공유하는 것이 좋습니다.

이것은 내가 올해에 두뇌 주기에 소비한 것이며 브라우저 공급업체에 우선 순위에 대해 물어보기까지 했기 때문에 미리 계획할 수 있었습니다.

ES6 모듈이 미래라는 데 동의하지만 가져오기 맵 없이 모듈을 사용하여 개발하면 큰 골칫거리를 야기하고 흐름을 완전히 깨뜨릴 수 있습니다. examples/js 사용을 중단하기로 결정했을 때 지도 가져오기가 더 많은 관심을 끌기를 기대했지만 현재로서는 브라우저의 우선 순위가 아닌 것 같습니다.

이 때문에 브라우저가 가져오기 맵을 구현할 때까지 examples/js 폴더 지원 중단을 중단하기로 결정했습니다. 나는 초보자가 첫 번째 큐브를 렌더링하기 위해 폴리필이나 번들러에 대해 배우도록 강요하는 것을 싫어합니다.

@Bug-Reaper와 같은 결론에 도달했습니다. 오늘은 examples/jsm 파일에서 examples/js 를 빌드하는 스크립트를 만드는 방법을 살펴보겠습니다.

@mrdoob

브라우저가 가져오기 맵을 구현할 때까지 examples/js 폴더 지원 중단을 중단하기로 결정했습니다.
@Bug-Reaper와 같은 결론에 도달했습니다. 오늘은 examples/jsm 파일에서 examples/js를 빌드하는 스크립트를 만드는 방법을 살펴보고 있습니다.

현명한 결정입니다.
👍

@mrdoob 물론 당신의 결정을 받아들이지만 기회를 놓친 것 같아요. 조만간 개발자는 글로벌 스크립트에서 멀어져야 합니다. 그리고 Import Maps 가 여기서 큰 차이를 만들지 않을 것이라고 생각합니다. 사용자를 더 나은 미래 보장형 워크플로로 "강제"하는 대신 글로벌 스크립트를 계속 사용할 수 있습니다. 2020년.

그리고 Import Maps 가 여기서 큰 차이를 만들지 않을 것이라고 생각합니다.

다른 날 나는 누군가가 이렇게 하는 것을 보았습니다.

<script src="js/three.js"></script>
<script src="https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>
<script type="module" src="js/main.js"></script>

그리고 main.js 내부에서 다음과 같이 했습니다.

import {OrbitControls} from "https://threejsfundamentals.org/threejs/resources/threejs/r119/examples/jsm/controls/OrbitControls.js";

그리고 실제로 효과가 있었던 것은... 😐

우리는 사용자가 올바른 일을 하기를 기대할 수 없습니다. 사용자는 학습하고 있으며 무언가가 작동할 때까지 시도하고 있습니다. 문제는 그들이 깨닫지 못하는 사이에 옳은 일을 할 수 있도록 도와주는 디자인을 찾는 것입니다.

가져오기 맵이 없는 ES6 모듈의 문제는 사용자가 OrbitControls.js 를 자신의 프로젝트에 있는 /js 폴더에 복사하고 이전처럼 가져올 수 없다는 것입니다. OrbitControls.js 가 ../../build/three.module.js 를 찾기 때문에 작동하지 않습니다.

가져오기 맵을 사용하면 OrbitControls.js 는 three 에서 가져옵니다. 사용자는 원하는 위치에 파일을 복사한 다음 가져오기 맵에서 경로를 조정할 수 있습니다.

가져오기 맵을 사용하면 "옛날"과 같이 파일을 쉽게 가져올 수 있습니다. 이전만큼 쉽지는 않겠지만 최소한 사용자는 파일을 가져오는 동안 순서에 대해 걱정할 필요가 없습니다. 무언가를 이기고 무언가를 잃습니다.

가져오기 맵을 사용하면 가져오기를 구성할 수 있고 따라서 더 유연하게 만들 수 있다는 데 동의했습니다. 사용자는 여전히 가져오기 맵을 조정해야 하지만(따라서 그것이 실제로 무엇인지 이해해야 합니다).

저는 "JS 파일을 폴더에 복사" 전체가 사악한 안티 패턴이라고 생각하고 새로운 사용자/초보자에게 CDN 가져오기 작업을 권장하여 이것을 방지할 수 있기를 바랐습니다. 어떤 이유로든 빌드를 사용하고 싶습니다.) 적절한 앱은 어쨌든 빌드 도구를 사용해야 합니다.

나는 정말로 안티 패턴으로 보지 않습니다.

그것이 내가 웹사이트를 만드는 방법을 배운 방법일 뿐입니다. .css 파일을 /css 폴더에 넣은 다음 이미지를 /img 에, .js 파일을 /js 에 넣습니다.

지난 몇 달 동안 나는 ES6 Modules/CDN 접근 방식을 사용하여 몇 가지 실험 을 했고 라이브러리가 내 프로젝트가 있는 곳과 다른 도메인에서 온 것이 기분이 좋지 않습니다.

파일을 복사하지 않을 때 한 가지 큰 손실은 파일을 편집할 수 있다는 것입니다. examples/js 의 파일은 항상 그 위에 빌드할 수 있는 예제여야 했습니다. 내 프로젝트에서 OrbitControls.js 를 복사했는데 내가 필요한 작업을 정확히 수행하지 않았다면 그냥 로컬 파일이었기 때문에 수정할 수 있었습니다.

이것이 내가 프로젝트를 설정하는 데 사용한 방법입니다.

<script src="js/libs/three.js"></script>
<script src="js/libs/three/OBJLoader.js"></script>
<script src="js/libs/three/OrbitControls.js"></script>
<script>
    console.log( THREE, THREE.OBJLoader, THREE.OrbitControls );
</script>

가져오기 맵을 사용하면 다음과 같이 표시됩니다.

<script type="importmap">
{
  "imports": {
    "three": "js/libs/three.module.js",
    "OBJLoader": "js/libs/three/OBJLoader.js",
    "OrbitControls": "js/libs/three/OrbitControls.js"
  }
}
</script>
<script type="module">
    import * as THREE from 'three';
    import { OBJLoader } from 'OBJLoader';
    import { OrbitControls } from 'OrbitControls';

    console.log( THREE, OBJLoader, OrbitControls );
</script>

예전만큼 예쁘지는 않지만 가져오기 종속성/주문을 처리하고 번들러가 필요하지 않습니다.

그러나 번들 기반 개발을 하는 사람들에게는 여전히 작동합니다. 사실, 애드온이 이제 ../../build/three.module.js three 에서 가져오기 때문에 더 좋습니다.

그리고 실제로 효과가 있었던 것은... 😐

FWIW 이것은 실제로 소량의 경우에만 작동하는 것 같습니다. 작동하지 않으면 매우 혼란스러운 방식으로 실패하고 빌드 프로세스에서도 발생하는 것과 관련된 몇 가지 문제가 제기되었습니다. 초보자가 동일한 파일을 사용하는 여러 가지 방법을 제공하는 것이 걱정된다면 틀림없이 오류가 발생하기 쉽고 혼란스러울 것입니다.

접할 수 있지만 콘솔의 경고를 통해 페이지에 두 개의 three.js 사본이 포함되어 있음을 사람들에게 알리는 것이 가치가 있을 수 있습니다(동일한 버전일지라도). 혼합하지 않도록 주의하지 않는 한 문제를 일으킬 수 있습니다. ~나는 React가 비슷한 이유로 이것을 한다고 믿습니다~ React는 실제로 이것을 오류의 가능한 소스로 가리킬 수 있습니다. 그것은 학습할 때 사람들이 이러한 양식을 혼합하지 않도록 하는 데 최소한 도움이 될 수 있습니다.

@Bug-Reaper와 같은 결론에 도달했습니다. 오늘은 examples/jsm 파일에서 examples/js를 빌드하는 스크립트를 만드는 방법을 살펴보고 있습니다.

이것이 새로운 계획이라면 모든 모듈 파일을 ES6 파일로 빌드하는 #15526 / #15543(지금은 프로젝트에서 삭제됨)을 되살리는 데 도움이 되었으면 합니다. 일부 예제가 너무 많은 파일(예: 셰이더 노드)에 퍼져 있고 일부 모듈을 여러 파일로 분할하는 데 관심이 있을 수 있다는 점을 감안할 때 변환하려는 파일의 명시적 목록을 가져오도록 롤업 스크립트를 업그레이드하는 것이 좋습니다. 및 출력. 출력되는 파일 사이에도 종속성을 자동으로 생성할 수 있어야 합니다.

파일을 복사하지 않을 때 잃는 것 중 하나는 파일을 편집할 수 있다는 것입니다.

나는 우리가 모든 수업에 참여할 수 있다면 다음과 같은 것을 희망하지만 동의합니다.

import orbitalcontrols from  orbitalcontrolsURL

class mycontrols extends orbitalcontrols {
// do the edits I care about
}

그리고 나중에

let controls = new myorbitalcontrols

파일을 복사하지 않을 때 잃는 것 중 하나는 파일을 편집할 수 있다는 것입니다.

나는 우리가 모든 수업에 참여할 수 있다면 다음과 같은 것을 희망하지만 동의합니다.

궤도 제어 URL에서 궤도 제어 가져오기

클래스 mycontrols는 orbitalcontrols를 확장합니다 {
// 내가 관심 있는 편집을 수행
}

그리고 나중에

let 컨트롤 = 새로운 myorbitalcontrols

부모 "클래스"가 간단한 js 함수인 경우에도 이미 할 수 있습니다!

실제로 작동하는 코드(디버거 빠른 테스트에서):

Promise.all([
    import('https://unpkg.com/three/build/three.module.js')
        .then( mod=> [mod.Camera, mod.WebGLRenderer] ),
    import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')
        .then( mod=> mod.OrbitControls )
])
.then( ([
    [ Camera, WebGLRenderer ],
    OrbitControls
])=> new ( class extends OrbitControls {} )( new Camera, (new WebGLRenderer).domElement )
)
.then( console.log )

... 또는 더 간단한 구문:

(async function() {

let { Camera, WebGLRenderer } = await import('https://unpkg.com/three/build/three.module.js')
,   { OrbitControls } = await import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')

class Con extends OrbitControls { }

let my = new Con( new Camera, (new WebGLRenderer).domElement )
console.log( my )

})()

aynom 함수와 async/await 약속에 대해 걱정하는 것 외에도 멋진

class mycontrols extend orbitalcontrols {
 // do the edits I care about
 }

이상적으로는 사용자에게 변경 시 원본 파일을 편집하도록 지시하기보다 승격해야 하는 패턴입니다. 그러나 예제는 확장성을 염두에 두고 작성되지 않았으므로 달성할 수 있는 것에 대한 강력한 제한이 있습니다. 내 경험에 따르면 결국 전체 원본 예제를 확장 클래스의 생성자에 복사하여 작동하게 하므로 extend 사용에 의미가 없습니다.

예를 들어, OrbitControls 에 대해 가장 일반적으로 요청되는 변경 은 pan 을 제한하는 것 입니다. 이것은 해당 스레드에서 @Mugen87 의 바이올린 에서 설명한 것처럼 쉽게 수행됩니다.

간단히 말해서 controls.update 메서드에서 minPan 및 maxPan 벡터를 추가하고 controls.target 를 클램프합니다.

OrbitControls 확장하여 이 작업을 수행했습니다. 확장 클래스를 만들 수 있으며 제대로 작동합니다. 그러나 변경을 시작하면 문제가 분명해집니다. 단순히 update 메서드를 확장할 수 없습니다.

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);
    }

    update() {
        super.update();
        console.log('Custom update function');
    }
}

이 확장 클래스는 작동하지만( glitch ), 이 새로운 OrbitControlsPanLimit.update 메서드는 무시됩니다. 원래 OrbitControls.update 방법이 계속 사용됩니다.

생성자에서 재정의하여 덮어쓸 수 있습니다.

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);

        this.update = () => {
            console.log('Custom update function');
        }
    }
}

여기서 super.update() 를 사용할 수 없으므로 유일한 옵션은 전체 원본 업데이트 방법을 복사하는 것입니다. 그러나 그 방법은 OrbitControls 내에서 이 많은 것을 사용합니다. 이는 모든 방법 간에 공유됩니다.

    //
    // internals
    //

    var scope = this;

    var changeEvent = { type: 'change' };
    var startEvent = { type: 'start' };
    var endEvent = { type: 'end' };

    var STATE = {
        NONE: - 1,
        ROTATE: 0,
        DOLLY: 1,
        PAN: 2,
        TOUCH_ROTATE: 3,
        TOUCH_PAN: 4,
        TOUCH_DOLLY_PAN: 5,
        TOUCH_DOLLY_ROTATE: 6
    };

    var state = STATE.NONE;

    var EPS = 0.000001;

    // current position in spherical coordinates
    var spherical = new THREE.Spherical();
    var sphericalDelta = new THREE.Spherical();

    var scale = 1;
    var panOffset = new THREE.Vector3();
    var zoomChanged = false;

    var rotateStart = new THREE.Vector2();
    var rotateEnd = new THREE.Vector2();
    var rotateDelta = new THREE.Vector2();

    var panStart = new THREE.Vector2();
    var panEnd = new THREE.Vector2();
    var panDelta = new THREE.Vector2();

    var dollyStart = new THREE.Vector2();
    var dollyEnd = new THREE.Vector2();
    var dollyDelta = new THREE.Vector2();

최종 결과는 거의 전체 원본 OrbitControls 을 OrbitControlsPanLimit 생성자로 복사해야 클래스 확장의 목적을 무효화한다는 것입니다. 확장성을 염두에 두고 컨트롤을 클래스로 작성하지 않는 한 확장이 가능하다고 생각하지 않습니다.

거기에 차임에 대해 @looeee 감사합니다. 나는 내 자신의 노력에서 쉬운 해결책을 놓쳤을 수도 있다고 생각했지만 이제 당신이 그것을 언급하고, 그것이 내가 스스로 일어섰던 부분입니다.

이상적으로는 사용자에게 변경 시 원본 파일을 편집하도록 지시하기보다 승격해야 하는 패턴입니다.

조심하세요. 상속 대 구성 인수에 대해 밀접하게 관련되어 있습니다.

이상적으로 라이브러리는 어떤 패턴도 홍보하지 않아야 합니다. 그것은 그것의 기능과 그것이 당신의 문제를 해결하는 것을 목표로하는 방법을 홍보해야합니다.

또한 개발자 워크플로, 스택, 빌드 시스템, 사용 사례를 가정해서는 안 됩니다. 훌륭한 도서관은 가능한 한 지역 사회의 복잡한 요구 사항을 수용합니다.

오늘 새로운 것은 내일이면 오래된 것이고 패턴은 왔다가 사라집니다. 유일한 상수는 가능한 한 많은 역호환성을 유지하기 위해 많은 사용 사례에 대한 훌륭한 지원을 제공하는 소프트웨어입니다.

Windows 10에서 DOS 게임을 계속 실행할 수 있습니다.

상속 대 구성 인수

제발 아니. 이 '인수'에 대한 해결책은 작업에 가장 적합한 도구를 사용하는 것입니다. 상속, 구성, 기능, 테스트 주도 등을 위한 장소가 있습니다.

우리는 다른 개발자가 three.js를 어떻게 사용(사용, 재사용, 수정)하는지에 대해 이야기하고 있으므로 js 브라우저 기능을 벗어나지 않고도 쉽게 이해하고 사용할 수 있는 패턴을 홍보하는 것이 유효합니다.

홍보한다고 해서 다른 스타일을 사용할 수 없는 것은 아닙니다.

가능한 한 많은 하위 호환성

예 및 아니오.

그것은 그것의 기능과 그것이 당신의 문제를 해결하는 것을 목표로하는 방법을 홍보해야합니다

아마도 우리가 명확하게하기 위해 당신을 위해 설정된 문제/기능은 무엇입니까?

또한 개발자 워크플로, 스택, 빌드 시스템, 사용 사례를 가정해서는 안 됩니다.

대부분 동의합니다. threejs 사용 사례는 현재 브라우저입니다. 내가 들은 바에 따르면 일부 로더가 일부 노드 애플리케이션에 유용하다는 경고가 있습니다.

그런 다음 유일한 상수는 그 과정에서 많은 사용 사례에 대한 훌륭한 지원을 제공하는 소프트웨어입니다.

변화는 계속된다. 개발자는 자신이 좋아하는 도구를 사용하고 때로는 다른 작업을 수행합니다.

여담으로:

그것은 그것의 기능과 그것이 당신의 문제를 해결하는 것을 목표로하는 방법을 홍보해야합니다

어느 것이 먼저 왔습니까? 기능, 패턴 또는 문제?
확실히 패턴은 문제를 해결하는 데 도움이 되었고 기능이 되었습니다.
...또는 문제를 만든 기능이었으며 문제를 해결할 패턴을 찾았습니까?

어느 것이 먼저 왔습니까? 기능, 패턴 또는 문제?

어느 것이 먼저 왔습니까? 암탉인가 달걀인가?
어떤 사람들은 수탉이 ...

훌륭한 토론, 모든 의견에 감사드립니다.

여러분이 ES6 예제 모듈을 트랜스파일하는 작업에 가장 적합한 번들러(롤업, 바벨, 소포, 웹팩 등)에 대해 어떻게 생각하는지 궁금합니다. 나는 @gigablox 가 여기서 경험이 있다고 언급했으며 다른 사람들도 마찬가지라고 확신합니다.

현재 저장소에는 이미 babel, 롤업 및 몇 가지 관련 플러그인이 포함되어 있습니다. 저는 오늘 밤에 해킹을 시작했고 공유할 매우 거친 롤업 구성 스크립트가 있습니다.

// jsm-transpiler.js
export default [
  {
    input: './examples/jsm/controls/OrbitControls.js',
    output: {
      banner:"//warning this file was generated automatically",
      file: './examples/js/controls/OrbitControls.js',
      name:'OC',
      footer:'THREE["OrbitControls"]=OC.OrbitControls',
      format: 'umd'
    }
  }
];

이 롤업 구성 스크립트는 실제로 OrbitControls 모듈을 THREE.OribitControls에 적절한 생성자를 할당하는 비모듈 .js 파일 포함으로 변환합니다. 작동했습니다. 멋지네요 :) ! 그것은 또한 40k 라인의 THREE.js를 출력 파일에 번들로 제공했습니다. 또한 OrbitControls 생성자를 THREE로 전송하는 데 도움이 되도록 OC라는 중간 전역 변수를 선언하여 전역 변수 공간을 느리게 오염시키고 있습니다.

롤업에는 우리의 많은 문제를 해결할 수 있는 정말 멋진 기능이 있는 것 같습니다. 특히 올바른 중첩 모듈이 포함/제외되도록 하기 위한 매핑 및 기타 컨트롤이 있습니다. header/footer/intro/output 속성을 통해 트랜스파일된 페이로드 전후에 코드를 삽입하는 기능.

나는 속임수를 쓴 롤업 구성 스크립트를 사용하여 필요한 것을 달성할 수 있다고 조심스럽게 낙관합니다. 그러나 많은 번들러 사이의 차이점을 연구/이해하는 사람이 여기에 무게를 둘 수 있다면 좋을 것입니다. 우리는 모듈이 더 훌륭 해짐에 따라 모듈을 처리하기 위해 상당히 강력한 것이 필요하고 일부 트랜스파일 코드는 다른 것보다 더 나을 것입니다.

이에 대한 제 의견은 다음과 같습니다.
https://github.com/mrdoob/three.js/pull/20529

이것은 약 30초 만에 모든 JSM 모듈을 JS 글로벌 네임스페이스 모듈로 변환하는 poc 사용자 정의 빌드 스크립트입니다. 이 방법으로 꽤 성공했습니다. 더 많은 테스트가 필요하지만 hello world에서 GLTFLoader와 같은 좀 더 복잡한 모듈을 시도했지만 괜찮았습니다.

노련한 RegExp 마법사의 도움을 받을 수 있습니다.

Chrome의 지도 가져오기 배송 예정:
https://groups.google.com/a/chromium.org/g/blink-dev/c/rVX_dJAJ-eI