<p>TypeScript 4.0 반복 계획</p>

실험 플래그 뒤에 https://github.com/microsoft/TypeScript/pull/29818 을 4.0에 포함하는 것을 고려하시겠습니까?

팩토리 함수 정의 자체의 변경으로 인해 복잡해집니다.

하지만 _separate_ 팩토리 가상 유형 정의를 도입하는 것은 흥미로울 수 있습니다. JSX.Factory 또는 React.JSX.Factory 라고 말하면 TypeScript가 추론에 사용할 수 있습니다. JSX 문법을 함수 호출로 번역하는 것이 충분하거나 효율적인지 확실하지 않지만 가상 유형이므로 구체적인 JavaScript 엔티티에 해당할 필요는 없습니다. 물론 위험은 현재 우리와 같은 상황에 처하게 되는 것입니다. 많은 가상 유형이 결국 어린이뿐만 아니라 React 15 이후에 도입된 여러 기능의 유형 안전성을 제한하게 되었습니다.

https://github.com/microsoft/TypeScript/pull/24738 도 4.0에 포함하는 것을 고려하시겠습니까?

#33038 [👍 140 and a real PR by your own @weswigham] 또는 #202 [👍 390]에 대한 언급이 없는 반면 #15230 [👍 27]과 같은 티켓은 "높은 수요"로 간주됩니다. "좋아요"를 기준으로 비교하거나 우선 순위를 지정할 수는 없지만 특히 4.0이 이와 같은 기능을 도입할 수 있는 좋은 기회인 것처럼 이에 대한 로드맵 업데이트가 있었다면 좋을 것입니다. 🙏

~3.5년 된 ​​문제로 거의 200개의 댓글과 함께 피드백을 기다리고 있습니다. Pwetty pwease 수정을 구현할 수 있습니까 🙏

로드맵과 반복 계획에 대해 주의가 필요하다고 생각하는 문제를 가끔 제기하는 사람들에게 감사하지만, 여기서 분명히 해야 할 필요가 있다고 생각합니다. "높은 수요가 많은 버그 수정 조사" 섹션은 그러나 범위에서 합리적으로 보였습니다. 우리는 여전히 언급된 문제를 염두에 두고 있지만 그 중 일부는 범위가 지정되지 않았거나 명확한 이상적인 결과를 얻지 못했습니다.

예:

• 명목상 브랜드가 좋겠지만 명목상의 미래 언어 방향으로 구성될까요? 나는 그것을 제안한 사람으로서 자리 표시자 유형에 대해 이러한 우려를 가지고 있습니다.
• 인덱스 서명의 undefined 는 흥미로운 것의 한 예이지만 현재 가정하에 이미 운영 중인 90%의 사람들을 더 어렵게 만드는 행동을 추가하고 싶지 않습니다. 사용자가 이러한 검사를 구성하고 점진적으로 채택할 수 있도록 하는 접근 방식을 찾는 것은 분명하지 않습니다. 많은 조건부 유형과 특수 컴파일러 검사로 기술적으로 가능하더라도 이러한 솔루션은 매우 명확하게 해킹되고 빠르게 분해되는 경향이 있습니다.

명목상 브랜드가 좋겠지만 명목상의 미래 언어 방향으로 구성될까요?

@DanielRosenwasser 당신의 비전에서 미래 언어 방향은 무엇입니까?

명목상 내 마음이 어디에 있는지에 대한 컨텍스트를 제공할 것입니다. 다음을 포함하여 명목 유형에 대해 질문할 때 사람들이 염두에 두는 다양한 아이디어가 있습니다.

