Less.js: ES6 и сводка

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

Я также думал в том же духе, что нам следует рассмотреть возможность использования коллекций es6 для синтаксического анализа / AST, а затем использовать полифилл для сборок es5, таких как https://github.com/Benvie/harmony-collections. В средах es6 (которыми сейчас являются Node.js, как и последние браузеры) это теоретически должно ускорить синтаксический анализ/оценку из-за уменьшения накладных расходов на память и более быстрого построения AST.

Как насчет использования TypeScript? Это может упростить разработку / вклад, чтобы иметь подсказку кода / реальную ссылку на объект. Хотя я не знаю, поставит ли это тогда бремя/барьер знаний.

Мы можем считать, что после ES6 - es6 не исключает машинописный текст, поскольку машинописный текст также является транспилятором es6. Это будет дополнительный шаг после этого.

Я лично не рекомендовал бы машинописный текст, если бы не было значительной дополнительной работы или рефакторинга за меньшее время. машинопись ИМО

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

Я также думал в том же духе, что нам следует рассмотреть возможность использования коллекций es6 для синтаксического анализа / AST, а затем использовать полифилл для сборок es5, таких как https://github.com/Benvie/harmony-collections. В средах es6 (которыми сейчас являются Node.js, как и последние браузеры) это теоретически должно ускорить синтаксический анализ/оценку из-за уменьшения накладных расходов на память и более быстрого построения AST.

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

Также я, к сожалению, не был бы уверен, что родные эквиваленты ES6 быстрее — https://jsperf.com/property-access-object-array-map-weakmap/6. Грустно, например, полифилл Promise быстрее, чем нативная реализация :(

:+1:

Все хорошие моменты. Стандартизация ES6/Babel часто упрощает не только написание, но и чтение, особенно при прототипном наследовании.

Что касается этого теста jsperf, это не совсем честный пример. Я ожидаю, что Weakmap будет работать медленнее для этого конкретного теста. Теоретически, для Less было бы лучше создать кучу различных форм и типов объектов, а затем оценить их. Хотя не уверен. Я нашел несколько хороших библиотек, которые я хочу в конечном итоге протестировать (и, надеюсь, добавить), где мы можем подключиться к отдельным функциям для детального бенчмаркинга, без необходимости помещать в библиотеку какие-либо «крючки для бенчмаркинга». Я надеюсь что-то настроить (когда у меня будет время, кто знает, когда это будет), чтобы вы могли провести своего рода тест jsperf на функциях в Less.js, но с изменениями локальной разработки/ветки на Less vs. текущий выпуск и использование нескольких видов тестовых файлов .less. Как я уже упоминал ранее, нам не нужно гадать, что быстрее для нашего конкретного случая использования. Теоретически мы могли бы добавить WeakMap на каком-то функциональном уровне по сравнению с необработанными объектами, запустить тесты в этом месте и принять решение на основе результата.

@lukeapage написал:
машинопись ИМО

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

И одно неупомянутое, очень важное преимущество, которое вы пропускаете:
Типизированный режим TypeScript вынуждает вас использовать стабильные типы переменных, что обеспечивает стабильные формы типов, что улучшает способность компилятора как к статическому, так и к динамическому анализу вашего кода, что создает _намного лучше_ оптимизированный код и останавливает (или, по крайней мере, значительно уменьшает) отказы от оптимизированный код обратно к медленно интерпретируемому коду.

Переход на TypeScript, вероятно, принесет больше пользы, чем переход на ES6, имхо.

Под типизированным режимом вы подразумеваете запрет Any?

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

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

@rjgotten Я не использовал TypeScript, но это хорошие моменты. Если вы используете среду intellisense/autocomplete для TypeScript, это может действительно помочь новым участникам, поскольку оно будет дополнять формы типов/объектов по мере внесения изменений. Правильно спроектированный, он может служить своего рода самодокументирующимся/ознакомительным/предотвращающим ошибки инструментом для тех, кто вносит изменения в код. Но ключ, вероятно, в дизайне TypeScript.

В целом, будет ли выигрыш в производительности? Это сложнее определить. Это больше художник, чем холст.

Несмотря на то, что я стремлюсь использовать TypeScript для своих собственных проектов, я, вероятно, немного более склонен согласиться с @lukeapage , в первую очередь потому, что, если кто-либо из нас не является экспертом по TypeScript, я не уверен, что мы могли бы эффективно использовать из него изначально.

