Как стать автором
Обновить

Комментарии 18

При понимании языка, Typescript не замедляет разработку. Напротив, приходит понимание что код получается более лаконичным и поддерживаемым.

Полностью согласен. В долгосрочной перспективе в умелых руках TypeScript только ускоряет разработку. Минимизируя количество багов и делая код понятнее. Но для неопытного разработчика в начале изучения языка TypeScript может стать проблемой. Особенно если типизация нетривиальна

Возможно я не понял, но выглядит что это не линтер плагин, нельзя ли было им решить вопрос чуть проще? (Может меньше возни language server было бы)

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

Нет, это не линтер плагин. Это плагин для TypeScript, позволяющий переопределять настройки tsconfig для заданных папок. Например, включать strict (или часть настроек из strict) постепенно при рефакторинге приложения

Ок тогда линтер тоже подошёл бы? Если у него была бы рула проверки стрикта + конечно запускать линтер проверку на пр

Вы имеете в виду что-то вроде этого https://github.com/JaroslawPokropinski/eslint-plugin-strict-null-checks?

Можно было бы пойти и по этому пути – имплементировать часть правил проверки типов на стороне eslint

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

Плюс хотелось сделать более универсальное решение, не привязанное к другим инструментам, кроме TypeScript. Чтобы разработчики смогли им пользоваться даже если кроме TypeScript на проекте ничего и нет. Или если разработчик захочет переопределять любую другую настройку, помимо strict

Да, спасибо

Плюс ко всему этому – хотелось подробнее разобраться как устроены плагины в TypeScript и как проверка типов работает под капотом

Ну чтож решение нишевое, но тем ценнее для тех случаев когда линтер не подходит.

Спасибо за статью

Очень классное начинание, но количество нюансов в настройке испугало. Мы ещё и на Angular, и на Yarn PNP. Вероятно, продолжим пользоваться этим:

https://github.com/allegro/typescript-strict-plugin

(вкратце, пускать TypeScript со стриктом отдельно для отдельных подпапок проекта)

Спасибо! Но я не совсем понял, о каком количестве нюансов идет речь? В статье разбирается процесс написания плагина. Подключение же его в проект состоит всего лишь из уставки из npm самого плагина и добавления в tsconfig:

{
  "compilerOptions": {
    "strict": false, // Default settings
    "plugins": [
      {
        "name": "ts-overrides-plugin",
        "overrides": [
          {
            "files": ["src/modern/**/*.{ts,tsx}"], // Path to files (glob) for which settings need to be overridden. Should not start with './'
            "compilerOptions": { // Settings for these files
              "strict": true,
            },
          }
        ]
      }
    ]
  }
}

Этого будет достаточно для его работы в IDE (как раз воспроизводит тот функционал, что реализует указанный вами плагин). Если же нужно отображать ошибки strict также и из консоли, то установить дополнительно ts-patch, запускать проверку типов командой tspc и отредактировать tsconfig:

{
  "compilerOptions": {
    "strict": false, // Default settings
    "plugins": [
      {
        "name": "ts-overrides-plugin",
        "transform": "ts-overrides-plugin",
        "transformProgram": true,
        "overrides": [
          {
            "files": ["src/modern/**/*.{ts,tsx}"], // Path to files (glob) for which settings need to be overridden. Should not start with './'
            "compilerOptions": { // Settings for these files
              "strict": true,
            },
          }
        ]
      }
    ]
  }
}

Да, хотелось бы и из консоли конечно, и чтобы при ng build (команда сборки проекта на Angular) тоже эти настройки использовались. У Angular свой сборщик (вернее, свои сборщики, т.к. их с недавнего времени несколько вариантов), которые уже внутри использует Webpack (в том варианте, который используем мы), свои плагины. Туда надо будет внедряться. И есть риск, что Angular использует TypeScript ещё где-нибудь под капотом, куда так просто не добраться. В общем, нетривиально.

При использовании Webpack, есть также возможность использовать данный плагин. Как при использовании ts-loader, так и fork-checker. В ридми плагина описан способ подключения

Также вторая часть статьи будет как раз про это

Рапортую - всё завелось отлично, кроме разве что ESLint'а. Подозреваю, для него нужно прокинуть ещё какие-то хуки TypeScript-компилятора, т.к. ESLint'у нужны не diagnostics, а типы переменных. Короткий пример:

const a: number | null = 5;
// eslint-disable-next-line @typescript-eslint/no-unnecessary-type-assertion
const b: number = a!;

ESLint по всей видимости использует информацию о типах из дефолтной программы, которая не strict и в которой поэтому number | null эквивалентен number.

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

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

По второй проблеме – если вам не сложно, создайте issue. Как будет время, я обязательно займусь. Но сейчас, к сожалению, большая загруженность

Обещанная проблема - чтобы плагин работал с ng build, мне пришлось пропатчить CLI plugin: https://n0paste.eu/VZwDSxc/ (не стал постить сюда простыню; ссылка протухнет через месяц). В стандартном Angular-сетапе tsconfig выглядит как

  ...
  "files": [
    "src/main.ts",
    "src/polyfills.ts"
  ],
  "exclude": [
    "src/test.ts",
    "**/*.spec.ts",
    "**/*.stories.ts"
  ]

т.е. rootFiles это только main.ts и polyfills.ts. А в getDiagnosticForFile приходит конечно каждый файл проекта. Так что в оригинальной версии у меня просто ничего не матчилось и продолжала использоваться дефолтная ts.Program.

Я почитал исходный код плагина, что вы указали. Реализация очень похожа с моей. В плане отличий в моём плагине:

  1. Можно более гибко настроить, какие именно strict правила нужно включить (например только strictNullChecks)

  2. Все файлы по умолчанию не strict. И нет необходимости добавлять //@ts-strict-ignore в каждый файл, что не strict (или добавлять exclude)

  3. Есть возможность указания glob-паттерна в paths

  4. Применены некоторые методы оптимизации из данной статьи

Зарегистрируйтесь на Хабре, чтобы оставить комментарий