• "전통적인" 선언 기반 명목성(예: 대부분의 OO 언어에서 볼 수 있는 것)
• 불투명 유형(내용이 외부에서 완전히 알려지지 않은 유형)
• 고유한 별칭(C/C++/C#의 단일 멤버 struct s, Haskell의 newtype , Kotlin의 인라인 클래스)
• 측정 단위(차원 분석을 언어로 인코딩하는 방법)

이들 중 일부 사이에는 음영이 있으며(예: 자리 표시자 유형 선언 - 구현 유형으로 대체되는 일종의 불투명 유형 변형), 각각을 함께 혼합하는 다른 방향이 있습니다.

@RyanCavanaugh 는 3명의 아이들이 부모에게 애완동물을 달라고 요청하는 것에 대해 훌륭한 비유를 했습니다. 하나는 개, 하나는 고양이, 하나는 물고기를 원합니다. 그들은 부모에게 "우리는 언제 애완 동물을 키울 수 있습니까?"라고 묻습니다. 분명히 그들은 모두 애완 동물을 원한다는 데 동의하지만 각각 다른 애완 동물을 원합니다!

브랜드 유형을 좋아합니까? 그래요! 브랜드 유형은 고유한 별칭과 같은 것을 달성하고 대부분의 사용자가 찾고 있는 것에 적합합니다. 하지만 그렇게 생각하는 것은 옳지 않다고 생각합니다. 많은 알려진 절충안으로 살을 붙일 더 많은 디자인 공간이 있으며 솔루션을 최대한 빨리 서두를 필요가 있다는 느낌을 주는 것은 없습니다.

https://github.com/microsoft/TSJS-lib-generator/pull/858 을 TypeScript 4.0 으로 가져올 수 있다면 좋겠습니다.

@DanielRosenwasser 먼저 작성해주셔서 감사합니다 🙇

명목형 유형이 실제로 TypeScript에 대해 다루는 사용 사례에 대해 조금 더 자세히 설명해 주시겠습니까?

첫째: 저를 거대한 텍스트 벽이나 리포지토리로 보내주십시오. 그러면 제가 읽을 것입니다.]

나는 자리 표시자 유형과 같은 불투명한 유형을 의미하는 것이 아니라 "전통적인" 명목 유형이라고 부르는 것을 의미합니다.

저는 항상 명목형이 JavaScript와 반대라고 느꼈고, 그래서 이전 시도가 제대로 작동하지 않았습니다. 꽤 잘 작동하게 하는 방법이 있으며(swift의 프로토콜과 haskell의 typeclasses는 "명목상이지만 외부에서 확장 가능"으로 생각합니다) 대부분의 "잘 확립된" 방법에 익숙할 것이라고 확신합니다. "측정 단위"가 F# 윙크라고 가정).

나는 명목형("전통적인") 유형을 요구하는 많은 사람들을 찾았지만 _why_에 대한 글은 많지 않습니다.

시간이 지남에 따라 "전통적인" 명목 유형을 요청하는 사람들이 점점 더 적어지는 것을 보았습니다. 아마도 커뮤니티가 집합적으로 구조적 유형에 대한 정신 모드를 구축했기 때문일 수 있습니다. 유형이 실제로 명목상으로 작동하는 곳이 있습니다( instanceof 가 관련되거나 private이 있을 때). 그 중 일부는 더 나은 제어 흐름 분석 및 호환성 검사로 캡처되지만 완벽하지는 않습니다.

"전통적인" 사용 사례 중 일부는 오버헤드가 없는 명목 래퍼 유형(예: newtype )의 경우와 동일하며 대부분 파일과 같은 항목에 대한 특수 처리를 보장하기 위한 것입니다. 경로, 신뢰할 수 없는 문자열 등

Typescript는 이미 충분히 표현력이 풍부한 것 같습니다. 개인적으로 보고 싶은 것은 더 나은 도구 통합입니다.

• ESM 지원 https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• 컴파일러 플러그인 https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• 원사 pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

위의 이유로 투박하고 해키한 솔루션을 보는 것이 일반적입니다. 대부분의 반응 프로젝트에는 react-hot-loader(컴파일러 플러그인)용으로 babel이 포함되어 있으며 일부 CSS 시스템에서는 컴파일 시간 변환을 위해 babel이 필요합니다. pnp, esm 또는 CSS 모듈을 사용하려면 tsc 제한에 대한 더 많은 도구와 해결 방법이 필요합니다.

또한 이러한 문제 중 일부에 대해 커뮤니티에서 PR 또는 제안의 형태로 구체적인 솔루션을 제공했지만 이러한 문제가 수년 동안 거부되거나 중단되었다는 사실도 실망스럽습니다. 실무자로서 더 넓은 생태계의 맥락에서 TS를 사용하는 것이 점점 더 어려워지고 있습니다.

