마이크로소프트, 이갈리아, 블룸버그 그들은 며칠 전에 다음과 같이 발표했습니다. 구문을 포함하는 주도권을 잡았습니다. 사양의 명시적 유형 정의에 대해 TypeScript 언어에서 사용되는 구문과 유사한 JavaScript.
현재 ECMAScript 표준에 포함하기 위해 제안된 프로토타입 변경 사항은 예비 논의를 위해 제출되었습니다(0단계).
오늘 우리는 선택적이고 지울 수 있는 유형 구문을 JavaScript에 제공하기 위한 새로운 Stage 0 제안에 대한 지원과 협력을 발표하게 된 것을 기쁘게 생각합니다. 이 새로운 구문은 주변 코드가 실행되는 방식을 변경하지 않기 때문에 주석처럼 효과적으로 작동합니다. 이것이 모든 규모의 개발에 TypeScript를 더 쉽고 빠르게 사용할 수 있도록 하는 잠재력이 있다고 생각합니다. 우리가 이것을 추구하는 이유와 이 제안이 높은 수준에서 어떻게 작동하는지에 대해 이야기하고 싶습니다.
t에서 언급된다.명시적 유형 정보를 갖는 것은 개발 과정에서 많은 오류를 방지하고, 추가 최적화 기술을 사용하고, 디버깅을 단순화하며, 타사 개발자가 코드를 더 읽기 쉽고 쉽게 수정 및 유지 관리할 수 있는 기회를 제공합니다.
그 외에 선택적 기능으로 유형 지원을 구현하는 것이 제안됩니다. 유형 검사를 지원하지 않는 JavaScript 엔진 및 런타임은 유형 정보가 있는 주석을 무시하고 이전과 같이 코드를 처리하여 유형 데이터를 주석으로 인식합니다. 그러나 유형 검사 도구는 사용 가능한 정보를 기반으로 잘못된 유형 사용과 관련된 오류를 감지할 수 있습니다.
배경
JavaScript 세계에서 우리 팀이 본 최근 경향은 더 빠른 반복 시간과 감소된 빌드 단계에 대한 요구입니다. 즉, "더 빠르고 간단하게 만드십시오".어떤 면에서 이것은 이미 일어나고 있습니다. 에버그린 브라우저의 성공 덕분에 개발자는 종종 이전 런타임에서 실행하기 위해 최신 버전의 JavaScript를 컴파일하지 않아도 됩니다. 어느 정도는 번들링도 마찬가지입니다. 대부분의 브라우저에는 모듈 사용에 대한 지원이 내장되어 있으므로 번들링은 필요 이상으로 최적화 단계로 볼 수 있습니다. 이것은 점점 더 사실이 되었는데 TypeScript는 어떻게 버틸까요?
동시에, 지정된 유형 정보와 달리 주석으로 지정된 JSDoc 주석을 통해 직접 사양 변수 정의 구문에서 직접 유형의 코드를 더 시각적이고 이해하기 쉽고 편집하기 쉽게 만듭니다..
예를 들어 TypeScript 지원 IDE는 추가 변환 없이 작성된 JavaScript 코드의 오류를 즉시 강조 표시할 수 있습니다. 또한 내장된 유형 지원을 통해 한 언어에서 다른 언어로 변환하지 않고도 TypeScript 및 Flow와 같은 스크립트로 작성된 JavaScript 방언으로 작성된 프로그램을 실행할 수 있습니다.
유형 중 변수, 함수 매개변수, 객체 요소, 클래스 필드, 형식화된 배열("숫자[]")을 정의할 때 사용할 수 있는 "문자열", "숫자" 및 "부울"을 추가하는 것이 좋습니다. 또한 혼합 유형("문자열 | 숫자") 및 제네릭에 대한 지원을 제공하도록 제안되었습니다.
이 모든 것을 감안할 때 우리는 TC1의 다음 2022년 39월 총회에서 XNUMX단계에 대한 이 제안을 발표할 계획입니다. 우리는 이 제안의 공동 챔피언인 Bloomberg의 Rob Palmer와 Igalia의 Romulo Cintra의 지원과 지도로 그렇게 할 것입니다.
1단계에 도달하면 표준 위원회가 ECMAScript에 대한 호환 가능한 유형 구문을 고려할 가치가 있다고 생각합니다. 이것은 확실하지 않습니다. 위원회 내에는 많은 가치 있는 관점이 있으며 우리는 어느 정도 회의론이 있을 것으로 예상합니다. 이와 같은 제안은 많은 의견과 적절한 조사를 받게 됩니다. 그 과정에서 많은 설계 변경이 포함될 수 있으며 결과를 얻는 데 몇 년이 걸릴 수 있습니다.
다음 회의에서 XNUMX월 TC39 위원회의 첫 번째 단계로 이동할 예정입니다. ECMA 전문가 커뮤니티의 참여로 제안 고려.
최종적으로 그것에 대해 더 많이 알고 싶다면 당신은에서 세부 사항을 확인할 수 있습니다 다음 링크.