Typescript: 커스텀 트랜스포머를 위한 플러그인 지원

우리는 단기적으로 컴파일러 플러그인 시스템을 공개할 계획이 없습니다. 변환은 귀하가 언급한 대로 공개 API의 일부로 노출되며 우리는 이에 대한 문서와 샘플을 작성하는 중입니다.

노출된 플러그인 API를 원하지 않습니다. 대신 TS-Compiler API를 사용하는 대신 tsconfig.json에 지정하여 사용자 지정 변환을 등록하는 방법을 선호합니다. TS-Compiler API를 사용한다는 것은 더 이상 tsc 명령줄 도구를 사용할 수 없다는 것을 의미하기 때문에 더 이상 기존 빌드 도구 및 워크플로에 제대로 통합되지 않는다는 것을 의미할 수 있습니다.

문서 및 샘플에 대한 업데이트가 있습니까? @mhegazy

@MichaReiser API를 기반으로 간단한 컴파일러를 작성할 수 있습니다(샘플 여기 ). 우리는 실제로 야후 파이낸스 내에서 TS를 매우 많이 사용하며 트랜스포머 공개 API는 훌륭했습니다.

다음은 공개된 후 작성한 변환기 중 일부입니다.
https://github.com/longlho/ts-transform-system-import
https://github.com/longlho/ts-transform-img
https://github.com/longlho/ts-transform-react-intl
https://github.com/longlho/ts-transform-css-modules-transform

샘플 문서화/수집에 도움이 필요한 경우 @mhegazy lmk

@longlho
샘플 주셔서 감사합니다.

그것이 제가 현재 하고 있는 일입니다. 그러나 웹 팩 로더, jest 로더와 같이 typescript용으로 생성된 다른 빌드 도구를 사용하는 것은 불가능합니다. 게다가 우리 각자가 다른 프론트엔드를 사용할 때 플러그인 중 하나를 내 플러그인 중 하나와 함께 사용하려면 어떻게 해야 합니까?

따라서 현재의 접근 방식이 좋은 시작이지만 플러그인 생태계에는 충분하지 않다고 생각합니다. 플러그인을 사용하는 것은 사용자에게 너무 많은 노력이 필요하고 작성자를 위한 변환 코드를 작성하는 것 이상의 작업이 필요하기 때문입니다.

저는 커뮤니티가 커스텀 트랜스포머를 만들고 사용하도록 장려하는 것이 목표라면 Babel과 같은 플러그인 시스템이 typescript에 필수적이라고 믿습니다.

@MichaReiser 네 . 생태계에 충분하다고 말하는 것이 아니라, 생태계를 향한 첫 걸음을 내딛기에 충분합니다.

gulp-typescript의 변환 지원을 추가하고 싶지만 모든 TypeScript 플러그인(gulp, webpack 등)이 다른 API를 제안하는 것을 방지하고 싶습니다. 그리고 TypeScript는 나중에 이것을 구성하기 위한 다른 방법을 추가할 수도 있습니다. 그래서 현재 가까운 장래에 이것을 추가할 계획이 있습니까?