어쨌든 나는 인터넷에서 무작위로 사람입니다.

@DanielRosenwasser 는 https://github.com/microsoft/TypeScript/pull/29374 가 4.0에 맞춰 검토될 수 있습니까? this -before- super 사례 중 많은(대부분?) 사람들이 궁금해하는 내용을 다루고 있다고 생각합니다.

파일 확장자가 포함된 파일 경로로 ES 모듈을 참조하는 지원을 포함하는 것을 재고하십시오. 다중 환경 코드의 경쟁 영역을 평준화하는 데 큰 도움이 될 것입니다.

https://github.com/microsoft/TypeScript/issues/16577

typescript 주변 도구에 집중해 주셔서 감사합니다! https://github.com/microsoft/tsdoc과의 긴밀한 통합을 고려할 수 있기를 바랍니다. go 및 Rust와 같은 다른 많은 현대 언어는 즉시 사용 가능한 문서 도구를 제공하고 개발자가 표준 주석을 작성하도록 권장하지만 이 점에서 typescript는 부족합니다.

#31445가 선택될 수 있다면 정말 좋을 것입니다. 이것은 우리에게 거래 차단기였으며 많은 사람들이 (해당 문제가 얼마나 많은 참조를 가지고 있는지에 따라) 믿습니다!

https://github.com/microsoft/TypeScript/pull/38967 은 TypeScript 4.0 에 포함될 수 있으며 https://github.com/microsoft/TypeScript/pull/35608 도 포함될 수 있습니다 .

사람들이 4.0 릴리스에 모든 것을 포함하도록 요청하고 있음을 발견했습니다 😆

TS가 기세를 잃는 것 같습니까? 다음 _major_, 4.0.0 릴리스에 대한 무효 병합 및 단락 할당? 더 이상 큰 목표와 야망 아이디어가 없습니까?

다음 전공의 경우 다음을 기대합니다.

• 고급 타이핑
• 종속 입력? 유형 수준 기능? (좋아, 이것은 5.0.0을 위한 것일 수 있다)
• 공칭 타이핑
• 마크로스
• tsconfig.json 의 변압기 지원
• WASM으로 컴파일(일부 언어 하위 집합)

@canonic-epicure 동의합니다. 현재 다음 버전에서는 3.10에 가깝습니다.

TS가 기세를 잃는 것 같습니까? 다음 주요 4.0.0 릴리스에 대한 병합 및 단락 할당을 무효화합니까? 더 이상 큰 목표와 야망 아이디어가 없습니까?

TypeScript는 semver를 따르지 않습니다. v0.10, v1.10, v2.10 또는 v3.10이 없습니다. 따라서 이것은 실제로 정상적인 이정표입니다. 사람들이 4.0에서 많은 변화를 기대하고 있지만 3.9 또는 이전 반복 계획에서 아무 말도 하지 않는 것은 조금 이상한 일입니다. 🙈

유형 수준 함수

type X<T> = T 는 어느 정도는 할 수 있습니다. (고차 함수를 지원하지 않습니다.)

마크로스

IMO는 Typescript의 목표를 충족하지 않습니다.

tsconfig.json의 변환기 지원

시도해보십시오: https://github.com/cevek/ttypescript

WASM으로 컴파일(일부 언어 하위 집합)

https://www.assemblyscript.org/ 를 찾고 있습니까?

좋습니다. 4.0.0은 다음 마이너 릴리스일 뿐입니다.

"매크로가 TS 목표를 충족하지 않음" 및 "변압기에 ttypescript 사용"( ts-patch 이 더 잘 작동함)과 관련하여 - 이것은 jedi 움직임과 유사합니다 - "이것은 당신이 필요로 하는 기능이 아닙니다". 아니요, 매크로와 변환기를 즉시 사용하십시오. 그것은 몇 년 전에 요청되었습니다.

나는 또한 TypeScript에서 marco를 원하지만 이것에 반대하는 이유는 정말 많습니다.

1. Marco가 다른 JavaScript 코드를 생성할 수 있는 경우 새로운 비유형 수준 구문을 생성하므로 ES 사양의 확장입니다. enum , import x = require(...) , module 는 이 규칙의 예외이지만 TypeScript 초기부터 왔습니다.

