Definitelytyped: 왜 모노레포인가?

1. types 아래의 폴더로 직접 이동할 수 있습니다. 예를 들어 jquery 의 유형을 보려면 https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery 로 이동
2. 도서관명을 검색할 수 있습니다. 예를 들어 lodash 와 관련된 미해결 문제를 검색하려면 https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% 로 이동

모노레포 완전 엉망 아닌가요?

가장 쉬운 방법은 TypeSearch 를 사용하는

Non-monorepo는 nonstarter입니다. 종종 하나의 @types 패키지에서 무언가를 수정하는 기여자는 중단을 수정하거나 새로운 기능을 활성화하기 위해 여러 다운스트림 패키지를 수정해야 합니다. 이는 모든 PR을 기반으로 합리적인 CI 빌드를 실행하면서 원자적 방식으로 해당 PR을 병합하는 통합된 방법이 없기 때문에 GitHub의 워크플로에 대한 절대적인 쓰레기 수거통 화재입니다. 당신이 4000 개 폴더를보고 생각하는 문제의 경우, 우리가 4000 개의 repos에서 동기화 GitHub의 설정을 유지하기 위해 노력하고 상상한다.

종종 하나의 @types 패키지에서 무언가를 수정하는 기여자는 중단을 수정하거나 새로운 기능을 활성화하기 위해 여러 다운스트림 패키지를 수정해야 합니다.

@types/ 패키지를 작성하는 데 익숙하지 않으므로 누락된 것이 있을 수 있습니다.

그러나 그것이 semver 를 위한 것 아닙니까?
npm의 다른 패키지와 비교하여 @types/ 패키지를 구현하는 것이 특별한 이유는 무엇입니까?

나는 그것이 동일하게 작동하기를 기대합니다 : 당신이 가지고있는 의존성 그래프. 패키지 @types/X 및 @types/Y 를 사용하는 다운스트림 패키지 @types/X . 둘 다 다른 사람들이 관리합니다. @types/X 변경되면 다른 버전으로 게시되므로 @types/Y 즉시 영향을 미치지 않습니다. @types/Y 기고자는 나중에 @types/X 의 최신 버전으로 업데이트하기로 결정하고 모든 주요 변경으로 인한 문제를 수정합니다.

아마 그 위에 DefinitelyTyped meta-repository가 있을 것입니다. 이는 type-repos에 대한 링크 목록만 유지 관리합니다. 그런 다음 해당 목록을 살펴보고 @types/ npm-namespace 아래에 모든 패키지를 게시하는 publisher 스크립트가 있습니다.

또는 가능한 경우 구현자가 @types 네임스페이스 바로 아래에 게시하도록 허용합니다. 따라서 DefinitelyTyped meta-repo가 ​​전혀 필요하지 않습니다.

https://github.com/npm/npm 도 2k 문제입니다.
https://github.com/moby/moby 더.

가장 좋은 해결책은 저자가 항상 권장하는 정의를 유지하는 것입니다.

@franklinyu 문제의 수는 문제의 대상이 아닙니다. 이 리포지토리가 >4k 타이핑을 집계한다는 점을 고려하면 엄청난 수의 문제가 문제가 되지 않습니다.

진짜 질문은 DefinitelyTyped 가 하나의 저장소에 모든 타이핑을 집계하여 해결하려는 문제는 무엇입니까?

불행히도 semver는 타이핑 패키지에 잘 작동하지 않습니다. 유형 패키지의 major.minor 버전은 자바스크립트 패키지의 major.minor 와 일치해야 합니다. 그렇지 않으면 사람들은 주어진 자바스크립트 패키지 버전에 어떤 @types 버전을 사용할지 모릅니다.

