В прошлом я писал о самой большой основной проблеме Typescript: низкой скорости компиляции. Удивительные проекты, такие как esbuild, SWC и bun, решают первую половину проблемы, создавая JS из TS, но они полностью пропускают критическую фазу проверки типов из-за сложности.
В этом посте я кратко упомянул, что большинство крупных игроков (включая Deno, Rome и т. д.) в экосистеме компиляции JS не планируют проводить проверку типов кода TS. SWC — единственный проект, активно решающий эту проблему, но неясно, будет ли он открытым исходным кодом или коммерческим.
По сути, это означает, что большинство из нас будет зависеть от ужасающе медленной скорости tscи это побудило меня задуматься о создании собственного средства проверки типов с открытым исходным кодом. Это, безусловно, было бы веселым и сложным делом, и оно принесло бы пользу огромному количеству людей.
Итак, около недели назад в свободное время я начал работать над средством проверки типов TS с произвольным названием tyty. В настоящее время он поддерживает небольшое подмножество Typescript, я планирую открыть исходный код в ближайшее время.
Очевидной отправной точкой было использование существующего синтаксического анализатора/упаковщика JS/TS путем проверки типов выходного AST. Сложная проблема парсинга JS/TS уже много раз решалась, зачем изобретать велосипед? Из существующих проектов только SWC делает свои узлы AST доступными для общедоступного API, поэтому выбор очевиден.
Вызовы
Система типов Typescript в некоторых отношениях проста, а в других сложна. С точки зрения традиционных систем типов это довольно просто. Typescript использует двунаправленную проверку типов, которая имеет очень простой алгоритм вывода локального типа. Существуют системы типов с более сложным выводом, например система типов Хиндли-Милнера. В результате большая часть проверки типов в Typescript выполняется проще, чем вы думаете.
Оставшаяся трудность связана с некоторыми уникальными функциями Typescript. Одна из самых крутых функций — это условные и рекурсивные типы. В сочетании с универсальными параметрами они позволяют вам добавлять сложную логику к вашим определениям типов, эффективно предоставляя вам простой функциональный язык программирования (который работает с типами, а не с данными), и все это встроено в систему типов Typescript. Например, см. этот синтаксический анализатор JSON, полностью созданный из типов Typescript.
Следствием этого является то, что проблема проверки типов сложных типов становится больше проблемой создания интерпретатора для этого метаязыка, встроенного в систему типов. Создав язык программирования раньше, я очень рад заняться этим аспектом Typescript, поскольку он мне более знаком.
Голы
Конечная цель состоит в том, чтобы достичь паритета функций с Typescript и обеспечить способ компиляции кода TS либо с помощью будущей системы плагинов SWC, либо с помощью оболочки вокруг нее.
Я также хочу использовать скорость средства проверки типов на основе Rust, чтобы создать очень быструю реализацию сервера LSP, которая хорошо работает во всех редакторах (не только в VSCode!).
Кроме того, я хочу, чтобы у tyty были более качественные и описательные сообщения об ошибках, чем у tsc. Разве это не приятно?:
Это сделано с использованием удивительного ящика ariadne Rust.
В идеале я также хотел бы предоставить некоторые функции проверки типов в библиотеке, потому что API-интерфейс компилятора Typescript довольно ужасен. Это дало бы разработчикам более надежные инструменты для управления типами Typescript. Когда я работал над tsgql, мне было ужасно тяжело работать с API компилятора TS.
Это скорее бесперспективная идея, но было бы замечательно, если бы tyty мог взаимодействовать с другими компиляторами JS/TS. Его можно было скомпилировать в динамическую библиотеку и вызывать через FFI.
Загрузка...
