Typescript: Поддержка плагинов для пользовательских трансформаторов

Мы не планируем раскрывать систему плагинов компилятора в краткосрочной перспективе. Как вы заметили, преобразования предоставляются как часть общедоступного API, и мы находимся в процессе написания документации и примеров для них.

Я не хочу иметь открытый API плагинов. Вместо этого я бы предпочел зарегистрировать свои пользовательские преобразования, просто указав их в tsconfig.json вместо использования API TS-Compiler. Потому что использование TS-Compiler API означает, что я больше не могу использовать инструмент командной строки tsc, что также может означать, что он больше не интегрируется в существующие инструменты сборки и рабочие процессы.

что-нибудь новое о документации и образцах? @mhegazy

@MichaReiser , вы можете написать простой компилятор на основе API (пример здесь ). На самом деле мы очень активно используем TS в Yahoo Finance, и общедоступный API-интерфейс Transformer был потрясающим.

Вот некоторые из трансформеров, которые мы написали после того, как они стали достоянием общественности:
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
Спасибо за образец.

Это то, что я сейчас делаю. Однако это делает невозможным использование других инструментов сборки, созданных для typescript, например, загрузчиков веб-пакетов, загрузчиков jest. Кроме того, как я могу использовать один из ваших плагинов вместе с одним из моих, когда каждый из нас использует разные интерфейсы?

Поэтому я считаю, что текущий подход — хорошее начало, но его недостаточно для экосистемы плагинов. Потому что использование плагина требует слишком много усилий для пользователя и требует большего, чем просто написание кода преобразования для автора.

Я считаю, что система плагинов, подобная той, что используется в Babel, необходима для машинописи, если цель состоит в том, чтобы побудить сообщество создавать и использовать собственные преобразователи.

@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"

Поскольку не может быть псевдонимов.

Другой удерживает сгенерированный идентификатор для импортной декларации, согласно прикрепленному почтовому индексу .

@RubaXa , если ваша цель - передать весь объект модуля, вы, вероятно, захотите использовать синтаксис import * as __LIB__ from "@external/lib" (который не требует псевдонимов), а не import __LIB__ from "@external/lib" , поскольку последний импортирует default Экспорт

да, мы также делаем import * as foo в наших преобразователях модулей CSS, чтобы предотвратить наложение имен. Хотя было бы неплохо использовать это, чтобы встроить определенные именованные экспорты

@rbuckton О, большое спасибо!
Все еще интересуетесь, как создать произвольный 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----

Я думаю, что это может появиться в выпуске машинописного текста 2.8 или, по крайней мере, в дорожной карте в какой-то момент, @ahejlsberg @mhegazy @DanielRosenwasser , что вы думаете? Таким образом, пользовательские трансформеры могут быть более популярными и, следовательно, более мощными. Наличие возможности подключить трансформер с точки зрения tsconfig.json значительно упростило бы жизнь.

Как отмечалось ранее, мы не планируем предоставлять плагины в краткосрочной перспективе.

@mhegazy Это обдуманное решение или оно выходит за рамки только из-за низкого интереса сообщества?

Я этого не говорил. мы хотели бы сохранить небольшую стоимость общедоступного API/сопровождения, а также гибкость в изменении того, как сборка продвигается вперед, и на оба эти фактора влияет модель плагинов.

Пожалуйста, остановите фрагментацию API плагина трансформатора. Стабилизируйте API-интерфейс плагина поверх API-интерфейса трансформера и выставьте их в tsconfig.json.

ts-loader , package-plugin-typescript , rollup-plugin-typescript2 , ts-transformer-keys , ttypescript и другие.

Каждый из них предоставляет настраиваемый метод регистрации плагина и настраиваемый формат точки входа плагина. Это путь в ад плагинов ts.

Теперь cevec/ttypescript поддерживает все распространенные форматы плагинов-трансформеров. Это надстройка над всеми машинописными модулями и командами 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 нет стандарта, все несколько разные и в конечном итоге сломаются.

они не хотят поддерживать другой API/поверхность, опасаясь, что это может привести к трудностям во внутренних процессах.

После 3 лет работы с typescript и наблюдения за его эволюцией я пришел к простому выводу. Microsoft имеет Typescript с открытым исходным кодом в смысле _code_, но не в смысле _process_. В большинстве случаев проекты с открытым исходным кодом более или менее управляются сообществом как в решениях , так и в кодировании , и это должно быть естественным путем развития. Вы помните форк IO.js для node.js? Сообщество осознало, что интересы компании не совсем совпадают с общей моделью управления с открытым исходным кодом, и они просто разветвились. Я надеюсь, что для TypeScript этого не произойдет, но Microsoft должна принять во внимание эту возможность.
Чтобы быть ясным, я не виню разработчиков, в любом случае, они действительно делают большую работу.
Просто мой 2с, извините за ОТ.

Microsoft имеет Typescript с открытым исходным кодом в смысле кода, но не в смысле процесса.

