그래서 그들 중 누구도 Svelte 파서를 사용하지 않습니까?

svelte2tsx는 스타일/스크립트 태그를 제거한 다음 svelte 컴파일러를 사용하여 htmlx 부분을 구문 분석합니다.
svelte-ts는 svelte 컴파일러를 두 번째 단계로 사용합니다.
현재 언어 서버는 구문 분석을 위해 svelte 컴파일러를 사용하지 않습니다.
초기 게시물을 업데이트하겠습니다.

이것을 공유해야하는지 확실하지 않았지만 일부는 유용 할 수 있습니다. 작년(2019년 7월/8월) 나는 그저 배우기 위해 버리는 일을 하고 있다는 것을 알고, 타입체킹 Svelte를 가지고 놀기 시작했습니다. 그것은 전체 솔루션의 알 수 없는 양(아마도 30%)을 지원하며 몇 가지 제한 사항이 있습니다(나중에 자세히 설명). 항상 막다른 골목이라고 생각했기 때문에 테스트나 외부 문서가 없습니다.

Svelte 컴파일은 유형 검사가 아닌 TS 전처리기를 사용하여 오늘날과 같이 진행됩니다. 스크립트 태그뿐만 아니라 HTMLx 마크업에 유형이 필요한 경우 이를 처리하기 위한 전처리기가 필요합니다. 그렇지 않으면 Svelte에서 TS를 내부적으로 처리해야 합니다.

typechecker는에서 해제 전처리 타이프 스크립트 코드를 사용하는 별도의 빌드 단계입니다 script 블록에서 마크 업 AST svelte.compile 위해 가상 벨테 타이프 스크립트 파일을 만들 목적으로 유형 검사만을. (여기에 Rollup 플러그인 이 가상 파일을 생성 한 다음 typechecks하는 곳입니다. ) @halfnelson 의 전략과 유사하지만 TSX가 아닌 일반 TS를 생성한다는 점에서 다르므로 마크업에서 HTML 태그 및 typecheck를 시도하지 않습니다. 속성, 콧수염 태그 및 Svelte 구성 요소 내부의 항목만. Svelte 구성 요소를 props와 함께 new 받는 생성자로 변환합니다. Svelte의 구성 요소를 많이 지원하는 과정에서 어느 정도 진행했지만 의도한 것보다 더 많은 작업이 진행되고 있으며 더 나아가 진지한 엔지니어링이 진행되어야 한다는 사실을 깨달았습니다.

TypeScript 컴파일러 API는 메모리에 프로그램 을 검사 하는 데 사용됩니다. Svelte와 달리 세계관은 개별 파일이 아니라 전체 프로그램입니다. 그 당시에는 향후 최적화로 증분 컴파일 및 작업자 스레드를 추가하는 것이 간단할 것 같았습니다.

가상 Svelte TS 파일은 원본 Svelte 소스에 TypeScript 진단을 다시 매핑 하는 데 사용되는 생성됩니다 . 유형 오류가 Svelte 소스를 가리키는 것을 보는 것은 꽤 멋졌지만 나는 전반적으로 내 접근 방식에 확신이 없었습니다.

내가 알아낼 수 없었던 한 가지 문제는 일부 경우에 충분히 구체적이지 않은 진단과 관련된 것이었습니다. IIRC의 예는 유형 검사 Svelte 구성 요소 생성자 소품이었습니다. VSCode는 어떻게 든 개별 소품 오류를 가리킬 것이지만 내가 받고 있던 TS 진단은 문제 속성이 아닌 생성자만 가리켰습니다.

코드를 살펴보면 부분이 엉망이고 일부 주석이 구식일 수 있다는 점에 유의하십시오. 나는 원래 magic-string 를 사용했고 어느 시점에서 source-map . 그리고 그것은 처음부터 운명적인 노력이었다는 것을 기억하십시오! 이 모든 것은 master 아니라 해당 repo의 ts 분기에 있습니다.

위에서 언급한 4개의 파일은 다음과 같습니다.

• virtualSvelteTs.ts
• typecheck.ts
• tsDiagnostics.ts
• 롤업-플러그인-svelte-typescript-checker.ts

현재 svelte 언어 서버의 소스 코드를 파헤쳤습니다. 타이프스크립트 부분에 대한 제 생각은 다음과 같습니다.

개요

언어 서버는 다음과 같이 광범위하게 작동합니다.