2. Marco를 사용하여 다른 파일을 교차하여 다른 JS 파일을 생성하려는 경우 JavaScript 파일을 가져오기 위해 모든 유형 구문을 멍청하게 삭제하는 것은 불가능합니다.

3. Marcos는 분석 및 컴파일 시간을 늘릴 수 있으며 남용될 가능성이 있습니다.

4. Marco가 유형 정보에 따라 다른 JS 파일을 내보낼 수 있다면 Babel이 이 구문을 처리할 수 없게 됩니다. 따라서 이 동작은 isolatedModules 규칙을 위반하는 것입니다(예외: const enum 및 module ).

5. Marco가 "유형 수준 Marco"만 수행할 수 있고 Babel에 의해 안전하게 지울 수 있다면 훨씬 쓸모없게 되지만 고차/프로그래매틱 유형에는 여전히 유용합니다. 따라서 목표를 위반한 것은 아니지만 TypeScript 팀이 이 아이디어에 관심을 가질지 의문입니다. (https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts에서 데모를 만들었습니다.)

@Jack-Works 나는 당신의 요점을 이해하지 못합니다. 아마도 매크로가 파서를 확장하고 새로운 synatx를 생성한다는 의미입니까?

나에게 매크로는 AST -> AST 기능으로, 이전 유형 검사기를 어떻게든 실행하므로 정기적으로 유형 검사를 받을 새 AST 노드를 생성할 수 있습니다. 그러나 새 구문을 생성하지는 않습니다. 입력은 일반 AST이고 출력도 마찬가지입니다. AST에서 새 노드를 생성합니다.

토론은 이 스레드에서 주제를 벗어나서 아마도 #compiler 채널에서 계속될 것입니다.

TypeScript 4.0에 #38597이 포함될 수 있습니까?

@DanielRosenwasser

인덱스 서명에 정의되지 않은 것은 흥미로운 예이지만 현재 가정하에 이미 운영 중인 90%의 사람들을 더 어렵게 만드는 동작을 추가하고 싶지 않습니다.

그게 90%의 사람들인지 어떻게 아는지 궁금합니다.

@wongjiahau 번호는 설명을 위해 아무렇게나 지어낸 것입니다. 그것이 당신이 묻는 특정 요점인지 확실하지 않습니다.

앞서가는 사람들처럼: 우리 팀은 6월 19일에 일하지 않으므로 일정을 조금 앞당길 것입니다. 베타는 현재 6월 25일 목요일까지 배송될 예정입니다.