Я полностью не согласен с этим. Я никогда не работал в Microsoft, но за последние 4 года оказал непосредственное влияние на некоторые функции TypeScript. Я представлял библиотеку с открытым исходным кодом, созданную на TypeScript, и мы договорились о нескольких прямых беседах, но все «дебаты» о любых функциях проводились открыто, публично, здесь. Основная группа публикует заметки о совещании по дизайну. Единственным «инсайдером», которого я получил, представляющим библиотеку с открытым исходным кодом, была возможность лично аргументировать мои аргументы в пользу некоторых функций и встретиться с основной командой. Это дало мне понять, что команда действует как команда. Одна особенность, о которой мы говорили, Андерс в основном сказал, что проблема слишком сложна и что потребуется много времени, чтобы от нее избавиться и решить «настоящие» проблемы, с которыми сталкиваются люди. Это было два года назад, и в TypeScript 3.0 мы наконец получили это. Но у сообщества есть право голоса в процессе проектирования, но, как и у любого сообщества, у нас есть разные голоса, и ни одна команда не может угодить всем, а если бы они это сделали, TypeScript был бы _действительно_ плохим инструментом.

Вы также хотите обозначить основную команду как «Microsoft». Основная команда была самой малочисленной командой Microsoft, с которой я когда-либо сталкивался. Они сражались за то, чтобы получить полный контроль над ритмом своих выпусков, после того как они были основаны на полном контроле над содержанием своих выпусков. Они также боролись за открытость и прозрачность. Боролись за переход на GitHub с CodePlex. По общему признанию, они больше не уникальны в Microsoft, так как несколько других команд приняли их модель, но, насколько мне известно, они были теми, кто начал все это, а команда VSCode вскоре последовала за ними.

Так что только потому, что основная команда выбирает свои сражения, придерживается своих Принципов дизайна , не означает, что у сообщества нет голоса, но как голос мы страдаем от психотического расстройства множественной личности. Мы трудный клиент, чтобы обслуживать.

Насколько я понимаю, это то же самое, что и # 16607, или это приведет к другой цели? Как совсем недавно автор плагинов, я также хотел бы, чтобы это было раскрыто, в том числе при работе с TypeScript с использованием плагина Babel.

@mrmckeb эта проблема предназначена для стандартизации и демонстрации преобразования AST машинописного текста, которое уже существует, в то время как связанная проблема, похоже, обсуждает преобразование всего файла в очень широкой (неопределенной) области.

Я хочу добавить свои 2 цента здесь. Некоторые из вас, возможно, слышали о блестящем проекте babel-plugin-macros . По сути, вместо тысяч различных плагинов Babel может быть только один, который затем приводится в действие пользовательским кодом для выполнения преобразования. Потрясающе прозрачная система без необходимости постоянно возиться с настройкой. Это особенно полезно для таких проектов, как CRA , который поддерживает макросы, но запрещает дополнительную настройку.

Сегодня я открыл дискуссию о том, как перенести это в мир TypeScript. Если у вас есть какие-то идеи, пожалуйста, приходите и делитесь.

В конечном счете, я надеюсь, что если мы каким-то образом добьемся успеха, в этом не будет необходимости, так как потребуется только одно преобразование.

@FredyC , это классный проект, но нам нужно решить эту проблему, чтобы легко внедрить что-то подобное в компилятор, используя только tsc . Например, с макросами babel-plugin-macros его все равно нужно указать в .babelrc и было бы неплохо указать что-то подобное в typescript в tsconfig.json .

На самом деле, вы предполагаете, что было бы неплохо иметь поведение, похожее на макрос babel-plugin, встроенное в TypeScript, и не было бы необходимости в настройке? Это может быть хорошо, но лично я бы предпочел настраиваемое решение, которое позволяет указывать пользовательские преобразователи в tsconfig.json, а затем можно было бы указать версию макроса babel-plugin-macros, которая поддерживает машинописные узлы ast.

@dsherret Да, я не ожидаю, что это будет частью самого TypeScript. Однако я могу себе представить, что после того, как преобразование будет готово, можно будет легко подготовить tsc -подобную крошечную оболочку, которая будет внедрять только это преобразование для макросов, а остальное можно будет сделать из пользовательского кода.

Редактировать: На самом деле крошечная оболочка уже есть, с вышеупомянутым https://github.com/cevek/ttypescript было бы легко указать использовать ее вместе с универсальным плагином макросов, и это беспроигрышный вариант.

Мне просто нужно найти людей, которые хорошо разбираются в преобразованиях Typescript, чтобы создать базовый прототип. Я могу обсуждать и говорить, но реализация этого выше моего текущего набора навыков.

они не хотят поддерживать другой API/поверхность, опасаясь, что это может привести к трудностям во внутренних процессах.

После 3 лет работы с typescript и наблюдения за его эволюцией я пришел к простому выводу. Microsoft имеет Typescript с открытым исходным кодом в смысле _code_, но не в смысле _process_. В большинстве случаев проекты с открытым исходным кодом более или менее управляются сообществом как в _решениях_, так и в _кодировании_, и это должно быть естественным путем развития. Вы помните форк IO.js для node.js? Сообщество осознало, что интересы компании не совсем совпадают с общей моделью управления с открытым исходным кодом, и они просто разветвились. Я надеюсь, что для TypeScript этого не произойдет, но Microsoft должна принять во внимание эту возможность.
Чтобы быть ясным, я не виню разработчиков, в любом случае, они действительно делают большую работу.
Просто мой 2с, извините за ОТ.