Кроме того, переход на ES6 не мешает использовать TypeScript в будущем. Цель Microsoft/Google — сделать TypeScript 2.0 надмножеством ES6, чтобы мы всегда могли начать с ES6/Babel, а позже добавить правильные типы и переключиться на транспилятор TypeScript. Я подозреваю, что TypeScript собирается «выиграть» транспилируемые языки только потому, что преимущества времени компиляции/автозаполнения намного больше, чем нетипизированный JavaScript. Итак... Я думаю, это означает, что я думаю, что использование TypeScript, вероятно, неизбежно, но это не значит, что мы должны использовать его прямо сейчас.

В какой-то момент я хотел бы обсудить другой архитектурный подход к Less, но это более касательная дискуссия.

Под типизированным режимом вы подразумеваете запрет Any?

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

Однако использование типизированных параметров в функции означает, что вызывающие функции (по крайней мере, вызывающие функции, написанные на TypeScript) _должны_ соблюдать заданный тип. Это означает, что типизированные функции можно использовать для защиты стабильности типов во внутренней работе компилятора Less, где это уместно, и гарантировать, что особенно важные функции будут хорошо оптимизированы. (Не забывайте, что движки JS обычно оптимизируются на функциональном уровне...)

работа началась - https://github.com/less/less.js/tree/rollup

Довольно крутая работа. Germaine к обсуждению, я смотрел код и быстро наткнулся:

if (typeof index === 'number') {   

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

С другой стороны, может быть, это единичный и редкий пример; это просто то, что мне показалось актуальным.

Я думаю, что самое большое преимущество явных типов заключается в том, что они позволяют использовать более мощные инструменты. Найти все (и единственные) места, которые вызывают функцию или переопределяют ее, можно всего лишь с помощью сочетания клавиш. Выяснение того, какие функции доступны объектам, не требует никакой работы, а рефакторинг безопаснее, поскольку компилятор генерирует больше ошибок. Это также облегчает изучение новой кодовой базы — получить общую картину, выяснить, какая часть кода зависит, или следовать потоку кода, не запуская его, в javascript сложнее, чем в java (например), потому что типизированные редакторы более мощные.

Я еще не использовал TypeScript, поэтому не знаю, достаточно ли зрелые инструменты, чтобы они того стоили. Преимущество javascript в том, что его знают все, TypeScript менее известен.

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

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

Возможно, так оно и есть, и на самом деле, чтобы быть прагматичным, @lukeapage уже взялся за работу, поэтому я склонен сказать, что он должен сделать последний выбор в это время. :-)

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

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

Привет, ребята, как дела сейчас?

Я могу работать над этим. @matthew-dean Вы бы приняли запрос на вытягивание?

@alexlur Конечно! Меня беспокоит только рефакторинг ветки 3.x и отсутствие конфликтов слияния. Так что лучше разветвляться/разветвляться оттуда. Кроме того, с тех пор, как этот выпуск был написан, теперь существует устоявшееся соглашение об использовании src/ и dist/ . Однако lib/ иногда используется как src/ , поэтому, вероятно, нет необходимости переименовывать.

Также будет немного переписан Gruntfile, чтобы тесты использовали сборки, а не lib/ . (Что делает тест браузера, так это выполняет сборку в test/ , а не dist/ . Папка dist/ — это специальная задача Grunt для новых выпусков. При тестировании она должна собираться в test/ ) После этого, пока тесты проходят, все должно быть хорошо.

@matthew-dean Привет. Я закончил рефакторинг, но не знаю, как настроить Gruntfile для запуска тестов на новых созданных файлах.

Может быть, я могу объединить ваши изменения в отдельную ветку и посмотреть на интеграцию тестов. Я просто быстро просмотрел ваши изменения. Поправьте меня, если я ошибаюсь, но является ли at-rule неправильно узлом assignment ? Или Github просто испортил то, как это показывалось?

Хороший улов, я использовал не тот файл.

Существует ли минимальная версия браузера/Node.js, которую должен поддерживать less.js? Node.js имеет довольно хорошую поддержку Promise (начиная с версии 0.12), в то время как использование в браузере обычно предназначено для разработчиков, которые уже используют последние версии браузера.

Редактировать:

Less.js поддерживает все современные браузеры (последние версии Chrome, Firefox, Safari, IE11+ и Edge).

Только в Internet Explorer 11 нет встроенного Promise .

@алекслур
Для браузерной версии Less я бы предложил создать свойство less.Promise и установить для него значение window.Promise по умолчанию. А затем попросите Less использовать класс Promise через less.Promise .

Таким образом, у пользователей современных браузеров, а также у пользователей, у которых Promise глобально полифиллирован до загрузки Less, все будет работать волшебным образом. И пользователи, которые не хотят — или по какой-либо причине не могут — глобально полифиллировать, могут заставить все работать с помощью одного крошечного дополнительного шага. Им нужно только вручную назначить выбранную реализацию Promise на less.Promise , прежде чем фактически использовать Less.

@rjgotten @alexlur В Less.js уже настроены полифиллы Promise . Никаких дополнительных действий там делать не нужно. Большая часть кода использует этот шаблон:

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

На стороне узла эта проблема все еще открыта: https://github.com/less/less.js/issues/3121 .

Тем не менее, без какой-либо обратной связи и с довольно умеренным количеством участников я склонен просто сказать, что Node 4+ — это то, что нужно на данный момент. Мы должны обновить документы/тесты, чтобы отразить это.

@matthew-dean Он должен быть готов к объединению в отдельную ветку .

@alexlur Спасибо! Постараюсь глянуть в ближайшее время. Вероятно, будет на следующей неделе (если только у кого-то еще не хватит времени это проверить).

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

Я создал форк , переработанный в TypeScript.

Я создал форк, переработанный в TypeScript.

@glixlur 😮 вау, и все тесты пройдены? И создает идентичный less.js в dist/ ?

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

@less/core Это следует изучить, чтобы увидеть, можем ли мы автоматизировать это для одноразового преобразования - https://github.com/lebab/lebab

@matthew-dean Я отправлю вам запрос на включение, как только закончу.

@glixlur О! Ладно, в своем предыдущем пиаре ты сказал, что у тебя нет на это времени. Если вы все еще работаете над этим, 👍

@matthew-dean Я ограничусь только переходом на ES6 и оставлю часть TypeScript позже.

@glixlur Я думаю, что ES6, вероятно, самый «дружественный к сообществу» первый шаг вперед, так что это идеально. Я не уверен, что все согласны с TypeScript, но определенно поток ES6 был бы отличным.

@matthew-dean Я предполагаю, что самые низкие поддерживаемые платформы — это Node 6 и IE11?

@glixlur Appveyor в настоящее время настроен для тестирования Node 4. Не усложнит ли это задачу? В идеале это было бы преобразование Babel папки src/ в (замененные) папки lib/ (и dist/ для браузера) для распространения для Node/браузера. Поэтому я бы предположил, что Babel выполняет большую часть работы по переносу на ES5.

Готово , но нужно, чтобы тесты работали. PhantomJS устарел и не поддерживает ничего после ES5.

@glixlur Хорошо ! Re: PhantomJS, его действительно нужно заменить чем-то вроде Chromy. См.: https://github.com/less/less.js/issues/3240 .

@glixlur Кроме того, это связано с Chromy / безголовым Chrome: https://github.com/less/less.js/issues/3262

@glixlur Относительно PhantomJS - эти тесты выполняются для встроенной версии браузера, которую вы, вероятно, перенесете в ES5, верно? Почему PhantomJS не работает с пакетом вывода ES5?

@matthew-dean Да, но есть ошибка, из-за которой Symbol используется при запуске PhantomJS с файлом, переданным Babel.

@glixlur Вам нужен babel-polyfill в транспилированном выводе. Это хороший показатель того, что он еще не транспилируется правильно. См. такие проблемы, как: https://github.com/babel/babel-preset-env/issues/203 .

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@matthew-dean babel-polyfill добавляет 87,3 КБ к выходному файлу. Вы, вероятно, не хотите этого.

@гликслур
Есть и другие причины, по которым вы не хотите babel-polyfill . А именно тот факт, что он влияет на глобальное пространство имен, публикуя полифиллы на window и изменяя прототипы нативных типов, таких как Array .

Вместо этого посмотрите на пакет babel-runtime и пакет babel-plugin-transform-runtime .