• DocumentManager 는 열리는 모든 문서를 처리합니다.
• TypescriptPlugin 는 DocumentManager 에 등록하여 언어 서버 이벤트("doHover" 등)에서 호출됩니다. 직접 등록하지 않습니다. wrapFragmentPlugin 래핑되어 TypescriptPlugin 가 script 태그 내부의 내용만 가져오도록 합니다. 위치 매핑(마우스/텍스트 커서)은 wrapFragmentPlugin 에서 수행되어 정보가 올바른 위치에 표시되도록 합니다.
• TypescriptPlugin 는 typescript 언어 서비스 래퍼 service 를 사용합니다. 기본적으로 모든 이벤트를 이 언어 서버에 위임하며 일부 매핑은 메서드 반환 유형을 따릅니다.
• service 는 TypescriptPlugin 의 createDocument 메서드와 함께 작업을 수행할 문서를 가져옵니다. service 는 현재 기본적으로 DocumentsManager 문서에 대한 대리자일 뿐인 자신의 문서 맵을 유지합니다. service 가 TypescriptPlugin 에서 호출될 때마다 service service 는 문서 맵을 주어진 문서로 업데이트합니다(랩핑 후). createDocument 는 언어 서비스가 아직 문서 맵의 일부가 아닌 문서를 열면 호출되지만, 이것은 typescript 언어 서비스가 다른 svelte 모듈을 찾지 않기 때문에 발생하지 않습니다(다음 섹션 참조).

현재의 단점과 개선을 위한 아이디어

• script 태그는 typescript 언어 서비스에 있는 그대로 부여되기 때문에 특수한 svelte 구문($)을 처리할 수 없습니다.
• typescript 언어 서비스는 현재 열려 있는 svelte 파일에서 참조되는 다른 파일을 조회하려고 합니다. .ts / .js 파일의 경우 작동하지만 .svelte 파일의 경우 작동하지 않습니다. 이유: typescript 언어 서비스는 .svelte 끝을 알지 못하므로 일반 typescript 파일이라고 가정하고 ../Component.svelte.ts 와 같은 파일을 검색하는 것은 잘못된 것입니다. 이 문제를 해결하기 위해, 우리는 방법을 구현해야 resolveModuleNames 에서 LanguageServiceHost 모든 라우팅 .svelte.ts 에 파일 조회 .svelte . 그러면 언어 서비스가 모든 svelte 파일을 탐색합니다. 참고: 이를 구현하려면 다음 버그도 수정해야 합니다. 이제 typescript 언어 서비스가 모든 파일을 검색하므로 createDocument 에서 TypescriptPlugin createDocument 를 호출합니다. 그러나 이것은 현재 script 태그 안의 내용뿐만 아니라 전체 문서를 반환합니다. 이것은 openDocument 래핑하지 않는 wrapFragmentPlugin 내부의 버그입니다.
• svelte component import 이름을 클릭하여 "go to svelte file"과 같은 고급 기능을 구현하거나 typescript를 $ 기호로 만들려면 전처리기를 추가해야 합니다. 이 전처리기는 어떤 식으로든 typescript에 누락된 부분을 추가합니다. 이상적으로는 모든 추가 항목을 기존 코드 위에 추가할 수 있으므로 위치 매핑이 오프셋으로 위치를 매핑하는 것만큼 쉽습니다. 그러나 이것은 또 다른 문제를 제기합니다. 이제 두 개의 위치 매핑이 있습니다. 하나는 전체 svelte 파일에서 스크립트 태그로, 다른 하나는 스크립트 태그에서 전처리된 typescript 코드로입니다. 이 시점에서 이것이 갈 길인지 아니면 TypescriptPlugin (및 다른 사람들)이 문서를 가져오는 방법을 다시 작업해야 하는지 확실하지 않습니다. 스크립트 태그 추출과 전처리가 모두 한 단계로 완료되어야 합니다. . 이것은 wrapFragmentPlugin 변경하거나 완전히 대체하는 것을 의미합니다. 재작업에 대한 또 다른 주장은 "사용하지 않는 기능"과 같은 것을 올바르게 결정하기 위해 html 부분을 고려해야 하므로 스크립트 태그가 충분하지 않다는 것입니다.

생각?

resolveModuleNames 에서 TypeScript 팀 구성원이 Vetur를 위해 한 방법과 Svelte에 대해 수행 한 유사한 버전이 있습니다. 여기 에는 효과가 있었지만 Vetur를 복사하는 것이 더 나은 대안 전략을 언급하는 주석이 포함되어 있습니다.

@dummdidumm 기술 책임자 역할을 하고 이러한 문제를 특정 문제로 분류해도 될까요? 나는 기꺼이 개발 시간을 자원 봉사할 것이지만, 나는 이것이 압도적으로 많다는 것을 알게 되었고 작고 정의된 문제에서 더 잘 작동할 것입니다. 수행해야 하는 큰 아키텍처 변경이 없는 한(아니요?)