안녕 모두, 나는 전처리기를 작성하려고 노력하지만 아무것도 나오지 않습니다 :[

사실 두 가지 질문이 있습니다.

• 문자열에서 AST 조각을 만드는 방법은 무엇입니까?
• 가져오기를 추가하는 방법?

// 1. Input
class Foo {
    templateString = 'some value';
}

// 2. After transformation
import __LIB__ from '@external/lib';

class Foo {
    templateString = (function compiledTemplate(deps) {
        // ...
        return result;
    })({lib: __LIB__});
}

// 3. Expected result
var lib_1 = require("@external/lib");
var Foo = (function () {
    function Foo() {
        this.templateString = (function compiledTemplate(deps) {
            // ...
            return result;
        })({ lib: lib_1 }); 
    }
    return Foo;
}());

단순화된 예: https://github.com/RubaXa/typescript-api-questions/tree/master/import-add

⬆️ ⬆️ ⬆️
@longlho , @mhegazy 힌트를 줄 수 있습니까?

@RubaXa 변환에 가져오기 선언을 추가했으므로 바인딩되거나 유형이 확인되지 않습니다. 바인딩되지 않았거나 유형이 확인되지 않았기 때문에 표현식의 __LIB__ 를 선언의 __LIB__ 로 해석할 수 없습니다.

한 가지 옵션은 기본 가져오기 대신 네임스페이스 가져오기를 사용하여 방출이 다음과 같도록 하는 것입니다.

import * as __LIB__ from "@external/lib"

발생할 수 있는 앨리어싱이 없기 때문입니다.

다른 하나는 첨부된 zip 에 따라 수입 선언을 위해 생성된 식별자를 보유합니다.

@RubaXa 목표가 전체 모듈 객체를 전달하는 것이라면 import * as __LIB__ from "@external/lib" 구문(앨리어싱이 필요하지 않음)을 사용하고 후자가 import __LIB__ from "@external/lib" default 전체 모듈 개체가 아닌

예, 우리는 앨리어싱을 방지하기 위해 CSS 모듈 변환기 에서도 import * as foo 를 수행하고 있습니다. 특정 명명된 내보내기를 인라인하기 위해 그것을 활용하는 것이 좋지만

@rbuckton O, 감사합니다!
문자열에서 임의의 AST 조각을 만드는 방법에 여전히 관심이 있으십니까?

function createFragmentFromString(code: string) {
  // ????
}

function visitPropertyDeclaration(node) {
    if (ts.isIdentifier(node.name) && node.name.text === "templateString") {
        // ...
        return ts.updateProperty(
            node,
            ts.visitNodes(node.decorators, visitor),
            ts.visitNodes(node.modifiers, visitor),
            ts.visitNode(node.name, visitor),
            ts.visitNode(node.type, visitor),
            createFragmentFromString('(function compiledTemplate() { /* ... */ })()')
        );
    }
    return node;
}

이것이 내가 TypeScript에서와 같이 변압기 지원 및 워크플로가 작동하기를 바랐던 것입니다.

https://www.dartlang.org/tools/pub/transformers

저도 이 기능에 관심이 많습니다.

@MichaReiser가 언급했듯이
If someone experienced has inputs on how to implement the changes, I'm willing to create a PR as it would simplify my project tremendously.

전문가/타입스크립트 컴파일러 DEV의 입력을 보고 싶습니다.

누군가 이 기능을 노출하기 위해 타이프스크립트를 래핑한 것 같습니다. https://github.com/cevek/ttypescript

또한 ts-loader에 있는 것처럼 보입니다: https://www.npmjs.com/package/ts-loader#getcustomtransformers -----before-transformerfactory--after-transformerfactory----

제 생각에는 이것이 typescript 2.8 릴리스나 적어도 로드맵에 포함될 수 있다고 생각합니다. @ahejlsberg @mhegazy @DanielRosenwasser 어떻게 생각하세요? 이러한 방식으로 맞춤형 변압기는 더 대중적이고 따라서 더 강력해질 수 있습니다. tsconfig.json 관점에서 변환기에 플러그인 옵션이 있으면 삶이 많이 단순화됩니다.

앞에서 언급했듯이 단기간에 플러그인을 공개할 계획은 없습니다.

@mhegazy 고려된 결정입니까 아니면 커뮤니티 관심이 낮다는 이유로 범위를 벗어났습니까?

나는 그렇게 말하지 않았어. 우리는 작은 공개 API/유지보수 비용과 빌드 진행 방식 변경의 유연성을 유지하고 싶습니다. 이 두 가지 모두 플러그인 모델의 영향을 받습니다.

변환기 플러그인 API 조각화를 중지하십시오. Transformer api 위에 플러그인 api를 안정화하고 tsconfig.json에 노출합니다.

ts-loader , parcel-plugin-typescript , rollup-plugin-typescript2 , ts-transformer-keys , ttypescript 및 기타.

각각 사용자 정의 플러그인 등록 방법과 사용자 정의 플러그인 진입점 형식을 제공합니다. 플러그인 지옥으로 가는 길입니다.

이제 cevec/ttypescript 는 모든 일반적인 변환기 플러그인 형식을 지원합니다. 모든 typescript 모듈과 tsc, tsserver 명령(작은 런타임 ts.createProgram 패치) 위에 있는 드롭인 래퍼입니다. Webpack ts-loader 및 rollup-plugin-typescript2는 ttypescript로 쉽게 구성할 수 있습니다.

TTypescript는 범용 변환기 플러그인 형식을 제안하지만 기존 변환기도 지원합니다.

{
    "compilerOptions": {
        "plugins": [
            { "transform": "ts-transform-graphql-tag" },
            { "transform": "ts-transform-css-modules", "type": "config" },
            { "transform": "ts-nameof", "type": "raw", "after": true}
            { "transform": "./transformers/my-transformer.ts", "someOption1": 123, "someOption2": 321  }
        ]
    },
    "exclude": ["node_modules", "transformers/**/*"]
}

이것에 대한 소식이 있습니까? TypeScript 작성자가 어떻게 든 바닐라 TypeScript에서 사용자 정의 변환기를 허용하지 않으려는 것처럼 보입니다. 부끄러운 일입니다. 멋진 기능이 될 것입니다.

그들은 내부에서 문제를 깨는 데 어려움을 겪을까봐 두려워 다른 API/표면을 유지하는 것을 원하지 않습니다. 아이러니하게도 이러한 모든 타사 플러그인 솔루션은 ts-team의 표준이 없기 때문에 모두 약간 다르며 결국 중단됩니다.

그들은 내부에서 문제를 깨는 데 어려움을 겪을까봐 두려워 다른 API/표면을 유지하는 것을 원하지 않습니다.

3년 동안 타이프스크립트로 작업하고 진화를 지켜본 결과 간단한 결론에 도달했습니다. Microsoft는 _code_의 의미에서 Typescript를 오픈 소스로 가지고 있지만 _process_의 의미는 아닙니다. 대부분의 경우 오픈 소스 프로젝트는 의사 결정 과 코딩 모두에서 커뮤니티 주도적이며 자연스러운 방식으로 발전해야 합니다. node.js의 IO.js 포크를 기억하십니까? 커뮤니티는 회사의 이익이 일반적인 오픈 소스 거버넌스 모델과 일치하지 않는다는 것을 깨달았고 단순히 분기했습니다. TypeScript에서는 이런 일이 발생하지 않기를 바랍니다. 하지만 Microsoft는 이 가능성을 고려해야 합니다.
분명히 말해서, 저는 개발자를 비난하는 것이 아닙니다. 어쨌든 그들은 훌륭한 일을 합니다.
그냥 내 2c, OT에 대해 죄송합니다.

Microsoft는 코드 측면에서 Typescript를 오픈 소스로 제공하지만 프로세스 측면에서는 그렇지 않습니다.

나는 이것에 전적으로 동의하지 않습니다. 저는 Microsoft에서 일한 적이 없지만 지난 4년 동안 TypeScript의 여러 기능에 직접적인 영향을 미쳤습니다. 저는 TypeScript로 구축된 오픈 소스 라이브러리를 대표하고 있었고 몇 가지 직접적인 대화를 나누기로 했습니다. 그러나 모든 기능에 대한 모든 "토론"은 여기에서 공개적으로 이루어졌습니다. 핵심 팀은 디자인 회의 노트를 게시합니다. 오픈 소스 라이브러리를 대표하는 내가 얻은 유일한 "내부자"는 일부 기능에 대해 내 주장을 직접 주장하고 핵심 팀을 만날 수 있는 기회였습니다. 팀이 팀과 같은 역할을 한다는 사실을 깨달았습니다. 우리가 이야기한 기능 중 하나인 Anders는 기본적으로 문제가 너무 어렵고 사람들이 직면한 "실제" 문제를 해결하는 데 많은 시간이 걸릴 것이라고 말했습니다. 그것은 2년 전이었고 TypeScript 3.0에서 마침내 그것을 얻었습니다. 하지만 커뮤니티는 디자인 과정에서 목소리를 냅니다. 하지만 다른 커뮤니티와 마찬가지로 우리는 다양한 목소리를 가졌습니다. 어느 팀도 모두를 기쁘게 할 수 없었습니다. 그렇게 한다면 TypeScript는 _정말_ 나쁜 도구가 될 것입니다.

또한 핵심 팀에 "Microsoft"라는 레이블을 지정하려고 합니다. 핵심 팀은 내가 만난 가장 작은 Microsoft 팀이었습니다. 그들은 릴리스 콘텐츠에 대한 완전한 통제를 기반으로 설립된 후 출시 주기를 완전히 통제하기 위해 전투를 벌였습니다. 그들은 또한 개방성과 투명성을 위해 싸웠습니다. CodePlex에서 GitHub로 이동하기 위해 싸웠습니다. 다른 여러 팀이 그들의 모델을 채택했기 때문에 그들은 Microsoft에서 더 이상 고유하지 않습니다. 그러나 내가 아는 한 그들은 VSCode 팀이 빠르게 뒤따르면서 모든 것을 시작한 사람들이었습니다.

따라서 핵심 팀이 전투를 선택하고 선택하기 때문에 디자인 원칙 을 고수한다는 것은 커뮤니티에 목소리가 없다는 것을 의미하는 것이 아니라 목소리로 우리가 정신병적 다중 인격 장애로 고통받는 것을 의미합니다. 우리는 봉사하기 어려운 고객입니다.

내 이해는 이것이 #16607과 동일하거나 다른 목표를 달성할 수 있다는 것입니다. 아주 최근의 플러그인 작성자로서, Babel 플러그인을 사용하여 TypeScript로 작업할 때를 포함하여 이것이 노출되는 것을 보고 싶습니다.

@mrmckeb 이 문제는 이미 존재하는 typescript AST 변환을 표준화하고 노출하기 위한 것이며 연결된 문제는 매우 광범위한(정의되지 않은) 범위에서 전체 파일 변환을 논의하는 것으로 보입니다.

여기에 2센트를 더하고 싶습니다. 여러분 중 일부는 훌륭한 프로젝트 babel-plugin-macros 에 대해 들어봤을 것입니다. 기본적으로 수천 개의 서로 다른 Babel 플러그인을 사용하는 대신 변환을 수행하기 위해 사용자 코드로 구동되는 유일한 플러그인이 있을 수 있습니다. 항상 구성을 엉망으로 만들 필요가 없는 엄청나게 투명한 시스템. 이것은 매크로를 지원하지만 추가 구성을 금지하는 CRA 와 같은 프로젝트에 특히 좋습니다.

오늘 저는 이것을 TypeScript 세계로 가져오는 방법에 대한 토론 을 열었습니다. 통찰력이 있으시면 와서 공유하십시오.

궁극적으로, 나는 우리가 어떻게든 성공한다면 단 하나의 변환만 필요하기 때문에 이것이 필요하지 않기를 바랍니다.

@FredyC 멋진 프로젝트지만 tsc 만 사용할 때 컴파일러에 이와 같은 것을 쉽게 삽입하려면 이 문제를 해결해야 합니다. 예를 들어 babel-plugin-macros의 경우 여전히 .babelrc 에 지정해야 하며 tsconfig.json 의 typescript에 이와 같은 것을 지정하는 것이 좋습니다.

사실, babel-plugin-macro와 같은 동작을 TypeScript에 내장하고 구성이 필요하지 않은 것이 좋을 것이라고 제안하고 있습니까? 좋을 수도 있지만 개인적으로 tsconfig.json 에서 사용자 지정 변환기를 지정한 다음 typescript ast 노드를 지원하는 babel-plugin-macros 버전을 지정할 수 있는 구성 가능한 솔루션을 선호합니다.

@dsherret 예, TypeScript 자체의 일부가 될 것이라고는 생각하지 않습니다. 그러나 변환이 준비되면 매크로에 대한 변환만 주입하고 나머지는 사용자 코드에서 수행할 수 있는 tsc 같은 작은 래퍼를 쉽게 준비할 수 있다고 상상할 수 있습니다.

편집: 사실, 작은 래퍼가 이미 있습니다. 위에서 언급한 https://github.com/cevek/ttypescript 를 사용하면 범용 매크로 플러그인과 함께 사용하도록 지시하기 쉽고 윈-윈입니다.

Typescript 변환에 정통한 사람들을 찾아서 기본적인 프로토타입을 파악하기만 하면 됩니다. 나는 토론하고 말할 수 있지만, 그것을 구현하는 것은 나의 현재 능력보다 높습니다.

그들은 내부에서 문제를 깨는 데 어려움을 겪을까봐 두려워 다른 API/표면을 유지하는 것을 원하지 않습니다.

3년 동안 타이프스크립트로 작업하고 진화를 지켜본 결과 간단한 결론에 도달했습니다. Microsoft는 _code_의 의미에서 Typescript를 오픈 소스로 가지고 있지만 _process_의 의미는 아닙니다. 대부분의 경우 오픈 소스 프로젝트는 _decisions_와 _coding_ 모두에서 다소 커뮤니티 주도적이며 이것이 진화하는 자연스러운 방법이어야 합니다. node.js의 IO.js 포크를 기억하십니까? 커뮤니티는 회사의 이익이 일반적인 오픈 소스 거버넌스 모델과 일치하지 않는다는 것을 깨달았고 단순히 분기했습니다. TypeScript에서는 이런 일이 발생하지 않기를 바랍니다. 하지만 Microsoft는 이 가능성을 고려해야 합니다.
분명히 말해서, 저는 개발자를 비난하는 것이 아닙니다. 어쨌든 그들은 훌륭한 일을 합니다.
그냥 내 2c, OT에 대해 죄송합니다.

동의한다. 커뮤니티의 강한 관심에도 불구하고 개발자는 "사람들이 그것을 오용할 것"이라는 라인을 제외하고는 실제로 거부 이유를 제공하지 않고 사용자 정의 변환기/매크로의 아이디어를 거부하는 것이 분명합니다. 이는 커뮤니티에 불쾌감을 주기도 합니다. 그것이 의미하는 바와 같이 품질이 낮은 개발자 커뮤니티입니다.

"그냥 하지 않겠습니다"라는 말 외에 합리적인 이유가 있다면 거절을 받아들이겠지만, 커뮤니티의 모든 요청에도 불구하고 아직 아무도 그것을 제공하려고 노력하지 않은 것 같습니다.

이것은 부당한 비판이라고 생각합니다. @pietrovismara. 이것이 필수 기능이라는 데 동의하지만 이 기능을 차단하는 "Microsoft"가 아닙니다. 제가 알기로 팀에서는 지원하기가 쉽지 않기 때문에 아직 이러한 기능을 추가하지 않았다고 합니다.

다시 말하지만 저는 이 기능을 다른 누구보다 원하지만 사실을 사용하여 이 문제를 논의해야 합니다. 사실은 팀이 아직 지원할 준비가 되지 않았다는 것입니다. 따라서 계속 관심을 표명하면서 대화를 올바른 방향으로 유지합시다.

@mrmckeb 그렇다면 이해할 수 있습니다. 나는 그 당시 이 이슈에 포함된 수많은 논평에서 그러한 선언을 놓쳤음에 틀림없다. 누구의 기분을 상하게 하려는 것이 아니라, 당신이 말했듯이 올바른 방향으로 대화를 유지하기 위해 관리인의 명확한 대답을 도발하려고 했습니다.

좋습니다. 이에 대한 지원이 존재하지 않는다는 것은 실망스럽습니다. 제가 말했듯이 저는 느끼고 있습니다. 우리는 TypeScript를 지원하므로 CRA에서 항상 CSS 모듈에 대한 일종의 솔루션을 요청받고 있습니다. 나는 그것이 곧 오기를 희망하지만, 또한 그것이 팀에 큰 위험 영역을 열어준다는 것을 이해합니다.

... 아직 기다리고 있습니다 :(

네, 아직 기다리고 있습니다 ...하지만 무엇을 기다리고 있습니까?

지금 ttypescript 보다 더 나은 솔루션이 있습니까?
TypeScript 개발자는 결국 플러그인을 지원할 계획입니까?

당신은 당신 자신의 컴파일러를 만들 수 있습니다 ;-)

주제에 대한 소식이 있습니까? 커뮤니티에서 이 기능을 충분히 사용하여 피드백을 수집하고 마지막으로 구성 파일에 변환기 지원을 추가한 것 같습니다. 참조로 사용할 구현도 많이 있습니다.

2년이 넘었습니다(와우!)*. 사람들이 변압기용 플러그인을 여는 것에 대한 찬반 양론을 재고하는 데 열려 있습니까?

API에 대한 문서가 부족하고 사용자 코드 <-> 변환기 <-> API의 메쉬를 지원해야 하는 것과 같이 이전에 존재했던 초기 문제가 더 이상 관련이 없다고 생각합니다. 오픈 플러그인 지원은 babel과 같은 패키지에서 놀라운 성과를 거두었습니다. 협업을 통한 진행. 나는 개인적으로 Babel을 광범위하게 사용하여 구체적으로 증명할 수 있습니다.

typescript와 같은 변환기의 더 쉬운 "그냥 작동" 통합이 _좋을 것입니다. 특히 이 패키지는 타이프스크립트 전체에 혁명적인 영향을 미치고 있다고 생각합니다. 진정한 강력한 계약! 😃

장단점에 대한 대화가 이에 대한 실망이나 차이점을 없애는 데 도움이 될 것이라고 생각합니다. 솔직히 말해서 이 좀비 문제는 그런 일이 일어날 때까지 계속될 것입니다.

* 그 동안 누군가 대신 TS용 기능을 생성했습니다( ttypescript ). 나는 이것을 성공에 사용했습니다.

@DanielRosenwasser 3.5 반복 계획 에 "TypeScript 플러그인 API 조사"가 있는 것을 보았습니다(그리고 그 작업은 이미 시작되었습니다).
그 요점은 이번 호에서 논의된 내용을 다루고 있습니까? 문제에 대한 링크가 부족하면 아직 그것에 대해 공유하기에는 너무 많은 WIP가 있다고 생각합니까?

Babel이 Typescript 정적 분석(예: 여러 파일 변환 또는 변환 중 여러 파일에 대한 종속성)을 지원하는 데 필요한 기능을 추가하는 것을 포함하여 Babel 파서에 대한 완전한 지원을 추가하는 작업이 이루어져야 한다고 생각합니다. 구문을 복제하거나 Babel 플러그인을 Typescript에 상응하는 것으로 변환하는 대신.

다음 지침에 문제가 있는 경우 알려주세요. 기꺼이 도와드리겠습니다.

디자인 팀의 순전한 과실을 감안할 때 해결 방법은 다음과 같습니다.

tslint와 코드 수정 기능을 활용할 것입니다.

다음 예제에서 우리는 가장 기본적인 형태 로 type-to-code 변환을 할 것입니다.

우리는 데코레이터 를 다시 작성해야 하는 코드의 마커로 사용할 것입니다.

우리의 경우 데코레이터는 유일한 목표가

• 변형의 장소를 표시하기 위해
• 생성기의 정보 소스가 될 유형을 캡처하려면

데모 목적으로 인터페이스의 이름과 속성 유형을 일반 문자열로 기본 클래스에 덤프할 것입니다.

다음 단계는 Windows 사용자를 위한 것입니다. 귀하가 Windows 사용자가 아닌 경우 신의 도움을 받을 수 있습니다.

1. VSCode 시작
2. 다음 확장을 설치하십시오: https://github.com/Microsoft/vscode-typescript-tslint-plugin
3. VSCode를 닫으십시오
4. 원하는 폴더로 이동
5. git clone https://github.com/zpdDG4gta8XKpMCd/code-gen.git 실행
6. code-gen 폴더로 이동: cd ./code-gen
7. 운영
   
   
   
   • 1-install.bat
   
   
   • 2-build.bat
   
   
   • 3-install-some-more.bat
   
   
   • 4-try.bat
   
   
8. 열린 VSCode 인스턴스 관찰
9. test.ts 로 이동( Ctrl + P -> test.ts )
10. 다음 인터페이스를 기록해 두십시오. 코드 생성기의 소스가 될 것입니다.

interface Data {
    one: string;
    another: number;
}

1. 마커로 사용할 팬텀 데코레이터로 구성된 다음 기능을 기록해 둡니다.

function gen<_T>() {
    return function (meh: any) {};
}

1. 인터페이스와 마커 데코레이터를 기반으로 일부 자동 생성 코드를 밀어넣고자 하는 재작성 사이트를 기록해 둡니다.

@gen<Data>()
export class Gen {
}

1. @gen<Data>() 아래의 구불구불한 선을 관찰하십시오.
   

2. Quick fix... 선택 -> Needs a rewrite, wanna fix?
   

3. 자동 생성 코드 관찰:
   

여기에 참조를 위해 codeGenRule.ts 에서 찾을 수 있는 생성기의 소스 코드가 있습니다.

import * as Lint from 'tslint';
import * as ts from 'typescript';

export class Rule extends Lint.Rules.TypedRule {
    public applyWithProgram(sourceFile: ts.SourceFile, program: ts.Program): Lint.RuleFailure[] {
        return this.applyWithWalker(new Walker(sourceFile, this.getOptions(), program.getTypeChecker()));
    }
}

class Walker extends Lint.RuleWalker {
    constructor(sourceFile: ts.SourceFile, options: Lint.IOptions, private checker: ts.TypeChecker) {
        super(sourceFile, options);
    }
    public visitNode(node: ts.Node) {
        if (ts.isDecorator(node)) {
            const checked = check(node, this.checker);
            if (checked !== undefined) {
                const [node, message, replacement] = checked;
                this.addFailureAtNode(node, message, replacement);
            }
        }
        super.visitNode(node);
    }
}

function check(node: ts.Decorator, checker: ts.TypeChecker) {
    const { expression, parent } = node;
    if (!ts.isClassDeclaration(parent)) return;
    if (!ts.isCallExpression(expression)) return;
    const { expression: identifier, typeArguments: typeArgs } = expression;
    if (!ts.isIdentifier(identifier)) return;
    const { text: name } = identifier;
    if (name !== 'gen') return;
    if (typeArgs === undefined) return;
    if (typeArgs.length > 1) return;
    if (typeArgs.length < 1) return;
    const [only] = typeArgs;
    const type = checker.getTypeFromTypeNode(only);

    // if you got to here, you are at the right place and you have a type

    // working on a fix
    const properties = checker.getPropertiesOfType(type);
    const allNameTypes = properties.map(p => {
        const { name } = p
        const type = checker.getTypeOfSymbolAtLocation(p, node);
        return name + ': \'' + checker.typeToString(type) + '\';'
    })
    const { newLine } = ts.sys;
    const body = newLine + allNameTypes.join(newLine);
    const { pos: start, end } = parent.members;
    return [
        node,
        'Needs a rewrite, wanna fix?',
        Lint.Replacement.replaceFromTo(start, end, body)
    ] as const;
}

@zpdDG4gta8XKpMCd , 개념을 공유해 주셔서 감사합니다. 하지만 예의 바르게 행동하세요.

디자인 팀의 순전한 과실을 감안할 때 해결 방법은 다음과 같습니다.

이것은 당신(그리고 나를 포함한 많은 다른 사람들)이 갖고 싶어하는 _기능_을 구현하지 않는 TypeScript를 처리하는 적절한 방법이 아닙니다. 이것은 주요 결함이 아니며 "과실"을 반영하지 않습니다. 예의를 지켜주세요.

오, 제발 개인적인 생각으로 받아들이지 마세요. 이것은 제가 항상 불만을 제기하는 방식입니다. 저는 성격이 매우 좋지 않습니다(건강 상태). 그리고 이것이 제가 제 자신을 짜낼 수 있는 최선입니다, 정말 죄송합니다

당신은 나를 놀라게하는 것을 멈추지 않을 것입니다

• 당신이 보는 것은 편안함으로 오늘날의 주요 문제를 해결할 수 있는 것처럼 보이는 코드 조각입니다(속임수 없음, 해킹 없음)
• 이 해결 방법은 디자인 팀에 대한 경고이며 이전에 커뮤니티가 잘못된 방향으로 돌아가려고 했을 때 발생하는 것을 보았듯이 디자인 팀이 즉시 해결했습니다. #4212,
• 따라서 그들이 관심을 갖는다면 너무 늦을 때까지 더 빨리 올바르게 할 수 있습니다. 그렇지 않으면 우리는 이 방향으로 자유롭게 파고들 수 있으며 앞으로는 문제가 되지 않을 것입니다.
• 그래서 내 피드백의 어조는 부적절했지만 2017년 3월 2일 이후(2년 이상) 적절한 어조로는 아무 것도 얻을 수 없었습니다. 네, 2년 더 기다려도 됩니다.

@zpdDG4gta8XKpMCd 실제 구현에 어떤 기여를 했습니까? TypeScript는 오픈 소스입니다. 풀 리퀘스트를 생성했다면(부분적으로라도) 풀 리퀘스트를 진지하게 고려할 것이라는 데 의심의 여지가 없습니다.

당신의 무례함을 의학적 상태로 비난하는 것은 용납될 수 없습니다. 귀하가 입력하고 자발적으로 "댓글"을 클릭하기로 선택한 단어입니다. 어떤 질병도 당신을 그렇게 만들지 않습니다. 타이핑이 아니라 말하세요. 당신은 또한 그것을 제거하기 위해 당신의 코멘트를 편집할 기회가 있었지만 당신은 그렇게 하지 않았습니다.

사용자 정의 변환기가 _now_ 필요한 경우 Babel을 사용할 수 있습니다. 거의 모든 TypeScript에서 유형 주석을 제거할 수 있으며 원하는 대로 구문 변환을 허용합니다. 보너스로 속도도 빨라집니다.

Microsoft의 저장소에서 영구적으로 쫓겨나기 전에 댓글 작성을 중단하는 것이 좋습니다. 그것이 내 repo라면, ​​당신은 마지막 빨대에있을 것이라는 것을 압니다.

알았어, 넌 날 쫓아냈어, 그럼 어쩌지
내가 돌아올 수 있을까? 새 계정을 만들 수 있습니까?
내가 이 계정을 너무 신경 쓰는 것 같아?

어쨌든, 예, 저는 pull 요청을 시도했지만 불행히도 다음과 같은 이유로 실현 가능하지 않습니다.

1. 당신이 해결할 수 있는 특정 범주의 문제가 있습니다. 이 문제는 다소 사소하고 덜 관심이 있는 것입니다. 이와 같이 심각한 문제는 아닙니다.

2. 스스로 해결할 수 없기 때문에 이와 같은 문제(224개의 엄지손가락을 들어도)는 고려한다면 몇 년을 기다릴 수 있습니다.

3. 운 좋게도 당신은 당신이 가진 수단을 사용하여 오늘 무언가를 할 수 있고 볼 수 있는 차이를 만들기 시작할 수 있습니다. 따라서 제안(아무것도 하지 않는다고 나를 비난하지 마십시오)

@zpdDG4gta8XKpMCd 아시다시피 저는 몇 년 동안 냉소적인 테이크의 팬이었습니다. 저는 여기에서 다른 사람들과 동의해야 합니다. 우리는 대화를 정중하고 정중하게 유지해야 합니다. 이 문제를 추적하는 모든 사람은 프로젝트를 개선하기를 원한다는 것을 항상 상기시켜줍니다.

@Janpot 네 , WIP에 가깝지만 @rbuckton 이 돌아오면 상태에 대한 세부 정보를 제공할 수 있습니다.

플러그인 포인트를 조사할 때(3.5 반복 계획에서 언급한 것처럼) 사용자 지정 변환기에 대한 더 쉬운 후크를 노출하는 것이 우리가 고려하고 싶은 주요 시나리오라고 생각합니다. 우리가 이것을 반드시 노골적으로 하지 않을 이유는 우리가 이것을 포함하는 더 광범위한 작업이 있을 수 있기 때문입니다. 다시 말해서, 아마도 사전 및 사후 트랜스포머보다 더 광범위한 것이 있을 수 있습니다.

@DanielRosenwasser 그다지 냉소적이지 않고 딱 2마디만 하고 그 점에 대해 진심으로 미안하다고 말했다

어쨌든, 요점은 우리 모두가 상황이 어떻게 돌아가는지에 대한 건전한 좌절의 상당 부분이 있다는 데 동의하고 우리는 그것을 비난하지 않는다는 것입니다. 우리는 이 프로젝트를 추진하는 요인을 이해합니다

하지만 우리의 관점에서 보면 비난할 사람이 있을 것입니다. 이러한 문제를 몇 년에 걸쳐 방치하는 것이 더 생산적이지 못한 이유입니다.

나는 그것을 미루고 다른 것들에 먼저 집중할 이유가 있다고 확신합니다. 따라서 청중에게 매우 원하는 특정 기능이 충족되지 않는 이유를 알려주면 더 좋을 것입니다. 좌절의 정도를 낮출 수 있습니다.

• A, BC 및 D, E 및 F가 먼저 수행되어야 하기 때문에 이 기능을 구현할 수 없습니다.

그래서 나는이 대화를 언급하고 있다고 생각합니다 : https://github.com/Microsoft/TypeScript/issues/30696#issuecomment -478799258

엄지손가락을 치켜세운다고 해서 새로운 리소스가 갑자기 창출되지 않고, 복잡하고 어려운 결정을 간단하고 쉽게 내리거나, 기존 비즈니스 우선 순위를 변경하고, 진행 중인 프로젝트를 중단하고, 다른 작업의 우선 순위를 낮추거나, 지나치게 야심찬 제안이 범위를 넓히거나, 초점을 맞추고 유지 관리할 수 있도록 광범위하고 영구적인 영향을 주는 제안을 변경합니다.

우리가 이와 같이 매우 복잡하고 유지 관리가 많이 필요한 작업에 앞서 잘 알려진 훌륭하고 간단한 작업을 미리 수행(또는 에 대한 PR 허용 )한 것에 대해 사과하지 않습니다. 지하실을 리모델링하고 집 꼭대기에 또 다른 이야기를 추가할 계획이 아직 진행 중인 동안 누군가가 와서 새는 수도꼭지를 수리하게 하려는 이유를 추측하는 것은 어렵지 않을 것입니다.

@zpdDG4gta8XKpMCd 왜 누군가를 탓해야 합니까? 애초에 이 문제를 해결하기 위해 PR을 하지 않은 자신을 탓하지 않겠습니까? 또는 구현 관점에서 접근하는 방법에 대한 건설적인 글이 있습니까?

앗, 방금 링크한 투명한 글을 쓰고도 2주 만에 곰을 다시 찌르기로 하셨어요? 1500개 이상의 작업이 있는 그 위치에 있다고 상상해 보십시오. 그러면 그 중 몇 가지를 선택해야 합니다. 우리 팀에서는 100개 정도의 작업을 옮기고 상당히 고군분투하고 있습니다. 15배나 더 많을 줄은 상상도 못함 😮

@FredyC 맙소사, 내가 아무것도 하지 않는다고 말하기 전에 내 해결 방법을 봐

예, 다음과 같은 이유로 공식적인 pull 요청을 하지 않습니다.

1. 나는 좋은 것을 만드는 수준에 있지 않다

2. 간단한 승인의 경우 긴 줄을 서야 하고 2년 전에 생성된 pull 요청을 현재 코드베이스로 최신 상태로 유지하려면 엄청난 노력이 필요합니다. 시간이 많지 않습니다.

3. Anders hejlsberg와 같은 소수의 사람들만이 알고 있는 거대한 설계 고려 사항을 고려할 때 특정 문제는 고려조차 되지 않을 것입니다.

당신은 좌절 부분을 제거 할 수 없습니다, 그리고 나는 여기에 혼자가 아닙니다

우리는 다음과 같은 요인이 작용한다는 것을 알고 있습니다.

• 언어의 웅장한 디자인
• 예산 / 자원 / MS 내부 정치
• 커뮤니티의 소원

이 재료들을 섞어서 내린 결정이 조금 더 명확했다면 더 좋았을 텐데

난 끝났어 너무 갔어 상처받은 모든 사람들에게 미안하지만 나는 아무 말도하지 않을거야

https://github.com/Microsoft/TypeScript/issues/14419#issuecomment -483920640의 연속

또 다른 옵션은 함수 선언 자체를 마커로 사용하는 것입니다. 아래는 이름이 toRandom... 로 시작하는 함수에 대한 코드 생성기의 구현입니다.

생성기의 정보 소스는 함수의 결과 유형입니다.

이것이 작동하는 방식입니다:

1. toRandom... 로 시작하는 함수 아래의 구불구불한 선을 확인하십시오.
   
2. 옵션 탐색:
   
3. 빨리 고치다
   
4. 결과 관찰:
   

다음은 이를 수행하는 codeGenRule.ts 의 코드입니다.

보너스로 이 구현은 함수의 현재 코드가 생성되어야 하는 코드와 일치하지 않는 경우에만 linting 문제를 발생시킵니다.

import * as Lint from 'tslint';
import * as ts from 'typescript';

export class Rule extends Lint.Rules.TypedRule {
    public applyWithProgram(sourceFile: ts.SourceFile, program: ts.Program): Lint.RuleFailure[] {
        return this.applyWithWalker(new Walker(sourceFile, this.getOptions(), program.getTypeChecker()));
    }
}

class Walker extends Lint.RuleWalker {
    constructor(sourceFile: ts.SourceFile, options: Lint.IOptions, private checker: ts.TypeChecker) {
        super(sourceFile, options);
    }
    public visitFunctionDeclaration(node: ts.FunctionDeclaration) {
        const checked = check(node, this.checker);
        if (checked !== undefined) {
            const [node, message, fix] = checked;
            this.addFailureAtNode(node, message, fix);
        }
        super.visitFunctionDeclaration(node);
    }
}

function check(node: ts.FunctionDeclaration, checker: ts.TypeChecker) {
    const { name: identifier, type: result, body } = node;
    if (body === undefined) return;
    if (identifier === undefined) return;
    const { text: name } = identifier;
    if (!name.startsWith('toRandom')) return;
    if (result === undefined) return;
    const type = checker.getTypeFromTypeNode(result);

    // if you got to here, you are at the right place and you have a type

    // working on a fix
    const properties = checker.getPropertiesOfType(type);
    const newerBody =
        `{
    return {${properties.map(prop => {
            const { name } = prop;
            const type = checker.getTypeOfSymbolAtLocation(prop, node);
            const typeName = capitalize(checker.typeToString(type));
            return `
        ${name}: toRandom${typeName}(),`;
        }).join('')}
    };
}`;
    const olderBody = body.getFullText();
    if (areEqual(olderBody, newerBody)) return;
    const start = body.getFullStart();
    const end = start + body.getFullWidth();
    return [
        node,
        'Needs a rewrite, wanna fix?',
        Lint.Replacement.replaceFromTo(start, end, newerBody),
    ] as const;
}

function areEqual(one: string, another: string) {
    // AB: we cannot make any assumption what line endings are,
    // this is why we compare the text of code without them
    return one.replace(/\r\n|\n/g, ' ') === another.replace(/\r\n|\n/g, ' ');
}

export function capitalize(value: string): string {
    const length = value.length;
    if (length > 1) {
        return value.substr(0, 1).toUpperCase() + value.substr(1);
    } else if (length > 0) {
        return value.substr(0, 1).toUpperCase();
    } else {
        return value;
    }
}

@zpdDG4gta8XKpMCd 내 생각에 이 문제는 방출하는 동안 사용자 정의 변압기를 더 쉽게 연결하는 방법에 관한 것이었습니까? 전. tsconfig.json에 변환을 지정 하여 api 를 사용하는 대신 tsc 와 함께 사용할 수 있습니다. 편집기에서 사용자 정의 코드 변경/수정을 원하십니까?

나는 그것들을 전혀 사용하지 않았지만 당신이 말하는 것은 이미 언어 서비스 플러그인으로 가능할 수 있다고 생각합니다(언어 서비스에서 getCodeFixesAtPosition 를 재정의하고 자신의 코드 작업을 삽입하는 것으로 생각합니다... 확실하지 않음) https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

아니면 제가 오해하고 있는 걸까요?

오른쪽. 그게 바로 내가 생각했던 것입니다

tsconfig.json 를 통해 사용자 정의 변환을 지정하는 방법이 꿈이 실현될 것이라고 생각했습니다.

그러나 나는 내 해결 방법이 훨씬 더 좋다는 것을 깨달았습니다.

제 생각은 다음과 같습니다.

• 플러그형 구성 가능한 코드 생성기가 필요했습니다.
• typescript에는 그런 편리한 기능이 없습니다.
• 다른 한편으로 나는 tslint(2019년 말까지 감가상각됨)가 매우 자유롭게 코드를 플러그인하고 구성하는 방법이 있는 typescript에 적합한 플러그인 플랫폼이라는 것을 알고 있습니다.
• 내가 필요한 모든 것이 있음이 밝혀졌습니다.
  
  
  
  • 플러그 가능 및 구성 가능
  
  
  • 필요한 모든 UI와 함께
  
  
  • typescript에 대한 API를 제공합니다.
  
  
  • 약간의 추가 기능이 있습니다
  
  

다음과 같은 이유로 typescript 언어 서비스를 사용하는 무언가를 작성하는 것을 볼 수 없다는 점을 감안할 때:

• 내 랩톱은 많은 typescript 언어 서비스만 보유할 수 있으며 그 중 일부는 이미 다음과 같습니다.
  
  
  
  • vscode 중 하나
  
  
  • tslint 중 하나
  
  

그리고 나는 그 위에 다른 것을 추가하고 싶지 않습니다

내 코드 변환기를 연결하는 더 나은 방법이 있으면 좋겠지만 우리는 가지고 있는 것을 가지고 있습니다.

이것이 우리가 매크로를 수행하는 방법입니다: #4892

• 내 랩톱은 많은 typescript 언어 서비스만 보유할 수 있으며 그 중 일부는 이미 다음과 같습니다.

  • 하나의 vscode
  • 하나 by tslint

@zpdDG4gta8XKpMCd 모든 것이 동일한 언어 서비스를 사용해야 한다고 생각합니다. 따라서 단일 언어 서비스가 있고 플러그인과 함께 tslint 플러그인이 이를 프록시합니다.

Btw, 여기에서 수행하려는 작업이 여기 에서 수행된 작업이기 때문에 일반 언어 서비스 플러그인으로 확실히 가능해야 합니다.

어쨌든, 여기에서는 편집기 코드 변경/언어 서비스 항목이 아닌 tsc 를 사용하여 빌드의 일부로 사용자 정의 변환기에 대해서만 주제에 대한 대화를 유지하려고 합니다. 대부분의 사람들은 전체 프로젝트에서 변환을 수행하는 솔루션을 찾고 있으며 편집기 내에서 수행하는 것은 실행 가능한 솔루션이 아닙니다(특히 해당 시점에서 변환을 수행하는 것은 사용 목적을 무효화하기 때문에). 이상적으로 여기에서 구현되어야 하는 것은 편집기/tsserver 또는 언어 서비스와 관련이 없어야 합니다.

소중한 정보 감사합니다 고려하겠습니다

tsc 빌드의 일부로 사용자 정의 변환기에 대해서만 대화를 유지하는 데 동의하지 않습니다.

• 작성된 원래 요청은 전달될 양식 변환이 구체적이지 않으며,
  > 단일 변환기를 추가하기 위해 전체 tsc 명령줄을 복제합니다.
• 2년 동안 이 토론은 솔루션이 있고 작동하고 사용하기 쉬운 경우 변압기 구현 방법에 대해 그다지 신경 쓰지 않는 것처럼 보이는 많은 사람들로부터 상당한 관심을 끌었습니다.
• 또한 tslint 팀은 플러그인을 위한 인프라를 잘 구축했습니다. 이를 사용하지 않는 것은 노력을 낭비하는 것입니다. 실제로 typescript를 처리하는 typescript 외부에서 공식적으로 유일하게 인정되는 플랫폼이라면
• 또한, 우리 모두는 변압기가 언어로 가는 길을 찾더라도 곧 일어나지 않을 것이라는 데 동의하지만 여기 사람들(저를 포함하여)은 어제처럼 필요했습니다.
• 마지막으로, 더 나은 대안이 많지 않기 때문에 적어도 우리가 가진 것을 고려하지 않는 이유는 무엇입니까?

내 제안은 해결 방법 으로 명확하게 레이블이 지정되어 있습니다(디자인 팀이 적절한 솔루션에 대해 더 열심히 생각하는 데 시간을 할애하는 동안). 그렇다면 왜 안 될까요?

다른 곳에서 해야 한다고 주장하신다면 말씀해 주십시오.

하지만 하는 것에 대한 귀하의 우려를 해결하기 위해

전체 프로젝트에 걸쳐 변형

tslint는 cli에 대한 --fix 인수로 정확히 수행합니다.

@zpdDG4gta8XKpMCd --fix 는 TypeScript 코드를 제자리에 업데이트합니다. 이 문제는 방출 중에 변환을 수행하는 것에 관한 것입니다(변경 사항은 최종 JavaScript 파일에서만 끝납니다). 참조된 문제의 PR(#13940)을 참조하십시오.

#13764가 출시된 이후로 커스텀 트랜스포머를 작성하는 것은 쉽습니다. 그러나 API를 올바르게 이해하면 단일 변환기를 추가하기 위해 전체 tsc 명령줄을 복제해야 합니다. 이는 typescript에 따라 응용 프로그램이 tsc 명령줄 도구와 동일한 기능을 지원하지 않기 때문에 비호환성을 초래합니다.

즉, 해당 문제로 인해 CustomTransformers 가 발생했지만(해당 링크를 클릭하고 API에서 사용된 위치 확인) tsc 를 사용하려면 어떻게든 복제하거나 래핑해야 합니다. ttypescript 가 않습니다. 그런 다음 두 번째 단락에서는 기존 빌드 도구에 잘 통합되기 때문에 이것이 얼마나 좋은지 설명합니다(사용자 정의 변환기를 사용하는 것은 다른 빌드 도구가 다른 방식으로 처리하는 대신 tsc에서 처리하기 때문입니다).

코드 수정에 대한 우려나 TypeScript 코드 내에서 TypeScript 코드를 생성하는 더 쉬운 방법을 원하는 새로운 문제를 여는 것이 더 생산적일 것이라고 생각합니다. 오늘날 많은 부분이 이미 가능하다고 생각하기 때문에 이러한 우려 사항이 정확히 무엇인지 잘 모르겠습니다. 그러나 귀하가 논의한 것은 코드 수정/작업을 수행하는 방법에 관한 것입니다. 이는 나와 관련이 없는 주제처럼 보입니다.

이 스레드에서 대답해야 할 주요 질문은 Daniel이 논의한 것("단순한 사전 및 사후 변환기보다 더 광범위한 것이 있을 수 있음")과 빌드의 이 부분을 만드는 솔루션이 어떻게 생겼는지에 대한 것입니다.

당신은 모호하다

나는 간단한 것을 이해하고 감사하는 사람입니다

내 문제는 내가 약 3500개 이상의 파일 프로젝트를 처리하고 있다는 것입니다. 그 중 15%는 손으로 작성 및 유지 관리할 필요가 없으며 그 위에 유사한 항목이 약 5% 추가될 예정입니다.

동시에 나는 그것을 할 수 있는 API가 있다는 것을 알고 있지만 완전히 구워지기 위해 처리하는 시간을 정당화할 수 없을 정도로 반쯤 구워졌습니다.

그래서 내가 여기에 왔을 때 나는 이것이 그것에 대해 이야기하기에 적절한 장소라고 생각했고, 빠르고 간단한 해결책이 있을 수 있다는 것이 밝혀졌습니다.

불행히도 여기에 온 일부 사람들은 훨씬 더 미세한 문제를 논의하기 위해 왔습니다.

좋아, 뛰어난!

그리고 아니요, 저는 사람들에게 tslint가 주요 문제 중 하나를 어떻게 해결할 수 있는지 다시 한 번 보여주기 위해 새 문제를 열지 않을 것입니다.

구성 가능한 변환을 즉시 사용하는 것이 좋습니다. 코드 내 문자열 l10n 및 i18n 문제를 해결하려고 합니다. tslint 와 같은 도구를 추출을 위한 사용자 지정 규칙과 함께 활용할 수 있지만 ttypescript 와 같은 것을 사용하지 않는 한 코드를 변환하는 옵션은 제한적입니다. 작업은 배출되지 않은 각도 앱입니다. 그것은 단지 빌드 도구의 레이어에 레이어를 추가하도록 강요합니다. 개발 속도에 따라 전체 스택이 정말 불안정해집니다.

우리는 현재 프레임워크를 개발 중이며 런타임에 유형 수준 정보에 액세스하기 위해 현재 ttypescript 를 사용하고 있습니다. 결국 공식 컴파일러에 plugins 옵션이 있으면 좋을 것입니다 😄

지금은 휴가 중이지만 다음 주에 돌아올 때 보겠습니다.

2019년 7월 21일 일요일 오후 5:54 Giorgio Boa [email protected]
썼다:

@longlho https://github.com/longlho 멋진 아스트를 많이 만드셨네요
트랜스포머 여러분의 도움이 필요합니다 👍
Angular 복사 전에 데코레이터 메타데이터를 수정하고 싶습니다.
내 목표는 이 노드를 수정하는 것입니다.
Component({ selector: 'standard' ... })를 Component({ selector: 'custom'
... })
나는 그것을 테스트하기 위해 github repo를 만들었습니다.
https://github.com/gioboa/ng-ts-transformer . 가능하다고 생각하지만
문서가 없으면 도움이 필요합니다. 🙏 감사합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/TypeScript/issues/14419?email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVEXG43VMXHJ2LDNMV
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCFER5A
.

프록시 없이 인터페이스에서 실제 모의 객체를 생성하는 라이브러리를 만드는 데 기여했습니다. 지금은 ttypescript를 사용하는 것이 좋지만 typescript와 통합하는 방법이 있으면 좋을 것입니다.

이 기능이 구현되는 것을 정말 보고 싶습니다. 이것이 Typescript와 이것이 가져올 수 있는 가장 위대한 혁신 사이에 서 있는 유일한 것이라고 확신합니다.

Typescript는 프론트엔드 개발에 큰 기여를 하지만, 추가 혁신에도 제동이 걸립니다…
의미 체계를 깨뜨리지 마십시오. 플러그인 ATM은 의미 체계를 깨뜨릴 수 없습니다. 플러그인은 전혀 허용되지 않습니다 :man_shrugging: 왜?
정말 좋은 플러그인이 있지만. 모든 플러그인은 (키)단어 토큰화 및 AST 설치)를 존중해야 합니다... , 내부에서 무언가를 수행하는 것은 정말 어려운 방법입니다.
그렇게 어렵지 않습니다. 쉽지는 않지만 babel 프로젝트는 그것이 가능하다는 것을 보여줍니다.
사실 babel이 새로운 의미나 구문을 도입하는 것은 거의 사소한 일입니다.

나는 typescript에서 의미론을 허용할 것으로 기대하지 않습니다. (또한 물론 구문 변경을 기대하지 않습니다! )
내가 원하는 것은 컴파일러에서 preeval과 같은 경우에 따라 이동하는 것입니다.
route 또는 message 또는 기타와 같은 take 함수가 있는 경우 컴파일러가 사전 평가하고 (오, 제발, 1단계에서) 정확성을 확인할 수 있습니다.

내 이전 단락을 이상하게 읽는다면. tsx 및 모든 React 장점은 무엇입니까?

React도 없고, 흐름도 없고, 타이프스크립트도 전혀 없고, 한눈에 보기에도 거의 없습니다.

제발. 나는 이 모든 것을 주의 깊게 바라보는 것을 잘 이해하고 있습니다. 그러나 우리가 IE5.5+에서 배운 것처럼; 차단은 앞으로 나아갈 길이 없습니다.

개선이 필요한 것이 있다면 여전히 레이아웃 엔진입니다. D.Knuth는 50년 전에 모든 누락된 부품을 디자인한 guenie였습니다. 왜 우리는 오늘 이것을 가지고 있지 않습니까?? :-)
사람들에게 JS 사악함에서 CSS를 중지하라고 알려주세요.