Кроме того, iirc команда Babel работает над ограничением полифиллов, связанных transform-runtime , в том же духе, что и предустановленные ограничения языковых преобразований babel-env . Но их работа над ним еще не закончена и общедоступна. В конечном итоге это будет похоже на Babel 7, который в любом случае все еще находится в стадии бета-тестирования, поэтому напрямую не полезен. Но определенно желательно на будущее.

@glixlur @rjgotten А. Я должен был уточнить, что я точно не знаю, какое решение использовать re: Babel. Просто это потому, что Symbol не определено, потому что оно не заполнено полифиллом (понифилл?), что также было бы в IE11. Так что, возможно, это не полифилл, но я считаю, что при правильных настройках Babel он должен дать вам определение с ограниченной областью видимости Symbol . Так может проблема в минимальной версии браузера?

с правильными настройками Babel это должно дать вам определение Symbol с областью видимости

Это действительно будет.
Эти настройки сводятся к использованию плагина transform-runtime и его способности вводить псевдонимы для более новых встроенных модулей, таких как Symbol , вместо того, чтобы полагаться на babel-polyfill .

Должны ли фантомы устареть?

Учитывая, что он мертв?
Возможно - да.

@glixlur См.: https://github.com/less/less.js/issues/3240

Преобразование выполнено и объединено! См.: https://github.com/less/less-meta/issues/32 .

Хорошо, на этой неделе я узнал, что Class в JavaScript НЕ является просто синтаксическим сахаром для прототипов функций, что и вызвало эту проблему: https://github.com/less/less.js/issues/3414

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

господи, интересно, вызовет ли это преобразование ES6 для Less такого рода проблемы.

Хорошо: вопрос ответил, я думаю?

Я _поэтому_ не завидую буре пользователей, которые излили свое недовольство вашей работой, @matthew-dean. У вас есть мое сочувствие, чтобы справиться с этой ситуацией. :улыбка:
К счастью, кажется, никто не пошел на апокалипсис, и с этим справились организованно.

@rjgotten lol Я имею в виду, как ты мог предвидеть что-то подобное? Безопаснее всего было бы вообще не преобразовывать или никогда не использовать классы, но это делает кодовую базу менее подробной (ну, или потенциально сделает, есть много возможностей для дальнейшей очистки). Технически, (историческая) интеграция less-loader с Less была неправильным использованием API (использование недокументированного/неподдерживаемого использования API), так что это было ошибкой с их стороны, но я сочувствую людям, которые разочарованы тем, что неосновной точечный выпуск, вызывающий сбой сборки.

Например, если кто-то взламывает прототипы в вашей библиотеке, как вы защищаете код от этого??

🤷‍♂

@rjgotten

Технически, я выпустил две бета-версии после преобразования, НО... ни у кого нет бета-версий Less в их конвейере. Таким образом, нет возможности протестировать 800 000 репозиториев, которые интегрируются с Less, и запустить их тесты. С зависимостями NPM вам действительно нужно просто поставить их и посмотреть, что сломается.

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

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

Ага. Это было непросто.

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

В любом случае, основная версия или нет, вы, вероятно, в конечном итоге будете вынуждены просто «попробовать» и посмотреть, что сломается.

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

Например, если кто-то взламывает прототипы в вашей библиотеке, как вы защищаете код от этого??

Вы буквально не знаете.

Это похоже на то, как люди жалуются на то, что их тщательно организованный IL, создаваемый во время выполнения, для доступа к закрытым членам в C# ломается в второстепенных выпусках. Если вы вмешиваетесь во внутренние дела, вы должны знать, на что вы покупаете. :улыбка:

@rjgotten Говоря о рефакторинге...

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

Были некоторые дискуссии о том, будет ли ответом TypeScript или просто современный JS. Я понял, что отсутствие типов или четких объектных интерфейсов делает кодовую базу Less временами очень сложной для понимания, что не может решить никакая документация или даже JSDocs.

Я настроил новый конвейер, чтобы разрешить линтинг TypeScript _если_ у вас есть правильные типы в JSDoc, но использование JSDoc для ввода текста является более многословным/визуально шумным, чем TypeScript, и есть некоторые функции ввода, которые TS просто не поддерживает только через аннотации JSDoc. . Не существует комбинации инструментов JSDoc/ESLint, которые могли бы решить некоторые из этих проблем, которые TS предоставляет вам бесплатно.