Я согласен. Понятно, что, несмотря на большой интерес со стороны сообщества, разработчики просто отвергают идею пользовательских трансформеров/макросов, фактически не указывая причину отказа, за исключением чего-то вроде «Люди будут использовать это неправильно», что также звучит оскорбительно по отношению к сообществу. поскольку это подразумевает, что это сообщество разработчиков низкого качества.

Я бы принял отказ, если бы можно было предоставить разумное обоснование, отличное от «Мы просто не будем этого делать», но, похоже, несмотря на все запросы сообщества, никто еще не предпринял усилий, чтобы предоставить это.

Я считаю, что это несправедливая критика @pietrovismara. Я согласен, что это обязательная функция, но это не «Майкрософт» блокирует эту функцию. Команда, насколько я понимаю, говорит, что это непросто поддерживать, и поэтому они еще не добавили такую ​​функцию.

Опять же, я хочу эту функцию, как никто другой, но нам нужно обсудить этот вопрос, используя факты. Дело в том, что команда пока не готова его поддерживать. Так что давайте продолжать выражать интерес, но также поддерживать разговор в правильном направлении.

@mrmckeb Если это так, я могу это понять. Должно быть, я тогда пропустил такое заявление в большом потоке комментариев, содержащихся в этих выпусках. Никого не хотел обидеть, просто пытался спровоцировать внятный ответ у мантейнеров, чтобы, как вы сказали, вести разговор в нужном русле.

Это нормально, это расстраивает, что поддержки для этого не существует — как я уже сказал, я это чувствую, и нас постоянно просят какое-то решение для модулей CSS в CRA теперь, когда у нас есть поддержка TypeScript. Я надеюсь, что это произойдет в ближайшее время, но я также понимаю, что это открывает огромную зону риска для команды.

... все еще жду :(

да, все еще жду... но жду чего, что-то сделано?

Есть ли лучшее решение, чем ttypescript сейчас?
Планируют ли разработчики TypeScript в конечном итоге поддержку плагинов?

Вы можете создать свой собственный компилятор ;-)

Есть новости по теме? Мне кажется, что сообщество достаточно широко использовало эту функцию, чтобы посидеть, собрать отзывы и, наконец, добавить поддержку трансформеров в файл конфигурации. Существует даже множество реализаций, которые можно использовать в качестве эталона.

Прошло более 2 лет (вау!)*. Готовы ли люди переосмыслить плюсы и минусы открытия плагинов для трансформеров?

Я чувствую, что первоначальные опасения, которые существовали все это время назад, такие как отсутствие документации об API и необходимость поддерживать сетку пользовательского кода <-> преобразователей <-> API, уже не так актуальны. Открытая поддержка плагинов творит чудеса с такими пакетами, как babel: продвижение через сотрудничество. Я могу лично засвидетельствовать конкретно Babel, так как широко использовал его.

Более простая «просто работающая» интеграция преобразователей, таких как машинописный текст, — это _было бы_ неплохо. В частности, я считаю, что этот пакет оказал революционное влияние на машинописный текст в целом. Настоящие крепкие контракты! 😃

Думаю, разговор о плюсах и минусах поможет рассеять любое уныние или разногласия по этому поводу. У меня такое чувство, что эта зомби-проблема будет продолжаться до тех пор, пока это не произойдет - если честно.

* А тем временем кто-то создает функцию для TS ( ttypescript ). Я использовал это для успеха.

@DanielRosenwasser Я видел, что в плане итерации 3.5 было «Изучить API-интерфейсы плагинов TypeScript» (и эта работа уже началась).
Относится ли этот пункт к тому, что обсуждается в этом выпуске? Отсутствие ссылки на проблему заставляет меня предположить, что это слишком много WIP, чтобы поделиться чем-либо об этом?

Я думаю, что следует поработать над добавлением полной поддержки синтаксического анализатора Babel, что включает в себя добавление необходимых функций для поддержки статического анализа Typescript (например, преобразование нескольких файлов или зависимость от нескольких файлов во время преобразования). Вместо того, чтобы дублировать синтаксис/преобразовывать плагины Babel в эквиваленты Typescript.

если у вас возникнут проблемы со следующей инструкцией, дайте мне знать, я буду рад помочь

учитывая явную небрежность команды разработчиков, вот обходной путь

мы воспользуемся преимуществами tslint и его возможностей по исправлению кода

в следующем примере мы собираемся выполнить преобразование типа в код в его самой простой форме.

мы собираемся использовать декораторы в качестве маркеров мест в коде, которые нужно переписать

в нашем случае декоратор — это фальшивая функция, единственной целью которой является

• отметить место преображения
• и захватить тип, который будет источником информации для генератора

в демонстрационных целях мы собираемся выгрузить имена и типы свойств интерфейса в виде простых строк в базовый класс.