기본적으로 많은 문제를 공개하고 사람들이 이를 주장하고 이에 대한 비공식 기술 리더로 관리하게 하십시오. 해주겠다고 했는데 솔직히 아직 고통은 못느꼈어요 하하

또한 https://github.com/sveltejs/svelte/issues/4518을 탐색하는 다른 사람들을 위해 orta의 원래 LSP 게시물에 링크합니다.

물론 이 일을 돕고 싶지만 지금은 언어 서버에 대해 매우 흥분하고 코드를 파헤치고 몇 가지 제안을 하는 무작위 친구입니다. 😄 또한 코드에 익숙해지려면 시간이 더 필요합니다. 아키텍처 및 일반적으로 lsp. 하지만 나는 분명히 앞으로 나아갈 의향이 있습니다. @orta 당신이 이 repo의 관리자이기 때문에 이에 대해 어떻게 생각하십니까?

👋 예, 우리 둘 다 그냥 관심을 갖고 있는 무작위 사람들입니다. 저는 "이것이 더 나아야 한다"는 가려움을 유발할 수 있는 날렵한 코드베이스조차 가지고 있지 않습니다. 그래서, 나는 어떤 움직임이라도 보게 되어 매우 기쁩니다 - @dummdidumm - 밀어 돌아가는지 확인하도록 노력하겠습니다.

큰 확인! 계속해서 일부 PR을 통해 코드의 일부를 재구성하고 준비하여 개별 항목에 대한 작업을 병렬화할 수 있습니다.

어쩌면 우리는 @ryanatkn , svelete-ts 의 접근 방식 및 eslint-plugin-svelte3 의 가변 접근 방식을 결합할 수 있습니다.

1. svelte 전처리 를 사용하여 스크립트를 js로 전처리하십시오.
   여기서 우리는 가능한 한 적은 변형을 수행하기 위해 최신 또는 다음 버전의 ES로 변환할 수 있습니다.
2. svelte가 전처리된 소스를 컴파일 하도록 합니다.
3. 그런 다음 injected = true 결과 변수를 인스턴스 ts 소스 또는 ts AST에 주입한 다음 소스 맵과 함께 사용하여 유형 확인 및 자동 완성을 제공할 수 있습니다.

스크립트에는 모듈 <script context="module"> , 인스턴스 및 콧수염(템플릿)의 세 부분이 있을 수 있습니다. 지금은 콧수염 부분을 모두 template.js에 덤프할 수 있습니다. 그러나 장기적으로 ryanatkn의 접근 방식과 같이 템플릿을 tsx 또는 일반 t에 반영할 수 있습니다.

module = true 인 모듈 변수는 template.js 및 인스턴스에 주입되지만 그 반대는 아닙니다.

이런 식으로 우리는 typescript AST에서 반응 변수 $: a = 1 또는 $-prefixed store를 찾는 방법을 다시 구현할 필요가 없습니다. svelte 컴파일러에 의해 주입된 이러한 변수는 최상위 문에서 파생되며 최신 ES로 변환합니다. 따라서 대부분 typescript로 이름을 바꾸지 않아야 합니다.

반응 변수 $: a 대해 다음과 같이 작성할 수 있습니다.

$: a = 1

```t
하자: 번호
$: a = 1

```ts
$: a = someFunction(b) as Type

변환하기 전에 변환할 필요가 없는 유효한 ts입니다.

그리고 $-prefixed store svelte/store get 과 같은 일반 함수를 생성하여 저장소 유형을 추출할 수 있습니다.

/** injected */
let $store = getType(store)

1. svelte 전처리 를 사용하여 스크립트를 js로 전처리하십시오.
   여기서 우리는 가능한 한 적은 변형을 수행하기 위해 최신 또는 다음 버전의 ES로 변환할 수 있습니다.
2. svelte가 전처리된 소스를 컴파일 하도록 합니다.
3. 그런 다음 injected = true 결과 변수를 인스턴스 ts 소스 또는 ts AST에 주입한 다음 소스 맵과 함께 사용하여 유형 확인 및 자동 완성을 제공할 수 있습니다.

나는 svelte-ts가 그런 일을 한다고 생각합니다. 좋은 생각인 것 같습니다. injected = true : 이 속성이 정확히 어떤 코드에 있습니까?