Итак, я думаю, все, что я хочу сказать, это то, что после значительного использования TypeScript в прошлом году и нескольких лет работы с кодовой базой Less, я бы сказал, что 95% путаницы/разочарования/кривой обучения, связанной с выяснением того, как работает Less, можно было бы избежать, если бы для объектов применялись типы времени компиляции. Я часто проводил много времени в отладчике, просто устанавливая точки останова и выясняя, какие свойства объекта _фактически_ представляют собой, а не то, как они определены в файле.

Например, есть ряд функций Less, которые во время оценки полагаются на свойство $#$1$ Ruleset узла paths . Из этого конструктора вы можете сказать мне, что такое свойство paths и какую форму оно будет иметь? (Подсказка: вы не можете, потому что его там нет.)

В TypeScript (с общими настройками tsconfig) это было бы запрещено. Он даже не скомпилировался. Вы были бы вынуждены указать форму paths и точно, что в ней будет, что, в свою очередь, даст четкую, конкретную документацию (и подсказки по коду) тому, кто исследует кодовую базу.

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

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

_( Дополнение : если непонятно, я на 100% не осуждаю чью-либо историческую работу в кодовой базе Less. Есть множество вещей, которые я предложил, получил одобрение и объединил в кодовую базу, которую теперь я Я такой: "Уф, лучше бы я этого не делал" или хотел бы сделать это по-другому. И я определенно добавил вещи, которые, как я теперь понимаю, могли негативно сказаться на ремонтопригодности. Все сделали все, что могли.)_

@мэттью-дин
Я настроил новый конвейер, чтобы разрешить линтинг TypeScript, если у вас есть правильные типы в JSDoc, но использование JSDoc для ввода текста является более многословным/визуально зашумленным, чем TypeScript, и есть некоторые функции ввода, которые TS просто не поддерживает только через аннотации JSDoc. . Не существует комбинации инструментов JSDoc/ESLint, которые могли бы решить некоторые из этих проблем, которые TS предоставляет вам бесплатно.

Фактически; Я столкнулся с проблемой, когда поддержка JSDoc была так себе для вывода типов.
К счастью, вы можете использовать файлы объявлений .d.ts рядом с исходными файлами .js без необходимости полностью использовать TypeScript и компилятора.

Раньше было намного сложнее работать с файлами объявлений, но современные версии компилятора TypeScript автоматически связывают файл .d.ts рядом с файлом .js , если оба названы то же.

Это может быть то, что вы ищете.

@rjgotten Можете ли вы объяснить немного больше (или дать ссылку, если знаете хороший ресурс), как это может хорошо работать с кодовой базой Less? Например, как вы делаете это на уровне файла за файлом? Есть ли файл .d.ts для каждого модуля .js ? Или вы их группируете?

Каковы преимущества наличия файла .d.ts по сравнению с использованием только TypeScript в исходном коде? Зачем тратить время на создание файлов .d.ts вместо того, чтобы просто определять эти типы в файлах?

@rjgotten Сегодня я разговаривал с разработчиком Chevrotain, и он сказал, что занимается разработкой в ​​TS, _НО_ на самом деле он управляет файлом api.d.ts как отдельной задачей. Таким образом, любые изменения типов в исходных файлах (например, узлов дерева) не прозрачно/невидимо изменяют общедоступный API без явного изменения файла типов API.

Затем он использует тест с утверждением, что внутренние типы и типы общедоступных API совпадают -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

Способ Chevrotain — это хороший способ предотвратить случайное изменение общедоступного API. Очень надежный, если вы считаете, что вам нужен такой уровень защиты. Но также несет некоторые накладные расходы.

Относительно использования файлов объявлений .d.ts для хранения типов .js :
Это на самом деле оба.

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

Вы также можете поместить типизацию в один (набор) файлов .d.ts , например api.d.ts , а затем использовать JSDoc для явного импорта объявленных типов. Поддержка JSDoc в TypeScript имеет особый вид @typedef для поддержки синтаксиса импорта. Например

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

Использование одного связанного файла типизации является хорошей идеей, если вам нужно пройти этап транспиляции перед распространением. В таком случае то, что пользователи на самом деле будут require() или import {} , больше не будут оригинальными исходными файлами. Т.е. они не выиграют от параллельной типизации.