следующие шаги предназначены только для пользователей 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,
• так что, если им не все равно, они могут сделать это как можно раньше, пока не станет слишком поздно, или, если они этого не сделают, мы вольны копать в этом направлении, и это не будет проблемой для них в будущем.
• так что тон моего отзыва был какой-то неуместный, а весь соответствующий тон ваш ничего не дал вам с 2 марта 2017 года (свыше 2 лет), и да, вы можете подождать еще 2 года

@zpdDG4gta8XKpMCd Какой вклад вы внесли в реальную реализацию? TypeScript имеет открытый исходный код; Я не сомневаюсь, что они серьезно рассмотрят пулл-реквест, если вы его создадите (даже частично).

Недопустимо обвинять в своей грубости состояние здоровья; это слова, которые вы напечатали и добровольно выбрали «комментарий». Никакое заболевание не заставляет вас делать это. Говорите, может быть, не типа. У вас также была возможность отредактировать свой комментарий, чтобы удалить его, но вы этого не сделали.

Если вам нужны пользовательские трансформеры _сейчас_, вы можете использовать Babel. Он может удалять аннотации типов практически из всех типов TypeScript, в то же время допуская преобразования синтаксиса так легко, как вам заблагорассудится. В качестве бонуса, это также быстрее.

Я предлагаю вам прекратить комментировать, прежде чем вас навсегда выкинут из репозитория Microsoft. Я знаю, если бы это было мое репозиторий, вы были бы на вашей последней соломинке.

ладно, ты меня выгнал, а дальше что?
смогу ли я когда-нибудь вернуться? могу ли я создать новую учетную запись?
ты думаешь, я слишком забочусь об этом аккаунте?

в любом случае, да, я пробовал тянуть запросы, к сожалению, это невозможно по следующим причинам:

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 для , на что вы жаловались в № 30696) первоначальную хорошо понятную и простую работу перед чрезвычайно сложной и требующей больших затрат работой, подобной этой. Нетрудно догадаться, почему мы позволили кому-то войти и починить протекающий кран, в то время как планы по переделке подвала и надстройке еще одного этажа на крыше дома все еще разрабатываются.

@zpdDG4gta8XKpMCd Зачем тебе кого-то обвинять? Почему бы вам в первую очередь не винить себя в том, что вы не сделали PR, чтобы решить эту проблему? Или, по крайней мере, какой-нибудь конструктивный отчет о том, как подойти к этому с точки зрения реализации?

О, чувак, даже после того прозрачного сообщения, которое ты только что связал, ты решил снова ткнуть медведя всего через 2 недели? Попробуйте представить, что вы находитесь в таком положении, имея под рукой более 1500 задач, и вам нужно выбрать пару из них. В нашей команде мы выполняем около 100 задач и достаточно боремся. Не могу представить, что будет в 15 раз больше 😮

@FredyC , ради Бога, посмотри на мой обходной путь, прежде чем сказать, что я ничего не делаю.

да, я не делаю формальные запросы на включение, потому что:

1. я не на том уровне, чтобы сделать хороший

2. для простых требуется длинная очередь одобрения, и требуется огромная работа, чтобы поддерживать запрос на вытягивание, созданный 2 года назад, в соответствии с текущей кодовой базой, у меня не так много времени.

3. некоторые проблемы даже не будут рассматриваться, учитывая грандиозные дизайнерские соображения, о которых знают лишь немногие, такие как Андерс Хейлсберг.

Вы не можете убрать часть разочарования, и я здесь не одинок

мы знаем, что действуют следующие факторы:

• великолепный дизайн языка
• бюджет/ресурсы/политика внутри MS
• пожелания сообщества

я был бы счастливее, если бы принятие решения с помощью смеси этих ингредиентов было немного яснее

Я закончил, это зашло слишком далеко, извините всех, чьи чувства были задеты, я не скажу ни слова

продолжение https://github.com/Microsoft/TypeScript/issues/14419#issuecomment -483920640

другой вариант - использовать сами объявления функций в качестве маркеров, ниже приведена реализация генератора кода для функций, имена которых начинаются с toRandom...

источником информации для генератора является тип результата функции

вот как это работает:

1. обратите внимание на волнистую линию под функцией, начинающейся с toRandom...
   
2. изучить ваши варианты:
   
3. быстро исправить
   
4. наблюдать за результатами:
   

вот код 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 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, чтобы их можно было использовать с tsc вместо использования API . Вы хотите изменить/исправить пользовательский код в редакторе?

Я вообще их не использовал, но я думаю, что то, о чем вы говорите, может быть уже возможно с помощью плагина языковой службы (я думаю, переопределив getCodeFixesAtPosition языковой службы и вставив свои собственные кодовые действия... хотя не уверен) https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

Или может я неправильно понимаю?

правильно. это именно то, что я думал

я думал, что способ указать мои пользовательские преобразования через tsconfig.json будет мечтой.

но потом я понял, что мой обходной путь мне нравится даже больше

вот мой ход мыслей:

• мне нужен подключаемый настраиваемый генератор кода
• машинописный текст не имеет ничего подобного под рукой
• с другой стороны, я знаю, что tslint (хотя и обесценившийся к концу 2019 года) — достойная платформа для плагинов для машинописного текста, которая позволяет легко подключать и настраивать ваш код.
• оказывается, в нем есть все, что мне нужно:
  
  
  
  • подключаемый и настраиваемый
  
  
  • со всем необходимым пользовательским интерфейсом
  
  
  • дает мне API для машинописи
  
  
  • есть несколько небольших дополнений
  
  

учитывая все это, я не могу представить себя пишущим что-то, использующее языковую службу машинописного текста, потому что:

• мой ноутбук может содержать только такое количество языковых служб машинописи, и некоторые из них уже есть:
  
  
  
  • один из vscode
  
  
  • один из tslint
  
  

и я не хочу добавлять еще один поверх этого

я хотел бы иметь лучший способ подключения преобразователей кода, но у нас есть то, что есть

и вот как мы делаем макросы: #4892

• мой ноутбук может содержать только такое количество языковых служб машинописи, и некоторые из них уже есть:

  • один из vscode
  • один от tslint

@ zpdDG4gta8XKpMCd Я считаю, что все должны использовать одну и ту же языковую службу. Таким образом, у вас будет один языковой сервис, а затем плагин tslint вместе с вашим плагином будет проксировать его.

Кстати, то, что вы пытаетесь сделать здесь, определенно должно быть возможно с помощью простого языкового плагина, потому что это то, что сделано здесь .

В любом случае, давайте попробуем вести разговор здесь по теме и только о пользовательских трансформерах как части сборки с tsc , а не об изменениях кода редактора/языковом сервисе. Большинство людей ищут решение для преобразования всего проекта, и выполнение этого в редакторе не является жизнеспособным решением (тем более, что выполнение преобразования в этот момент противоречит цели их использования). В идеале то, что должно быть реализовано здесь, не должно иметь ничего общего с редактором/tsserver или языковой службой.

спасибо за ценный вклад, я учту это

я не согласен с вами по поводу ведения разговора только о кастомных трансформерах как части сборки с tsc , т.к.

• исходный запрос в том виде, в котором он написан, не указывает конкретно, в какой форме должны быть доставлены преобразования, в нем только говорится, что они не должны требовать необходимости
  > продублировать всю командную строку tsc только для того, чтобы добавить один преобразователь
• за 2 года это обсуждение привлекло немало внимания многих людей, которые, кажется, не очень заботятся о том, как реализованы трансформаторы, при условии, что есть решение, оно работает и его легко использовать.
• Кроме того, команда tslint проделала хорошую работу по созданию инфраструктуры для плагинов, отказ от ее использования — пустая трата усилий, при условии, что де-факто это единственная официально признанная платформа за пределами машинописного текста, которая работает с машинописным текстом.
• Кроме того, мы все согласны с тем, что даже если трансформеры когда-нибудь найдут свой путь к языку, это произойдет не скоро, но люди здесь (включая меня) нуждались в них, как и вчера.
• наконец, поскольку лучших альтернатив не так много, почему бы нам не рассмотреть хотя бы то, что у нас есть?

мое предложение четко помечено как обходной путь (пока команда дизайнеров не торопится, чтобы усердно подумать над правильным решением), так почему бы и нет?

если вы настаиваете на том, чтобы мы сделали это в другом месте, пожалуйста, говорите

но для решения вашей самой заботы о том, чтобы сделать

трансформировать весь проект

tslint делает именно это со своим аргументом --fix для cli