스크립트는 모듈 <script context="module"> , 인스턴스 및 콧수염(템플릿)의 세 부분을 가질 수 있습니다. 지금은 콧수염 부분을 모두 template.js에 덤프할 수 있습니다. 그러나 장기적으로 ryanatkn의 접근 방식과 같이 템플릿을 tsx 또는 일반 t에 반영할 수 있습니다.

module = true 인 모듈 변수는 template.js 및 인스턴스에 주입되지만 그 반대는 아닙니다.

이런 식으로 우리는 typescript AST에서 반응 변수 $: a = 1 또는 $-prefixed store를 찾는 방법을 다시 구현할 필요가 없습니다. svelte 컴파일러에 의해 주입된 이러한 변수는 최상위 문에서 파생되며 최신 ES로 변환합니다. 따라서 대부분 typescript로 이름을 바꾸지 않아야 합니다.

따라서 파일을 가상 .ts -file과 .template -file로 분할하시겠습니까? .ts 하단에 콧수염 부분이 없는 이유는 무엇입니까? 이렇게 하면 "사용하지 않는 방법" 경고도 제거할 수 있습니다. AST를 걷을 때: 예, 템플릿에서 참조되는 모든 것이 스크립트의 최상위 수준이어야 하기 때문에 여기에서 현명하게 AST를 너무 많이 살펴보는 것을 건너뛸 수 있다고 생각합니다.

반응 변수 $: a 대해 다음과 같이 작성할 수 있습니다.

$: a = 1

let a: number
$: a = 1

또는

$: a = someFunction(b) as Type

변환하기 전에 변환할 필요가 없는 유효한 ts입니다.

유형을 유추할 수 있습니까? 아마도 이것은 우리가 그대로 두는 것이며 사용자가 typescript를 사용하려면 let a: number 직접 정의해야 합니다. 대안으로 let a; 삽입할 수 있지만 any 됩니다.

그리고 $-prefixed store svelte/store get 과 같은 일반 함수를 생성하여 저장소 유형을 추출할 수 있습니다.

/** injected */
let $store = getType(store)

예, 좋은 것 같습니다. 내가 가진 또 다른 아이디어는 getter/setter를 구성하는 것이었습니다.

나는 svelte-ts가 그런 일을 한다고 생각합니다. 좋은 생각인 것 같습니다. injected = true : 이 속성이 정확히 어떤 코드에 있습니까?

컴파일 결과에는 vars 속성이 있습니다. 이 속성은 다음 속성을 가진 객체의 배열입니다.
이름, export_name, 주입, 모듈, 변형, 재할당, referenced_from_script 및 쓰기 가능
자세한 정보는 svelte compile api를 볼 수 있습니다.

그래서 파일을 가상 .ts 파일과 .template 파일로 나누시겠습니까? .ts 파일의 맨 아래에 콧수염 부분이 없는 이유는 무엇입니까? 이렇게 하면 "사용하지 않는 방법" 경고도 제거할 수 있습니다.

이것은 eslint-plugin-svelte3 의 접근 방식입니다. 또한 언어를 지정하는 속성이 없기 때문에 템플릿에서 ts를 지원하고 싶다고 생각했습니다.

유형을 유추할 수 있습니까?

이 가상 소스는 유형 확인 및 자동 완성용으로만 사용되기 때문에 초기화를 위해 첫 번째 assign 문을 복사하는 것만으로 달성할 수 있지만 더 많은 작업이 필요할 것 같습니다.

유형을 유추할 수 있습니까? 아마도 이것은 우리가 그대로 두고 사용자가 typescript를 사용하려면 let: number를 직접 정의해야 합니다. 대안으로 let;을 삽입할 수 있지만 그러면 any가 됩니다.

정상적인 추론이 우리를 거기까지 데려다주지 못하는 것 같습니다. (컴파일 시간 추론을 의미했나요? 작동할 수 있는지 확실하지 않음)

let a; // type is "any" initially
$: a = 5;
a; // type is now "number", good
const cb = () => a; // type is implicitly "any", noo

그 이유는 선형 코드 흐름에서 TypeScript가 a 가 재할당되지 않은 것을 볼 수 있지만 중첩된 함수 범위에는 그러한 보장이 없고 TypeScript는 유형 안전성 측면에서 오류가 발생한다는 것을 알 수 있기 때문입니다.

놀이터 예

바로 이것이 내 걱정거리였다. 그러나 @jasonlyu123이 지적했듯이 정의( = 뒤의 모든 것)를 복사할 수 있습니다.

전에

$: a = true;

후에

let a = true;
$: a = true;