@DanielRosenwasser 나는 당신이 Typescript의 첫 번째 목표와 명확하게 일치하는 기능(# 13778 )의 중요성을 부정하기 위해 임의의 숫자를 사용하고 있다는 점을 지적하려고 합니다.

오해하지 마세요. 핵심 팀이 이 프로젝트에 투입한 노고에 감사드립니다. 하지만 우리가 대신 이 프로젝트의 목표에 진정으로 부합할 수 있었다면 더 나은 성과를 낼 수 있었을 것이라고 생각합니다. 입증되지 않은 진술이 발전을 방해하도록 허용하는 것.

@wongjiahau 우리는 회의에 참석하지 않았고 "Daniel이 이 수치가 90%라고 말했습니다. 이는 우리의 임계값인 85%를 초과합니다. 절대 이 기능을 사용하지 맙시다"라고 말했습니다. 우리는 여전히 그것을 조사하고 있으며 이에 대한 개발자 수요를 잘 알고 있지만 실제로 이 기능이 어떻게 보이는지 테스트했으며 아름답지 않다고 말할 수 있습니다.

만약 당신이 우리로부터 이와 같은 진술을 과대 분석하려고 한다면 우리로부터 더 적은 수의 진술을 받게 될 것입니다. 왜냐하면 우리는 인터넷에서 적극적으로 잘못 해석되는 것보다 더 나은 일이 있기 때문입니다.

4.0은 "3.9의 다음 버전"이 아니라 확실히 이정표입니다.

@typescript-bot 생성 릴리스-4.0

@DanielRosenwasser님 , 여러분을 위해 release-4.0 브랜치를 만들기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

@Kingwl 이것이 이정표라면 그 큰 일이나 적어도 영웅 기능은 무엇입니까? 이 문제의 맨 위에 있는 언어 기능 목록에서 그런 훌륭한 것을 볼 수 없습니다. 대부분의 3.x 릴리스와 비교할 때 특이한 점은 없습니다.
물론 메이저 버전의 출시가 필요한 브레이킹 체인지라고 말할 수도 있겠지만, '마일스톤'이라고 하기는 어렵다.

@wgebczyk 제 생각에는 레이블이 지정된 튜플 요소가 있는 가변 튜플이 이정표입니다.

@wgebczyk 신경 쓰지 마세요. 그러나 실제로 Variadic Tuple은 그렇습니다.

@xiaoxiangmoe @Kingwl 마일스톤 ? 인치 스톤.

거기에 있습니다: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
언제 안정화 버전에 도달합니까? 매일 VS Code로 코딩할 때 이것을 적용하고 싶습니다.

@mk0y 8월 18일에 대한 오프닝 메시지 에 따르면.

@wgebczyk 릴리스는 시간 기반입니다. 각 릴리스에는 약 3개월 간의 팀 작업이 포함됩니다. 우리의 마일스톤 버전 관리 정책(n = n + 0.1)은 지난 20개 릴리스에서 일관되었으므로 언젠가는 이것이 사람들에게 놀라운 일이 아니길 바랍니다 😅

다음 마이너 릴리스에서 인덱싱을 위해 symbol 유형을 허용하는 것을 고려하시겠습니까? pull request 26797 을 구현하고 병합할 수 있습니까?

@DanielRosenwasser님 , 저는 release-4.0 4.0.1-rc 로 업데이트하기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

@typescript-bot 동기화 릴리스-4.0

@DanielRosenwasser님 , 마스터와 release-4.0 동기화를 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

@typescript-bot 동기화 릴리스-4.0

@DanielRosenwasser님 , 마스터와 release-4.0 동기화를 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

@weswigham mmmmmmmmmmmmmmmmmm 봇이 나를 싫어합니다 ): ): ): ):

전혀 서두르지 않지만 수동으로 수행하고 다음을 제출했습니다. https://github.com/microsoft/TypeScript/issues/39869

어딘가에 4.0 이후에 대한 로드맵이 이미 있습니까? 점점 더 수요가 증가하고 있기 때문에 #37582를 강화하고 싶습니다(#39965, #38149, #27481, #39965, #38546). 그것은 나에게 합리적인 범위의 문제처럼 보입니다.

업데이트와 마찬가지로 웹 사이트 출시 및 기타 변경 사항을 위해 RC에 착륙해야 한다고 생각하는 2일까지 RC를 옮겨야 했습니다. 우리는 우리를 훨씬 더 뒤로 미룰 것으로 예상하지 않지만 안전을 위해 RC에 대한 피드백을 얻기 위해 2일을 더 주고 대신 20일을 목표로 할 것입니다.

@typescript-bot 범프 릴리스-4.0

@DanielRosenwasser님 , 저는 release-4.0 4.0.2 로 업데이트하기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

8월 20일입니다 :)

헐 아직 8월 19일인데 지금부터 20분이라도 더 기다려야 할 것 같다. 1분만 더 시간을 내실 수 없다면 npm에서 야간 릴리스를 제공합니다! 😄

릴리스를 기다리고 있습니다. 이미 npm에 나와 있습니다 :)

@typescript-bot 범프 릴리스-4.0

@DanielRosenwasser님 , 저는 release-4.0 4.0.3 로 업데이트하기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

@typescript-bot 범프 릴리스-4.1

@DanielRosenwasser님 , 저는 release-4.1 4.1.1-rc 로 업데이트하기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

안 돼

@typescript-bot 범프 릴리스-4.0

@DanielRosenwasser님 , 저는 release-4.0 4.0.4 로 업데이트하기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.

@typescript-bot 범프 릴리스-4.0

@DanielRosenwasser님 , 저는 release-4.0 4.0.5 로 업데이트하기 시작했습니다. 다음은 로그에서 가장 잘 추측할 수 있는 링크 입니다.