@zpdDG4gta8XKpMCd --fix обновит код TypeScript на месте. Эта проблема связана с выполнением преобразований во время отправки (поэтому изменения попадают только в окончательные файлы JavaScript). См. PR упомянутой проблемы (# 13940):

Так как #13764 приземлился, легко написать пользовательские преобразователи. Однако, если я правильно понимаю API, необходимо продублировать всю командную строку tsc только для добавления одного преобразователя. Это приводит к несовместимости, поскольку эти приложения, в зависимости от машинописного текста, не поддерживают те же функции, что и инструмент командной строки tsc.

Другими словами, эта проблема принесла CustomTransformers (щелкните эту ссылку и посмотрите, где она используется в API), но для того, чтобы использовать их, tsc нужно как-то продублировать или обернуть, что и ttypescript делает. Затем во втором абзаце говорится о том, как это было бы хорошо, потому что оно прекрасно интегрировалось бы в существующие инструменты сборки (поскольку использование пользовательских преобразователей будет обрабатываться tsc, а не разными инструментами сборки, делающими это по-разному).

Я думаю, что было бы более продуктивно открыть новую проблему с вашими проблемами с исправлениями кода или с желанием более простого способа генерировать код TypeScript в коде TypeScript. Я не совсем уверен, в чем именно заключаются эти проблемы, поскольку я думаю, что многое из этого уже возможно сегодня, но то, что вы обсуждали, - это то, как выполнять исправления / действия в коде, что кажется мне несвязанной темой.

Я думаю, что основные вопросы, на которые нужно ответить в этой ветке, — это то, что обсуждал Дэниел — «может быть, есть что-то более широкое, чем просто пре- и посттрансформеры», — и как могло бы выглядеть решение для создания этой части сборки.

ты расплывчатый

я человек который понимает и ценит простые вещи

моя проблема в том, что я имею дело с проектом из более чем 3500 файлов, из которых 15% не нужно писать и поддерживать вручную, а еще около 5% подобных вещей появятся в будущем.

в то же время я знаю, что есть API, который может сделать это за меня, но он настолько наполовину готов, что я никогда не смогу оправдать потраченное на него время, чтобы получить его полностью испеченным

поэтому, когда я пришел сюда, я подумал, что это подходящее место, чтобы поговорить об этом, и оказалось, что может быть быстрое и простое решение

не повезло некоторым людям, которые пришли сюда, чтобы обсудить некоторые гораздо более тонкие вопросы

хорошо, выдающийся!

и нет, я не собираюсь открывать новую тему, чтобы еще раз показать людям, как tslint может решить одну из основных проблем, я сделал свою работу, я сделал

Было бы неплохо иметь настраиваемые преобразования из коробки. Я пытаюсь решить проблему строки в коде l10n и i18n . Я могу использовать такие инструменты, как tslint с пользовательским правилом извлечения, но мои возможности преобразования кода ограничены, если только я не использую что-то вроде ttypescript , но это проблематично, потому что приложение, которое я работает над неизвлеченным угловым приложением. Это просто заставляет меня добавлять слой за слоем инструменты сборки. С темпами разработки весь стек становится действительно ненадежным.

В настоящее время мы разрабатываем фреймворк, и в настоящее время мы используем ttypescript для доступа к информации на уровне типов во время выполнения, было бы неплохо в конечном итоге иметь параметр plugins в официальном компиляторе 😄

Я сейчас в отпуске, но посмотрю на следующей неделе, когда вернусь

Вс, 21 июля 2019 г., 17:54 Джорджио Боа, [email protected]
написал:

@longlho https://github.com/longlho Вы создали много отличных аст
Трансформеры, мне нужна ваша помощь, пожалуйста 👍
Я действительно хотел бы изменить метаданные декоратора перед копированием Angular.
Моя цель - изменить этот узел
Component({ selector: 'standard' ... }) в Component({ selector: 'custom'
... })
Я сделал репозиторий на гитхабе для проверки
https://github.com/gioboa/ng-ts-transformer . Я думаю, что это возможно, но
без документации мне нужна помощь. 🙏 Спасибо.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/microsoft/TypeScript/issues/14419?email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OGIWQ1#issuecomment-56 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCFER5A
.

Я внес свой вклад в создание библиотеки для создания настоящих моков из интерфейсов без прокси. На данный момент я рекомендую использовать ttypescript, но было бы неплохо иметь способ интеграции с typescript.

Я бы очень хотел, чтобы эта функция появилась. Я почти уверен, что это единственное, что стоит между Typescript и некоторыми из величайших инноваций, к которым он может привести.

Typescript — огромный вклад в разработку внешнего интерфейса, но он также тормозит дальнейшие инновации…
Не нарушайте семантику. Ни один плагин ATM не может нарушить семантику; и плагины вообще запрещены :man_shrugging: Почему?
Есть действительно хорошие плагины, но. Каждый плагин должен учитывать токенизацию (ключевого) слова и установку AST)…, действительно сложный способ сделать что-то внутри.
Это не так сложно. Это непросто, но проект Babel показывает, что это возможно.
На самом деле для Babel почти тривиально ввести новую семантику или даже синтаксические фразы.

Я не ожидаю, что машинописный текст разрешит семантику. (также я не ожидаю изменений синтаксиса, конечно!)
Чего я хочу, так это от компилятора в некоторых случаях сдвига, например (может быть, только типа) preeval.
Например, если у меня есть функция take, такая как route или message или что-то в этом роде, компилятор может предварительно оценить и (о, пожалуйста, на первом этапе) проверить правильность.

Если вы читаете мой предыдущий абзац странно. Что такое tsx и все прелести React?

Никакого React, никакого потока, вообще никакого машинописного текста, почти никакого взгляда.

Пожалуйста. Я хорошо понимаю внимательное смотрение на все это; но, как мы узнали из IE5.5+; блокировка - это не путь вперед.

Если что-то нуждается в улучшении, это все еще движок компоновки. Д. Кнут был гениальным дизайнером всех недостающих частей 50 лет назад. Почему у нас нет этого сегодня?? :-)
Пожалуйста, скажите людям, чтобы они остановили зло CSS в JS.

Пожалуйста. Open TS для семантического анализа ; функция like со статическим строковым вводом, предоставляющая подсказку типа для остальных; анализировать фактическую константную входную строку…
Маленький пример:

• Форма возврата вызова GraphQL
• Форма ввода Intl
• …гораздо более_
  Пожалуйста. Никаких семантических изменений не требуется. Все будет работать как хотелось. Что-то еще может быть проверено во время сборки. Это все люди! :кролик:

удар