그러나 그것이 모든 상황에서 가능한지는 모르겠습니다. 특히 누군가가 인터페이스를 구현하는 큰 개체의 경우 사용자가 예상하는 대로 모든 것을 추론할 수는 없습니다. 또한 복사 파스타가 꽤 커질 수 있습니다. 그래서 저는 여전히 "사용자가 입력하게 하라"는 편입니다.

명확히 해 주셔서 감사합니다. @jasonlyu123이 말한 것을 오해했습니다. 그것은 내가 언급한 중첩된 함수 범위 문제를 수정합니다.

그것이 좋은 기본 동작이 아닌 경우의 예가 있습니까? 대부분의 경우 인체 공학적인 작업을 수행하는 것처럼 보이며 다른 경우는 수동으로 고칠 수 있습니다. 다음은 몇 가지 예입니다.

음, 당신 말이 맞는 것 같아요. 가장 인체공학적인 것입니다. 내가 걱정한 것은 유추된 유형이 잘못된 경우입니다. 예를 들어 속성은 정의된 문자열 조합( 'a' | 'b' ) 대신 string 입니다. 그러나 당신이 말했듯이 이러한 경우는 그렇게 일반적이지 않으며 사용자는 여전히 수동으로 입력할 수 있습니다.

"훌륭합니다. 명시적 let 구문이 훌륭합니다."와 같은 부분이 있습니다. 하지만 이는 기본적으로 JS 지원과 함께 작동하지 않게 될 것입니다.

첫 번째 레이블을 다음과 같이 바꾸면 어떻습니까?

$: a = 1
$: a = 2

변신하다

/** injected  */
let a = 1
$: a = 2

나는 조금 다시 생각하고 " $: 를 let 바꾸기"보다 "복사 정의"의 이점을 찾을 수 없습니다. $: 를 let 로 바꾸면 어떤 단점이 있는지 생각해 볼 수 있습니까?

사용자가 예상한 것과 유추된 유형 차이에 대해 수동 정의로 변환하는 리팩토링 작업을 제공할 수 있습니까? 이 작업은 매뉴얼 유형 등의 변수를 사용자에게 메시지를 표시합니다 이 그 추론 유형 가능한 경우에, 또는 리팩토링을.

~ 전에

$: a = 'const1'

~ 후에

let a : AskUserForType
$: a = 'const1'

지적하신 부분에 대해서도 생각하고, 배운 점 👍

하, 현명한 생각입니다. $: 를 let 완전히 바꾸십시오. 나는 그것이 나쁘게 끝날 어떤 상황도 모른다.
우리는 또한 첫 번째 레이블뿐만 아니라 항상 변환을 수행하는 것에 대해 생각할 수 있습니다. 그런 다음 사용자에게 "이 변수를 두 번 정의했습니다"라는 힌트를 주는 "재선언할 수 없음" 오류가 발생합니다. 아니면 이것이 실행 가능하고 실수가 아닌 상황이 있습니까?

좋습니다. 라벨 교체도 실패할 이유가 없다고 생각합니다. ( break $ 는 할당 내에서 작동하지 않기 때문에 맞습니까?)

동일한 반응 변수를 다시 선언하기 위해 Svelte가 이를 허용하는 것처럼 보이며 예상대로 순서대로 작동합니다. ( 이 repl 예제 참조 ) 저는 개인적으로 이 패턴을 의도적으로 사용하는 것을 보지 않고 오류를 원하지만 Svelte의 의미론을 해석하는 영역에 있으므로 내 말을 받아들이지 마십시오!

다시 선언하면 실제로 작동하는 패턴입니다. 나는 우리가 그것을 허용하는 것이 더 낫다고 말할 것입니다 - 또는 기본적으로 꺼져있는 "허용되지 않음 재선언"기능 플래그를 나중에 만드십시오.

@halfnelson 은 https://github.com/halfnelson/svelte-type-checker-vscode 에서 자신의 svelte2tsx 접근 방식을 기반으로 언어 서버를 만들었습니다. 이 모든 것이 이미 얼마나 잘 작동하는지 정말 좋아하지만 tsx를 중간 출력으로 사용하지 않는 것을 선호합니다. 너무 느리고 몇 가지 제한 사항이 있을 수 있기 때문입니다. 하지만 그건 제 직감일 뿐입니다. 그래도 svelte2tsx: 구문 분석-컴파일링-변환의 흐름이 수행되는 방식과 광범위한 테스트 제품군에서 많은 것을 얻을 수 있습니다. 다른 사람들은 코드를 tsx로 변환하는 접근 방식을 어떻게 보고 있습니까?

나는 다른 변형이 어떻게 생겼는지에 대해 생각했습니다. 여기 몇 가지 예가 있어요. 피드백 환영합니다.