예를 들어 지금 당장 [email protected] 를 설치하면 @types/[email protected] (지금 4.14.109 )도 설치됩니다. 그러나 lodash 유형에 버그가 있다고 상상해보십시오. (이는 매우 자주 발생합니다) 누군가 수정합니다. 이제 버전 번호를 무엇으로 범프합니까? 정의에 따르면 유형 정의에 대한 모든 변경은 인터페이스 중단 변경(또는 최소한 인터페이스 추가)입니다. 그러나 이러한 유형은 4.14 가 아니라 4.15 4.14 이기 때문에 버전을 4.15.0 올릴 수 없습니다. 그리고 우리는 확실히 버전 번호를 5.0.0 로 올리고 싶지 않습니다. 따라서 인터페이스 변경이 있더라도 버전 번호를 4.14.110 변경합니다. 실제로 이전 인터페이스가 정확하지 않았기 때문입니다.

@ AJ-R 좋아, major.minor 버전 @type/X 동일해야 major.minor 버전 X 및 버그가있는 경우 @type/X patch 버전을 사용하여 수정합니다. 맞아요.

그것이 원래 질문과 어떤 관련이 있습니까? monorepo 대 개별 repos?

죄송합니다. 분명히 말했어야 했습니다. 이전 의견 중 하나를 언급하고 있었습니다.

하지만 그것이 _semver_를 위한 것이 아닙니까?

한 리포지토리에 모든 입력을 집계하여 확실하게 유형이 해결하려고 하는 문제는 무엇입니까?

DT를 4,000개의 개별 GitHub 저장소로 분할하면 어떤 문제가 해결 됩니까?

TypeScript 팀원은 매일 수십 개의 PR을 병합하거나 검토하면서 PR 백로그를 관리합니다. 봇은 우리가 받는 엄청난 양의 PR을 감시합니다. 우리는 일반적인 오류를 잡아내는 리포지토리 전체 린트 규칙을 실행하고 도움이 될 것으로 생각되면 정기적으로 새로운 린트 규칙을 켭니다. 우리는 미래의 컴파일러 버전에 의해 깨진 것들로 정의를 찾아 수정합니다.

이것을 수천 개의 하위 리포지토리로 나누면 모든 것이 더 어려워지고 다른 것은 더 쉬워집니다. 왜 우리가 그것을 할까요?

DT를 4,000개의 개별 GitHub 저장소로 분할하면 어떤 문제가 해결됩니까?

1. 사용자는 소스에 더 빨리 도달합니다. 소스에 도달하기 위해 TypeSearch와 같은 추가 앱을 사용할 필요가 없습니다. npm에는 필요한 타이핑 리포지토리에 대한 직접 링크가 있습니다.

2. 사용자로서 현재 문제를 확인하고 새 문제를 제출하는 것이 더 쉽습니다.

   • 2,000개 이상의 문제가 있는 하나의 거대한 저장소를 검색하고 필터링할 필요가 없습니다. 기자가 문제 명명 규칙(예: [@types/name-of-package] Issue description )을 준수하는 것을 잊어버리면 어떻게 됩니까? 필요한 문제를 찾지 못합니다.
   • 따라서 중복 파일을 제출할 가능성이 적습니다.

3. 기여자는 저장소에 얼마나 많은 문제가 있는지 명확하게 모니터링할 수 있습니다.

   • 구체적인 타이핑에 대한 문제를 얻기 위해 (다시) 아무 것도 필터링할 필요가 없습니다. 필요한 문제를 놓칠 가능성이 적습니다.
   • 문제 수를 낮게 유지하려는 분명한 동기가 있습니다. 문제 번호는 더 이상 공동 책임이 아닙니다.
   • 따라서 몇 년 동안 걸려 있는 문제를 잊어버릴 가능성이 적습니다.
     예. 2013년 1호 페이지, 2014년 5호 등이 있습니다.