제발. 의미론적 지능을 위한 개방형 TS ; 나머지에 대한 유형 힌트를 제공하는 정적 문자열 입력이 있는 함수와 유사합니다. 실제 const 입력 문자열 분석…
약간의 예:

• GraphQL 호출 반환 모양
• 국제 입력 모양
• …훨씬 더_
  제발. 의미 체계 변경이 필요하지 않습니다. 모든 것이 원하는 대로 작동합니다. 빌드 시 더 많은 것을 확인할 수 있습니다. 그게 다야! :토끼:

충돌

core-js import - @babel/preset-env 및 @babel/runtime $ 와 같은 대상 환경에 대한 자동 폴리필($#$3 babel #$ 제외)을 위한 TS 변환 작성을 실험 중입니다. TS 개발자의 큰 부분을 심각하게 도울 수 있습니다. 그러나 ttypescript 와 같은 추가 도구 없이 상자에서 사용자 정의 변환을 지원하지 않으면 이러한 변환을 사용할 가능성이 심각하게 제한되므로 이것이 의미가 있는지 확신할 수 없습니다.

나는 그런 아이디어로 실험을 해왔습니다 - https://github.com/webschik/typescript-polyfills-generator.
나는 Transformers API가 개발 체인에서 babel 를 드롭할 가능성을 열어줄 것이라고 생각합니다. 많은 개발자들이 둘 다 사용하고 싶지 않지만 @babel/preset-env 와 같은 플러그인이 여전히 필요하다고 생각합니다.

이 제한 사항으로 인해 현재 자체 사용자 지정 컴파일러 스크립트(TypeScript 컴파일러 API 사용)를 롤링했습니다. 우리는 ttypescript 에 대해 간략하게 살펴보았지만 기본 TypeScript 컴파일러에서 TypeScript 컴파일러의 확장으로 이동하려는 욕구는 거기에 없었습니다.

사용자 정의 변환기가 tsconfig.json에서 지원된다면 환상적일 것입니다. 단순히 tsconfig를 구문 분석하고 변환기를 선언한 다음 컴파일러를 실행하는 스크립트를 작성하는 것은 번거롭습니다. 또는 더 나쁜 것은 사용자 정의 스크립트에서 파일 보기와 같은 컴파일러의 기본 기능을 실제로 다시 구현하려고 시도하는 것입니다.

다른 사람들도 이 감정을 반영했지만 사용자 정의 변환기를 컴파일러에 쉽게 통합할 수 있도록 하면 TypeScript 개발 팀의 부담이 크게 줄어들고 커뮤니티에서 이 언어로 혁신과 추가적인 추진력을 얻을 수 있습니다.

매우 성공적인 플러그인 생태계의 예는 Serverless Framework의 플러그인 커뮤니티입니다. 개발 팀은 기능 개발에 대한 수요를 따라갈 수 없으며 플러그인을 사용하면 PR을 열거나 핵심 제품에 포함된 기능을 축소하지 않고도 새로운(실험적일 수 있음) 기능을 통합할 수 있습니다. 더 넓은 사용자 기반에 가치를 제공하지 않습니다.

나는 도서관을 짓고 있고 거기에는 나에게 잘 작동하고 내가 의존하는 데코레이터가 있습니다. 나는 얼마 전에 데코레이터가 내 라이브러리를 트리 흔들 수 없도록 만든다는 것을 깨달았습니다. 조사한 후 변환기가 컴파일 시 이러한 데코레이터를 트리 흔들 수 있는 코드로 바꾸는 데 도움이 될 수 있다는 결론에 도달했습니다. 내 파이프라인에서 정의할 수 없다는 것은 불행한 일입니다. 이 문제가 곧 해결되기를 바랍니다. 매우 도움이 될 사용 사례에 2센트를 드리고 싶었습니다.

TypeScript가 래퍼 프로그램과 복잡한 지침 없이 사용자 정의 변환기를 지원하도록 하기 위해 ts-patch ( npm github )라는 도구를 작성했습니다.

ts-patch(전역 또는 로컬)를 설치하고 ts-patch install 를 실행하여 typescript를 패치하기만 하면 됩니다. 또한 typescript 설치 디렉토리를 지정하거나 TS가 업데이트되거나 다시 설치되는 경우 패치를 유지 관리하는 지속성을 활성화할 수 있습니다. (세부정보: ts-patch /? )

패치 로직은 대부분 ttypescript를 기반으로 합니다. (cevek의 훌륭한 작업에 큰 감사를 드립니다!) npm 패키지 설치 프로세스에 쉽게 추가할 수 있는 방식으로 작성되었습니다. 패치 해제도 쉽습니다.

분명히 말해서 이것은 typescript 자체의 관련 파일을 직접 패치하며 래퍼가 아닙니다. 종속성 설치 후 패치를 실행하기만 하면 typescript가 변환기 준비가 됩니다.

이것이 어떤 사람들에게 도움이 되기를 바랍니다!

TypeScript가 래퍼 프로그램과 복잡한 지침 없이 사용자 정의 변환기를 지원하도록 하기 위해 ts-patch ( npm github )라는 도구를 작성했습니다.

ts-patch(전역 또는 로컬)를 설치하고 ts-patch install 를 실행하여 typescript를 패치하기만 하면 됩니다. 또한 typescript 설치 디렉토리를 지정하거나 TS가 업데이트되거나 다시 설치되는 경우 패치를 유지 관리하는 지속성을 활성화할 수 있습니다. (세부정보: ts-patch /? )

패치 로직은 대부분 ttypescript를 기반으로 합니다. (cevek의 훌륭한 작업에 큰 감사를 드립니다!) npm 패키지 설치 프로세스에 쉽게 추가할 수 있는 방식으로 작성되었습니다. 패치 해제도 쉽습니다.

분명히 말해서 이것은 typescript 자체의 관련 파일을 직접 패치하며 래퍼가 아닙니다. 종속성 설치 후 패치를 실행하기만 하면 typescript가 변환기 준비가 됩니다.

이것이 어떤 사람들에게 도움이 되기를 바랍니다!

적절한 지원을 추가/토론하기 위해 PR로 제기할 수 있습니까? :)