구성 요소 정의의 모양

원래의:

<script>
    import { createEventDispatcher } from 'svelte';
    const dispatch = createEventDispatcher();

    export let todo: string;

    function doneChange() {
        dispatch('doneChange', true);
    }
</script>

변환됨:

export default class Component {
   constructor(props: {todo: string; 'on:doneChange': (evt: CustomEvent<boolean>) => void}) {}
}

import { createEventDispatcher } from 'svelte';
const dispatch = createEventDispatcher();

export let todo: string;

function doneChange() {
    dispatch('doneChange', !todo.done);
}

설명:
어떻게든 모든 props(쉬움) 및 디스패치된 이벤트(hard)를 가져와 하나의 큰 props 객체에 추가합니다. on: -prefix를 사용하여 이벤트를 추가하면 충돌을 최소화하고 자동 완성 제안을 더 쉽게 구현할 수 있습니다.

(다음 예에서 구성 요소 정의는 간결함을 위해 생략됩니다.)

템플릿에서 변수 사용

원래의:

<script>const bla = {bla: 'bla'};</script>
<p>{bla.bla}</p>

변환됨:

const bla = 'bla';
const _bla = bla.bla;

설명:
변수의 올바른 사용법을 확인하고 "사용하지 않음" 경고를 없애기 위해 임의의 const 요소를 추가합니다. 그런 다음 사용하지 않는 _bla -warning ...

네이티브 이벤트 리스너 사용

원래의:

<script>function bla() {return true;}</script>
<button on:click={bla}>bla</button>

변환됨:

function bla() {return true;}
const btn = document.createElement('button');
btn.addEventListener('click', bla);

설명:
네이티브 이벤트 리스너를 사용하는 경우 해당 요소를 생성한 후 이벤트 리스너를 추가합니다. 이런 식으로 우리는 addEventListener -typings를 활용합니다. 여기에는 거의 모든 리스너에 대한 오버로드가 있습니다. .addEventListener('click', ...); -> 이벤트는 MouseEvent 유형입니다. 이 패턴은 요소가 이벤트가 정의된 또 다른 svelte 구성 요소인지 확인한 후 사용됩니다(다음 예제 참조). 단점: Svelte가 웹이 아닌 환경(Nativescript)에서 사용된다면?

다른 구성 요소 사용

원래의:

<script>
import Bla from './bla.svelte';
function blub() {}
</script>
<Bla bla={1} on:blubb={blub} />

변환됨:

import Bla from './bla.svelte';
function blub() {}
const bla = new Bla({bla: 1, 'on:blubb': blub});

설명:
모든 구성 요소에는 클래스 정의가 있으므로 해당 클래스를 인스턴스화하면 됩니다.

각 루프

원래의:

{#each todos as todo,i (todo.id)}
    <p>{todo.text}</p>
{/each}

변환됨:

todos.forEach((todo, i) => {
    const _todoText = todo.text;
});

설명:
forEach 는 변환하기 가장 쉬운 것 같습니다. 내부에서는 다른 모든 기능을 재귀적으로 적용할 수 있습니다.

만약에

원래의:

{#if x === 1}
    <p>if</p>
{else if x === 2}
    <p>elseif</p>
{else}
    <p>else</p>
{/if}

변환됨:

if (x === 1) {

} else if (x === 2) {

} else {

}

설명:
꽤 자명합니다.

누락된 조각

• 슬롯
• 특별 svelte:x 구성품
• use:action , transition , bind 와 같은 다른 요소/구성 요소 지시문
• $-구문

여러분은 어떻게 생각하세요? 이러한 변환이 실행 가능하고 실행 가능한가? 내가 뭐 놓친 거 없니?

구성 요소 클래스에 대해 svelte의 자체 SvelteComponent 클래스를 확장하는 것을 선호하지만 이것이 구현하기 쉬운지 여부는 모르겠습니다.

import { SvelteComponent } from "svelte";

export default class Component extends SvelteComponent {
    constructor(options: ComponentOption<{ propA: string }>) {
        super(options)
    }

    $on(
        event: 'input',
        callback: (event: CustomEvent<string>) => void
    ): () => void
    $on(
        event: 'click',
        callback: (event: CustomEvent<number>) => void
    ): () => void 
    $on(
        event: string,
        callback: (event: CustomEvent<any>) => void
    ): () => void {
        return () => { }
    }
}

이러한 인터페이스를 가져옵니다.

interface ComponentOption<TProps, TSlot = undefined> {
    target: Element,
    props: TProps | SlotProp<TSlot>
}

type SlotOption<T> = [unknown, unknown, unknown]

interface SlotProp<TSlot> {
    $$slots: Record<string, SlotOption<TSlot>>
}

$$slots 는 아마도 svelte의 내부 API일 것입니다. 컴파일된 코드에서 가져왔습니다.

그 이유는 바닐라 ts/js를 입력하는 데 사용할 수 있는 .d.ts 를 내보내는 데 사용할 수 있기 때문입니다.
또한 충분히 이상하지만 이것은 유효한 구문이기 때문에:

<script>
onMount(() => {
    new Component({
        target: document.getElementById('foo')
    })
})
</script>

요소 지시문

Transition , use:action 및 기타 요소 지시문은 다음과 같이 변환할 수 있습니다.

fade(null as Element, {  } /* option in attribute*/)

기다리다

{#await promise}
    <p>...waiting</p>
{:then number}
    <p>The number is {number}</p>
{:catch error}
    <p style="color: red">{error.message}</p>
{/await}

에게

    promise.then(number => {  number })
    promise.catch(error => { error.message })

바인딩:이

<script>
let a;
</script>
<div bind:this={a}><div>

에게

let a;
onMount(() => {
 a = document.createElement('div')
})

즉시 사용할 수 없기 때문에 콜백으로 래핑해야 함

컨텍스트="모듈"

이건 좀 까다롭다

<script context="module">
 let count = 1;
</script>

<script>
import _ from "lodash"
let b;
</script>

로 컴파일해야 합니다.

import _ from "lodash"

let count = 1;

// any block is ok
{
    let b;
{

또한 사용자가 모듈의 js와 인스턴스의 t와 같이 두 개의 스크립트에서 다른 언어를 사용한다면 어떻게 될까요?

좋아, 좋아. "템플릿에서 변수 사용"의 경우 const _bla = bla.bla; 는 "사용하지 않는 var" 진단을 걸러낼 필요 없이 TypeScript가 검사를 수행하도록 하는 bla.bla; 수 있습니다. 나는 이것이 작동하지 않는 코너 케이스를 생각할 수 없습니다.

Vue 팀 중 일부는 typescript 언어 서버 플러그인을 탐색 중입니다 - https://github.com/znck/vue-developer-experience

오늘날 이러한 경험이 TypeScript 외부와 내부(vetur가 하는 것처럼 자체 tsserver-ish 및 html/css/etc LSP를 실행하기 때문에) 또는 TypeScript 내부에서 외부로 작업하려고 시도하는 것은 흥미로운 각도입니다( 예를 들어 이 제안) .vue 파일이 비 TS 코드를 마스킹하여 합법적인 TypeScript라고 효과적으로 믿도록 TSServer를 조작하는 경우.

오늘날에는 타이프스크립트에 패치가 있어야만 작동할 수 있지만

흥미로운 접근 방식입니다. 그러나 html 또는 css에 대한 자동 완성과 같은 기능은 어떻게 작동할까요? 이 모든 것을 "수동으로" 구현하고 기본 언어 서버에 더 이상 의존하지 않아야 합니까, 아니면 제가 놓치고 있는 것이 있습니까?

한 번 이상 하는 것의 장점이 있습니까?

JS/TS 지원 이외의 모든 것은 별도의 vscode LSP에서 처리됩니다. 이 확장이 JS/TS에 대한 모든 지원을 제거하고 나머지만 처리하면 typescript 플러그인이 나머지를 처리하는 것과 같습니다.

이 경우 "무료"로 모든 TS 도구를 얻을 수 있다는 이점이 있습니다. 기호, 파일 매핑 등으로 이동합니다.

나는 아마도 그것을 권장하지 않을 것입니다. 오늘날에는 진입 장벽이 상당히 높은 TypeScript의 포크나 패치가 필요합니다. 그리고 TypeScript 팀은 컴파일러 플러그인이 그런 종류의 액세스 권한을 가질 수 있는지/언제까지 확신할 수 없습니다.

통찰력 주셔서 감사합니다. 나는 우리가 현재의 접근 방식을 가지고 있다고 말할 것입니다(outside-in).

위에서 논의한 "가상 ts 파일 만들기" 접근 방식을 사용하는 경우 이를 구현하고 소스 매핑을 유지하려면 어떻게 해야 합니까?

오늘날에는 "스크립트 시작 찾기, 스크립트 끝 찾기", "스크립트 부분 추출" 및 "가느다란 파일의 오프셋을 위치에 추가" 매핑을 위해 간단하기 때문에 쉽습니다.
지금 스크립트 부분을 변경하면 더 정교한 매핑이 필요합니다.

원래의

<script lang="typescript">
  let a = 1;
  $: b = a + 1;
</script>
<p>{b}</p>

매핑됨:

export default class Bla extends SvelteComponent { ... } // <- prepended, no mapping needed as far as I know
let a = 1; // <- untouched
let b = a + 1; // <- modified in place. How to map? Do we need to adjust all following code positions now to have a new offset/position?
b; // <- appended. Needs mapping from {b} inside svelte-mustache-tag to here. We can get the original position from the html ast which is part of the output of svelte.parse

어떤 아이디어? 소스 매핑 작업을 한 번도 해본 적이 없습니다.

Vue 팀 중 일부는 typescript 언어 서버 플러그인을 탐색 중입니다 - https://github.com/znck/vue-developer-experience

오늘날 이러한 경험이 TypeScript 외부와 내부(vetur가 하는 것처럼 자체 tsserver-ish 및 html/css/etc LSP를 실행하기 때문에) 또는 TypeScript 내부에서 외부로 작업하려고 시도하는 것은 흥미로운 각도입니다( 예를 들어 이 제안) .vue 파일이 비 TS 코드를 마스킹하여 합법적인 TypeScript라고 효과적으로 믿도록 TSServer를 조작하는 경우.

오늘날에는 타이프스크립트에 패치가 있어야만 작동할 수 있지만

제거 TypeScript 패치 PR이 병합됩니다.
https://github.com/znck/vue-developer-experience/pull/7

그래서 ... @orta 이것은 "비공식"에 관한 단점이 더 이상 아님을 의미합니까? 아니면 패치가 아니라 package.json 구성을 통해 알아야 하고 언제든지 변경할 수 있는 일종의 비공식적입니까?

또 다른 주제: 현재로서는 이 최선의 접근 방법에 대해 여전히 논의 중이며, 결정하면 구현하는 데 시간이 걸릴 것입니다. 그동안 svelte2tsx 을 사용하는 것에 대해 어떻게 생각하십니까? 이것은 아주 좋은 출발점 역할을 할 수 있고, 우리는 이것에 대해 몇 가지 테스트를 할 수 있고, 그런 다음 우리는 "이것은 실제로 잘 작동합니다. 변경하지 말자"라고 확인하거나 점진적으로 마이그레이션할 수 있습니다. 생각?

예, TS의 기본 흐름을 편집하는 두 가지 방법이 있었습니다. 여전히 TypeScript를 패치하고 있지만 런타임 에는 TS의 기능을 교체합니다. 플러그인 개발이 아직 로드맵에 포함되지 않은 점을 고려하면 합리적이라고 생각합니다.

그래도 추천한다면 나쁜 핵심 팀원이 될 것입니다 ;)

svelte2ts 시도하는 것은 탐색을 위한 좋은 방법인 것 같습니다!

이 vscode 플러그인을 사용하여 svelte2tsx가 어떤 것인지 확인할 수 있습니다. https://marketplace.visualstudio.com/items?itemName=halfnelson.svelte-type-checker-vscode 와 Svelte Beta(svelte 베타를 비활성화하면 가장 잘 작동 두 번 힌트를 얻지 않도록 typescript 옵션 :) )

svelte2tsx를 사용하지 않더라도 typescript를 만족스럽게 유지하려면 svelte의 JS 코드에 어떤 변환을 수행해야 하는지에 대한 논의가 있습니다. svelte2tsx 커버에 대한 테스트 스위트가 아니라이 템플릿을 만들 수 필요한 변경뿐만 아니라, 당신은 스크립트 태그하려는 경우 스크립트 태그는, 유일한 해결책은 좋은 출발점이 될 수 있습니다 https://github.com/halfnelson /svelte2tsx/tree/master/test/svelte2tsx/samples

htmlx2jsx 는 템플릿 변경 테스트(htmlx) 폴더이고 svelte2tsx 샘플은 svelte의 js 구문 남용에 필요한 svelte 특정 변경 사항입니다. :)

https://github.com/pivaszbs/svelte-autoimport 리포지토리를 방금 발견했습니다. svelte2tsx 독립적인 인텔리센스 가져오기를 원하는지 살펴볼 가치가 있습니다.

이 프로젝트의 전반적인 방향이 대부분 정리되고 깔끔하게 진행되는 지점에 있다고 생각합니다. 피드백을 위해 일주일을 주겠지만 지금은 구조적으로 다시 생각할 필요가 없어 매우 기쁩니다.

아무도 이의를 제기하지 않는 것 같으니 이만 마치겠습니다. 토론해 주셔서 감사합니다!