Ускорение начальной компиляции в watch и incremental режимах в TS
Я писал про инкрементальную компиляцию в TS, которая позволяет ускорить последующие компиляции в разы. Однако, оказалось, что первый запуск может быть аж в 3 раза дольше обычной компиляции. Такая же проблема существует и про использовании watch режима.
Тобиас Копперс (фаундер и мэйнтэйнер вебпака) открыл пул-реквест с фиксом этого поведения. В watch и incremental режимах тайпскрипту необходимо вычислять две дополнительные сущности для каждого модуля, чтобы определить какие модули нужно инвалидировать.
Первая это «shape». По сути это контент, который получается при генерации declaration file (d.ts).
Вторая это «referenced modules». Здесь всё очевидней — это граф модулей, который зависят от измененного модуля.
Идеи рефакторинга:
1. Лениво вычислять shape и referenced modules во время первой инвалидации.
2. Если старый shape не известен и есть referenced modules, то инвалидировать модули при изменении контента файла, а не его shape.
3. Инвалидировать модуль даже если изменились только импортируемые в него модули, т.к. проверка на эскпортируемые дороже.
Как результат, начальная компиляция в 3 раза быстрее при использовании флагов —incremental или —watch. А сам ПР образцово-показательный из категории «как нужно описывать свои изменения».
Я писал про инкрементальную компиляцию в TS, которая позволяет ускорить последующие компиляции в разы. Однако, оказалось, что первый запуск может быть аж в 3 раза дольше обычной компиляции. Такая же проблема существует и про использовании watch режима.
Тобиас Копперс (фаундер и мэйнтэйнер вебпака) открыл пул-реквест с фиксом этого поведения. В watch и incremental режимах тайпскрипту необходимо вычислять две дополнительные сущности для каждого модуля, чтобы определить какие модули нужно инвалидировать.
Первая это «shape». По сути это контент, который получается при генерации declaration file (d.ts).
Вторая это «referenced modules». Здесь всё очевидней — это граф модулей, который зависят от измененного модуля.
Идеи рефакторинга:
1. Лениво вычислять shape и referenced modules во время первой инвалидации.
2. Если старый shape не известен и есть referenced modules, то инвалидировать модули при изменении контента файла, а не его shape.
3. Инвалидировать модуль даже если изменились только импортируемые в него модули, т.к. проверка на эскпортируемые дороже.
Как результат, начальная компиляция в 3 раза быстрее при использовании флагов —incremental или —watch. А сам ПР образцово-показательный из категории «как нужно описывать свои изменения».