이봐. 그만한 가치가 있는 fuse-box라는 번들러가 있어 맞춤형 변압기를 매우 쉽게 추가할 수 있습니다. 4.0 버전이 곧 나올 예정입니다... 그래서 중간 지점에 있습니다. 그러나 전반적으로 나는 번들러를 정말 좋아합니다. 어쩌면 당신에게도 도움이 될 수 있습니다.

https://github.com/fuse-box/fuse-box/blob/master/docs/plugins/pluginCustomTransform.md

적절한 지원을 추가/토론하기 위해 PR로 제기할 수 있습니까? :)

TS 팀은 이것을 기본 기능으로 제공하고 싶지 않다고 밝혔습니다. 결정에 대한 그들의 이유는 합리적입니다!

좋은 소식은 TS가 오픈 소스이고 이미 모듈 방식으로 컴파일되었기 때문에 ts-patch가 내장된 경우와 매우 유사한 방식으로 작동한다는 것입니다. 따라서 버그가 있는 리버스 엔지니어링된 바이트코드 패치와 다릅니다.

지원을 통해 유지 관리되는 것이 걱정된다면 최신 상태로 유지하고 TS의 모든 향후 버전에서 작동할 계획입니다! 내 상업 기반 시설의 많은 부분이 이미 그것에 의존하고 있습니다.

