Простой способ проверять typescript без skipLibCheck: true

[qdanik]

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

[Cherezzabo]

Объясните лучше, как у вас настройка skipLibCheck отрубает ошибки типов в вашем коде?

[PavelBotezat]

Постараюсь :)

Если коротко - типы в .ts компилятор проверит. Если они в d.ts - пропустит. Или если его импортировать из d.ts в .ts - тоже пропустит.

Ниже подробнее.

Вот пример - простой namespace где я создал тип которого не существует, на пример - можно опечататься или забыть импортировать. Когда skipLibCheck: false то компилятор выдает ошибку.

Но как только я поставлю skibLibCheck: true - то ошибка исчезает. Дальше можно использовать этот тип и он будет работать как any, но без подсветки.

И я могу создать объект и засунуть в этот тип что угодно, на пример:

И компилятор не выдает больше ошибки.

Так же если импортировать файл с ошибкой из d.ts -> .ts то ошибки не будет:

Итого: Если в проекте используется .d.ts для каких-то типов то при skipLibCheck: true они перестают проверяться.

[Cherezzabo]

Не понятно тогда, зачем вы в проекте пишите вручную декларации типов в .d.ts, если у вас проект на TypeScript и он в целом умеет в автоматическую генерацию таких файлов при компиляции типов при сборке либы ?

[PavelBotezat]

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

[Cherezzabo]

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

[PavelBotezat]

Можно) тут уже от договоренности команды мне кажется

[SWATOPLUS]

Ничего не понял, но очень интересно.

Если я правильно понимаю, ошибка вызвана несовместимостью библиотек после обновления. И правильные шаги для этого должны быть такими:

1. Использовать lock-file и pnpm. (что бы все было детерминировано и каждая библиотека имела доступ к своим версиям зависимостей)

2. Проверить совместимость библиотек друг с другом (peer dependencies)

3. Отказаться от обновления на React 18, до того как ваша библиотека станет его поддерживать.

А вот это решение, которое глотает ошибки, может привести к трудноуловимым багам.

P.S. Использовать pre-commit хуки это плохая практика (плохо сочетается с IDE, можно тупо не застейджить фикс и закоммитить без фикса). Лучше сделайте нормальный CI + squash коммитов при мердже.

P.P.S. Ваш скрипт написан на баше (в котором, сами признаете, что не эксперт), хотя вы пишете на TS. В чем проблема написать скрипт на deno или ts-node (хотя бы ради кросплатформенности).

[PavelBotezat]

1. По поводу лок файла - можно и нужно, но при этом часто бывает ситуация когда нужна другая библиотека с новой версией у которой peer dependency обновился. При этом в проекте есть какая-то библиотека которая обновиться позже. Тут в общем от проекта зависит и от потребностей.

2. Если эти библиотеки уже пару лет в проекте, а потом реакт обновился а они еще нет тот тут это вряд ли поможет. При этом всегда нужно осторожно подходить к выбору библиотек :)

3. Можно, но нам нужны были фичи из 18 и в какой-то момент npm install перестал работать без --legacy-peer-deps. Искать среди кучи библиотека как это исправить и подбирать версии куда сложнее чем обновить все до последней версии (да и все равно рано или поздно придется)

4. По поводу глотания ошибок, они глотаются только в папке node_modules на которую особо повлиять нельзя. Да и на код они не оказывают никакого влияния. Естественно не нужно использовать все слепо и нужно проверить что это за ошибки перед использованием. Тем более это нужно воспринимать как: в нашем коде ошибок нет при коммите. И если есть какие-то реальные ошибки вызванные библиотеками, из-за того что конфиг настроен на skipLibCheck: false - компилятор их не проглотит.

5. Если в VS коде, на пример попробовать закомитить с ошибками из родного кода - вылезет окно которое трудно пропустить :)

   

   Также если посмотреть output - то ошибку из кода скрипт выводит и плохой коммит не попадет в ветку.

   

   Если появляется необходимость запушить код с ошибками, можно использовать --no-verify

   

   6. По поводу CI - он и так есть) Это нужно чтобы разработчик случайно не запушил код с ошибками и потом во время билда мы об этом узнавали.

   7. По поводу баша - мы используем уже husky кучу лет. На Windows и Mac OS скрипт работает.

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