Я экспериментирую с написанием TS-преобразований для оптимизации импорта core-js — автоматического полифилла для целевых сред, таких как @babel/preset-env и @babel/runtime , но без babel . Это могло бы серьезно помочь большой части разработчиков TS. Но без поддержки кастомных трансформаций из коробки без дополнительных инструментов типа ttypescript возможность использования тех трансформаций будет серьезно ограничена, так что не уверен, что это имеет смысл.

Я экспериментировал с такой идеей - https://github.com/webschik/typescript-polyfills-generator.
Я думаю, что Transformers API откроет возможность выбросить babel из цепочки разработки. Я думаю, что многие разработчики не хотят использовать их оба, но им все равно нужны плагины типа @babel/preset-env .

В настоящее время мы создали собственный пользовательский скрипт компилятора (используя API-интерфейс компилятора TypeScript) из-за этого ограничения. Мы бегло посмотрели на ttypescript , но желания перейти от ванильного компилятора TypeScript к расширению компилятора TypeScript просто нет.

Было бы замечательно, если бы пользовательские преобразователи поддерживались в tsconfig.json. Затруднительно писать сценарий, который просто анализирует tsconfig, объявляет преобразователи, а затем запускает компилятор; или, что еще хуже, на самом деле попытаться повторно реализовать основные функции компилятора, такие как просмотр файлов, в пользовательском скрипте.

Другие люди поддержали это мнение, но возможность простоты интеграции пользовательских преобразователей в компилятор сняла бы значительную нагрузку с команды разработчиков TypeScript и обеспечила бы инновации и дополнительный импульс для продвижения этого языка от сообщества.

Примером очень успешной экосистемы плагинов является сообщество плагинов Serverless Framework. Команда разработчиков не может удовлетворить спрос на разработку функций, а плагины позволяют интегрировать новые (возможно, экспериментальные) функции без необходимости открывать PR или разбавлять основной продукт функциями, которые могут или могут не представляют ценности для более широкой пользовательской базы.

Я создаю библиотеку, и у меня есть декораторы, которые отлично работают для меня и от которых я завишу. Некоторое время назад я понял, что декораторы делают мою библиотеку неустойчивой к деревьям. Изучив его, я пришел к выводу, что трансформеры могут помочь мне превратить эти декораторы в код, который можно изменять с помощью дерева при компиляции. К сожалению, я не могу определить их в своем конвейере. Я надеюсь, что вы скоро доберетесь до этой проблемы, просто хотел бросить свои 2 цента в случае использования, где это было бы очень полезно.

Чтобы заставить TypeScript поддерживать пользовательские преобразователи без программ-оболочек и сложных инструкций, я написал инструмент под названием ts-patch ( npm github ).

Просто установите ts-patch (глобально или локально) и запустите ts-patch install , чтобы исправить машинописный текст. Вы также можете указать каталог установки машинописного текста и/или включить постоянство, которое поддерживает исправление, если TS обновляется или переустанавливается. (подробности: ts-patch /? )

Логика исправления в основном основана на ttypescript. (Большое спасибо cevek за отличную работу!) Он написан таким образом, что его можно легко добавить в процесс установки пакета npm. Это также легко распаковать.

Чтобы было ясно, это напрямую исправляет соответствующие файлы в самом машинописном тексте и не является оболочкой. Просто запустите патч после установки зависимостей, и typescript будет готов к преобразованию.

Надеюсь, это поможет некоторым людям!

Чтобы заставить TypeScript поддерживать пользовательские преобразователи без программ-оболочек и сложных инструкций, я написал инструмент под названием ts-patch ( npm github ).

Просто установите ts-patch (глобально или локально) и запустите ts-patch install , чтобы исправить машинописный текст. Вы также можете указать каталог установки машинописного текста и/или включить постоянство, которое поддерживает исправление, если TS обновляется или переустанавливается. (подробности: ts-patch /? )

Логика исправления в основном основана на ttypescript. (Большое спасибо cevek за отличную работу!) Он написан таким образом, что его можно легко добавить в процесс установки пакета npm. Это также легко распаковать.

Чтобы было ясно, это напрямую исправляет соответствующие файлы в самом машинописном тексте и не является оболочкой. Просто запустите патч после установки зависимостей, и 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(), он не создает полный экземпляр программы, с которым вы могли бы работать, поэтому, если вы хотите работать со средством проверки, вам нужно его создать. Используя CompilerHost, вы можете перезагрузить его с измененными файлами после изменения AST.

Я еще не слишком углубился в это, но похоже, что также можно использовать функцию «смотреть», чтобы избежать необходимости каждый раз перестраивать весь экземпляр программы. Проще говоря, оказывается, что на самом деле не так уж сложно иметь более полную систему плагинов, но у преобразования просто нет поддержки в предоставленном контексте.