참고로 저는 다른 진입점이 있는 여러 플러그인을 단일 패키지로 패키징할 수 있는 새 버전과 이를 개선하고 사용하기 쉽게 하기 위한 몇 가지 기타 최적화를 허용하는 새 버전을 곧 출시할 예정입니다.

플러그인을 작성한 후 ts 팀이 주저하는 이유를 이해할 수 있습니다. 현재 변환기는 컴파일 후 단계입니다. 복잡한 작업을 수행하고 원래 바인딩되지 않은 새 콘텐츠를 추가하기 시작하면 심각한 문제가 발생합니다. 그대로 ts-node --compiler ttypescript foo.ts 는 완벽하게 작동합니다. 차라리 ts 팀이 다른 컴파일 단계에서 변환기 플러그인을 처리하거나 리바인딩 단계를 허용하고 싶습니다.

전류 변환기는 컴파일 후 단계입니다. 복잡한 작업을 수행하고 원래 바인딩되지 않은 새 콘텐츠를 추가하기 시작하면 심각한 문제가 발생합니다.

변환기는 TSC 컴파일 전이나 후에 실행할 수 있습니다. 당신이 언급한 것은 노드를 수정한 후 검사기가 업데이트되지 않는다는 것입니다. 이것은 실제로 우회할 수 있으며, 기능이 구축되지 않았을 뿐입니다. ts.transform()을 호출하면 작업할 전체 Program 인스턴스가 생성되지 않으므로 검사기로 작업하려면 생성해야 합니다. CompilerHost를 사용하면 AST를 변경한 후 수정된 파일로 다시 로드할 수 있습니다.