4. TypeScript 팀원으로서 당신은 많은 npm 패키지에 대한 수천 개의 타이핑을 유지/병합/검토하는 대신 typescript 자체 개선(예: jsdoc 지원)에 더 많은 시간을 할애했습니다.
   성숙한 생태계에서는 그것이 커뮤니티가 해야 할 일입니다.

   • 일반적인 오류를 잡아내는 repo 전체 린트 규칙을 실행합니다.

     모든 권장 규칙으로 린트 사전 설정을 해제하고 모든 기여자에게 해당 사전 설정의 최신 버전을 사용하도록 조언합니다.

   • 우리는 미래의 컴파일러 버전에 의해 깨진 것들로 정의를 찾아 수정합니다.

     그것이 커뮤니티 기여자들이 해야 할 일입니다. 예상되는 ts-compiler의 버전은 Typing-package package.json 의 peerDependency 섹션에 명시되어 있어야 하므로 잘못된 환경에서 사용할 경우 경고를 해준다.

타이핑은 실제로 누구에게나 소유 되어 있다는 사고방식에서 접근하고 있습니다. 현실은 이 리포지토리에 있는 대부분의 파일이 dts-gen을 실행하고 몇 가지 수정을 통해 체크인한 사람이 한 번 작성한 다음 다른 세 사람이 1년에 한 번 수정했다는 것입니다. 여기에는 강력한 소유권 모델이 없으며 그럴 필요도 없습니다.

이러한 저장소 중 하나의 임시 자체 선언 "소유자"가 유지 관리를 중단하기로 결정하면 어떻게 됩니까? 이것은 항상 발생

이것은 또한 수정 사항을 제출하려는 사람들의 삶을 악화시킵니다. 작년에 우리는 수백 개의 파일에서 다운스트림 변경이 필요한 유형 매개변수를 React 정의 파일에 추가했습니다. 광범위한 변경을 수행하고 수백 개의 동시 pull 요청을 관리하기 위해 수백 리포지토리(오, 어떤 리포지토리?)를 복제하고 싶은 사람이 있습니까? 이를 위한 도구조차 어디에도 없습니다.

TypeScript 팀원으로서 당신은 많은 npm 패키지에 대한 수천 개의 타이핑을 유지/병합/검토하는 대신 typescript 자체 개선(예: jsdoc 지원)에 더 많은 시간을 할애했습니다. 성숙한 생태계에서는 그것이 커뮤니티가 해야 할 일입니다.

우리는 문자 그대로 이것을 시도했지만 작동하지 않았습니다. DT는 전적으로 커뮤니티 중심이었고 수백 개의 풀 요청 백로그가 발생했습니다. 그 이후로 PR 볼륨이 ~200/월에서 ~1,000/월로 감소했음에도 불구하고 PR을 병합하는 평균 시간이 2주에서 4일로 감소했습니다(이는 의도적인 최소값이므로 사람들이 변경 사항에 무게를 둘 시간이 있음). .

좋아, 나는 "왜 monorepo?"라는 원래 질문에 대한 답을 가지고 있다고 생각합니다.
TypeScript 팀이 유형 정의를 유지하는 것이 더 쉽기 때문입니다(유형 종속성, 다운스트림 패키지에 대한 원자적 업데이트, CI, 린팅 등 고려).

저는 여전히 TypeScript 팀이 수천 개의 패키지를 대부분 단독으로 유지 관리하는 데 중요한 역할을 하는 모델이 약간 이상하다고 생각합니다. 특히 모듈식 커뮤니티 기반 npm 세계에서.

그러나 이 모델이 당신에게 적합하다면. 그럼 좋아 : 스마일 :

@art-in 이 하나의 저장소에서 모든 유형을 관리하는 것이 의도가 아니라고 생각합니다. 패키지 자체에서 제공하지 않는 유형을 관리하기 위한 것입니다. 패키지가 해당 패키지의 유형을 게시하려는 경우 패키지에서 바로 그렇게 할 수 있습니다. ConfirmTyped는 원래 패키지 관리자의 동의 없이 유형을 집계할 수 있는 곳일 뿐입니다.