@nonara Я использовал преобразования с ttypescript и ts-loader`, у обоих есть полные точки входа в программу. Моя проблема в том, что если вы добавите новый оператор импорта, в нем отсутствует «что-то», и эти новые операторы будут удалены из окончательного вывода. @weswigham говорит, что это потому, что преобразование - это шаг после привязки . Решение, по-видимому, состоит в том, чтобы создать совершенно новую программу для файла, но это кажется головной болью, когда вы имеете дело с такими вещами, как ts-loader (особенно когда он находится в режиме только для преобразования и полностью скрывает файл webpack/bundler- В конце концов я отказался от импорта и просто вставил нужный мне код .

@MeirionHughes А, хорошо. В этом случае да, у вас есть экземпляр программы. ttypescript работает, перехватывая createProgram для исправления полученного метода emit program , чтобы включить преобразователи.

• ts.emitFiles вызывает ts.transformNodes во время процесса.
• ts.transformNodes можно вызывать как с экземпляром программы, так и без него. Прямой вызов 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

Каков статус по этому поводу?

Мне очень нравится машинописный текст, но он кажется особенно неуклюжим, когда вы начинаете взаимодействовать между статическими типами и исполняемым JS. Существует множество плагинов, написанных сообществом, чтобы сделать это лучше, например, https://github.com/dsherret/ts-nameof , https://github.com/kimamula/ts-transformer-keys , но без первоклассной поддержки плагинов. Включение их в проект кажется рискованным техническим решением. Включение плагинов изначально позволит сообществу поиграть с потенциальными будущими функциями машинописного текста, прежде чем их нужно будет включить в основную библиотеку.

Я думаю, что команда TypeScript должна пересмотреть свою аргументацию. Экосистема плагинов — это проверенный способ продвижения языка вперед, позволяющий (и поощряющий) экспериментировать (см. Haskell с его прагмами).

Некоторые из этих экспериментов будут дикими и сумасшедшими, а некоторые в конечном итоге стабилизируются и станут обычным явлением. Всегда хорошо предоставлять возможность реализации языковых функций в пользовательском пространстве.

В целом позиция команды TypeScript выглядит излишне жесткой.

Существуют также преобразования, которые не изменяют язык, но предоставляют дополнительную информацию для упрощения отладки.

Например, babel-plugin-transform-react-jsx-source является частью предустановки транспиляции реакции по умолчанию ( @babel/preset- react ).
Он трансформирует

<sometag />

В

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

Эта информация позволяет react обеспечить лучшую трассировку стека ошибок во время разработки.

Для машинописного текста нет стандартного способа добиться того же, хотя есть преобразование с открытым исходным кодом: https://github.com/dropbox/ts-transform-react-jsx-source

Насколько я понимаю , @mhegazy дважды упомянул, что команда TS не планирует включать «плагины» в состав tsconfig. Что стоит за этим?

Вы были бы открыты для пиара? То, как ttypescript обрабатывает преобразователи через tsconfig, довольно приятно.

Случаи применения:

1) создание типов интерфейса для схем, чтобы их можно было проверить во время выполнения.
2) импорт json со строками в виде литералов, чтобы машинописный текст не ругался при назначении типа с размеченными союзами.
3) импорт css/yaml и других объектов, таких как синтаксис
4) выполнение запросов graphql, которые динамически создают правильные типы
5) компиляция jsx в строки html, чтобы их можно было вводить через innerHTML
5) переписывание абсолютного импорта в относительный импорт на основе путей tsconfig.

У этого списка нет конца. Плагин API хороший. Спасибо за посадку. Наличие «плагинов» в составе «tsconfig» делает tsc действительно мощным. Есть ли что-то большое, что мы упускаем?

вы также можете сделать много оптимизаций производительности. я писал https://github.com/atlassian-labs/compiled-css-in-js с преобразователями машинописного текста 🤙 было бы круто, если бы потребителям не нужно было прыгать через обручи, чтобы использовать его.

Уважаемая команда Typescript, пожалуйста, перестаньте затягивать с этим <_<

Каков статус по этому поводу?

Положение дел?

Друзья какие новости?

Команда typescript отказалась от этой идеи — если вам нужна гибкость или лучшие инструменты разработки, использование машинописного текста не вариант без хаков — используйте вместо него babel и используйте машинописный текст только для проверки типов.

Команда typescript отказалась от этой идеи — если вам нужна гибкость или лучшие инструменты разработки, использование машинописного текста не вариант без хаков — используйте вместо него babel и используйте машинописный текст только для проверки типов.

Но что, если мне нужны хаки для проверки типов? Я пишу небольшой трансформер, который делает немного волшебства:

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

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

Функция check преобразована в специальную функцию защиты типа! Как я могу сделать это с Babel? В настоящее время я должен использовать ttypescript...

Команда typescript отказалась от этой идеи — если вам нужна гибкость или лучшие инструменты разработки, использование машинописного текста не вариант без хаков — используйте вместо него babel и используйте машинописный текст только для проверки типов.

На самом деле есть некоторые разговоры о том, что это будет поддерживаться в будущем. Тем не менее, это действительно уже поддерживается. API-интерфейс компилятора TypeScript поддерживает преобразователи, и _очень_ просто написать собственный компилятор, использующий преобразователи, всего в нескольких строках кода.

Но чтобы упростить задачу, вы можете использовать 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, как я могу получить доступ к общему типу <T> в Babel?

Эта тема становится довольно повторяющейся и не по теме. @RyanCavanaugh Возможно, эту ветку следует заблокировать, пока у вас не появятся какие-либо обновления по этому вопросу.