아직 자세히 다루지는 않았지만 '감시' 기능을 사용하여 매번 전체 프로그램 인스턴스를 다시 빌드할 필요가 없는 것처럼 보입니다. 간단히 말해서, 더 완전한 플러그인 시스템을 갖는 것이 실제로 _너무_ 어렵지는 않지만 변환은 제공된 컨텍스트에서 지원이 부족하다는 것이 밝혀졌습니다.

@nonara ttypescript 및 ts-loader`와 함께 변환을 사용했으며 둘 다 전체 프로그램 진입점이 있습니다. 내 문제는 새 가져오기 문을 추가하면 누락된 "무언가"와 새 명령문이 최종 출력 방출에서 제거된다는 것입니다. @weswigham 은 변환이 바인딩 후 단계이기 때문에 말합니다. 해결책은 분명히 파일에 대해 완전히 새로운 프로그램을 만드는 것입니다. 그러나 ts-loader(특히 변환 전용 모드에 있고 webpack/bundler 파일을 완전히 숨길 때)와 같은 것을 다룰 때 두통처럼 보입니다. 리졸버. 결국 에는 가져오기를 중단하고 필요한 코드를 인라인했습니다 .

@MeirionHughes 아, 알겠습니다. 이 경우 예, Program 인스턴스가 있습니다. ttypescript 는 createProgram을 후킹하여 결과 program 의 emit 메소드가 변환기를 포함하도록 패치하여 작동합니다.

• ts.emitFiles 는 프로세스 중에 ts.transformNodes $를 호출합니다.
• ts.transformNodes 는 Program 인스턴스를 사용하거나 사용하지 않고 호출할 수 있습니다. ts.transform() 를 직접 호출하면 하나 없이 수행됩니다.

내가 올바르게 이해하고 있다면 유형 및 기호가 이미 표시되고 AST 변환 후에 업데이트되지 않는다는 사실에도 문제가 묶여 있는 것처럼 들립니다.

안녕하세요 여러분 저는 변압기에 대한 모든 정보를 함께 배치하고 쉽게 시작할 수 있도록 변압기 핸드북을 작성했습니다.

https://github.com/madou/ts-transformer-handbook/blob/master/translations/en/transformer-handbook.md

잠시만 시간을 내어 봐주시면 감사하겠습니다 👍

@madou 나는 또한 TS 변압기 https://levelup.gitconnected.com/writing-typescript-custom-ast-transformer-part-1-7585d6916819 에 대한 무리 게시물을 작성했습니다.

이에 대한 상태는 어떻습니까?

typescript를 많이 사랑하지만 정적 유형과 런타임 JS 간의 상호 운용성을 시작할 때 특히 투박하게 느껴집니다. 이를 개선하기 위해 커뮤니티 작성 플러그인이 많이 있습니다(예: https://github.com/dsherret/ts-nameof , https://github.com/kimamula/ts-transformer-keys - 하지만 일류 플러그인 지원 없음). 프로젝트에 포함시키는 것은 위험한 기술적 결정처럼 느껴집니다. 플러그인을 기본적으로 활성화하면 커뮤니티에서 핵심 라이브러리에 포함되어야 하기 전에 잠재적인 미래 유형 스크립트 기능을 가지고 놀 수 있습니다.

TypeScript 팀은 그들의 주장을 재고해야 한다고 생각합니다. 플러그인 생태계는 언어를 발전시키고 실험을 가능하게 하고 장려하는 입증된 방법입니다(하스켈의 pragma 참조).

그러한 실험 중 일부는 거칠고 미친 것이 될 것이며, 일부는 결국 안정화되어 일반화될 것입니다. 사용자 공간에서 언어 기능을 구현할 수 있는 기능을 제공하는 것은 항상 좋습니다.

일반적으로 TypeScript 팀의 위치는 불필요하게 경직되어 보입니다.

언어를 변경하지 않지만 더 쉬운 디버깅을 위한 추가 정보를 제공하는 변환도 있습니다.

예를 들어 babel-plugin-transform-react-jsx-source 는 기본 반응 변환 사전 설정( @babel/preset-react )의 일부입니다.
변신한다

<sometag />

안으로

<sometag __source={ { fileName: 'this/file.js', lineNumber: 10 } } />

이 정보를 통해 react 는 개발 중에 더 나은 오류 스택 추적을 제공할 수 있습니다.

typescript의 경우 오픈 소스 변환이 있지만 동일한 결과를 얻을 수 있는 표준 방법은 없습니다. https://github.com/dropbox/ts-transform-react-jsx-source

@mhegazy 가 TS 팀이 tsconfig의 일부로 "플러그인"을 포함할 계획이 없다고 두 번 언급한 것을 이해합니다. 그 이유는 무엇입니까?

당신은 PR에 열려 있습니까? ttypescript가 tsconfig를 통해 변환기를 처리하는 방식은 꽤 좋습니다.

사용 사례:

1) 런타임 검사가 가능하도록 스키마에 대한 인터페이스 유형을 생성합니다.
2) 문자열을 리터럴로 사용하여 json을 가져와서 구분된 공용체를 사용하는 유형에 할당할 때 typescript가 방해하지 않습니다.
3) css/yaml 및 구문과 같은 기타 객체 가져오기
4) 올바른 유형을 동적으로 생성하는 graphql 쿼리 만들기
5) jsx를 html 문자열로 컴파일하여 innerHTML 삽입 가능
5) tsconfig 경로를 기반으로 절대 가져오기를 상대 가져오기로 다시 작성합니다.

목록은 계속됩니다. 플러그인 API가 좋습니다. 착륙해주셔서 감사합니다. "tsconfig"의 "플러그인" 부분이 있으면 tsc가 정말 강력해집니다. 우리가 놓치고 있는 큰 것이 있습니까?

또한 많은 성능 최적화를 수행할 수 있습니다. 저는 typescript 변환기를 사용하여 https://github.com/atlassian-labs/compiled-css-in-js 를 작성하고 있습니다 🤙 소비자가 사용하기 위해 후프를 건너뛸 필요가 없다면 멋질 것입니다.

친애하는 Typescript 팀, 이 문제에 대해 질질 끌지 말아주세요 <_<

이에 대한 상태는 어떻습니까?

상태?

친구 무슨 소식?

typescript 팀은 이 아이디어에 반대하기로 결정했습니다. 유연성이 필요하거나 typescript를 사용하는 더 나은 개발 도구가 핵 없는 옵션이 아닌 경우 대신 babel을 사용하고 typechecking에만 typescript를 사용하십시오.

typescript 팀은 이 아이디어에 반대하기로 결정했습니다. 유연성이 필요하거나 typescript를 사용하는 더 나은 개발 도구가 핵 없는 옵션이 아닌 경우 대신 babel을 사용하고 typechecking에만 typescript를 사용하십시오.

그러나 유형 검사를 위한 몇 가지 해킹을 원하면 어떻게 합니까? 나는 마술을 만드는 작은 변환기를 작성합니다.

type Human = {
    name: string,
    age: number
}

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true
const isValid = check<Human>({ name: 'Carl' }) // => false

check 함수가 특정 type-guard 함수로 변형되었습니다! Babel로 어떻게 만들 수 있습니까? 현재는 ttypescript를 사용해야 합니다...

typescript 팀은 이 아이디어에 반대하기로 결정했습니다. 유연성이 필요하거나 typescript를 사용하는 더 나은 개발 도구가 핵 없는 옵션이 아닌 경우 대신 babel을 사용하고 typechecking에만 typescript를 사용하십시오.

실제로 이것이 미래에 지원될 것이라는 이야기가 있습니다. 즉, 실제로 이미 지원됩니다. TypeScript 컴파일러 API는 변환기를 지원하며 단 몇 줄의 코드로 변환기를 사용하는 사용자 정의 컴파일러를 작성하는 것은 _정말_ 간단합니다.

하지만 더 쉽게 하기 위해 ttypescript 또는 ts-patch 를 사용할 수 있습니다.

이러한 라이브러리는 변환기 기능을 추가하기 위해 컴파일러를 보강하지 않는다는 점에서 실제로 "해킹"이 아닙니다. 대신 컴파일러 API의 기존 기능을 tsc 에 노출하여 tsconfig를 통해 사용할 수 있도록 합니다.

@ilya-buligin 사용 사례를 올바르게 이해하면 주변 상수를 선언할 수 있습니다.

declare const check: <T>(value: unknown) => value is T;

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true

Typescript는 check 유형 정의에 따라 코드를 컴파일한 다음 Babel을 사용하여 생성된 코드로 대체합니다.

@just-boris Babel에서 일반 유형 <T> 에 액세스하는 방법은 무엇입니까?

이 스레드는 상당히 반복적이고 주제에서 벗어났습니다. @RyanCavanaugh 주제에 대한 업데이트가 있을 때까지 이 스레드를 잠가야 합니다.