Проверка в CI/CD происходит только для тех файлов, которые изменились в рамках задачи
А если в таком случае изменится файл A, который в свою очередь импортируется в файле B (который не был изменен), получится ли отследить, что файл A мог поломать B?
Спасибо за упоминание в статье и интересный материал!
Пара вопросов:
В случае с IDE, как вы решаете кейс, когда в одной папке располагаются сразу много файлов и вы хотите включить стрикт только для части из них? Из очевидного приходит в голову — переместить часть файлов в другую папку. Но это повлечет к изменениям в структуре проекта, что не всегда может быть приятно
Не совсем понял часть про "Взаимодействие с сервером TypeScript". В каких кейсах это используется?
При использовании Webpack, есть также возможность использовать данный плагин. Как при использовании ts-loader, так и fork-checker. В ридми плагина описан способ подключения
Спасибо! Но я не совсем понял, о каком количестве нюансов идет речь? В статье разбирается процесс написания плагина. Подключение же его в проект состоит всего лишь из уставки из 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,
},
}
]
}
]
}
}
Можно было бы пойти и по этому пути – имплементировать часть правил проверки типов на стороне eslint
Но с линтером были свои проблемы на проекте. В пайплайне он не запускался, носил больше информационный характер. Поэтому в коде накопилось достаточно много ошибок, которые нужно было бы исправить
Плюс хотелось сделать более универсальное решение, не привязанное к другим инструментам, кроме TypeScript. Чтобы разработчики смогли им пользоваться даже если кроме TypeScript на проекте ничего и нет. Или если разработчик захочет переопределять любую другую настройку, помимо strict
Нет, это не линтер плагин. Это плагин для TypeScript, позволяющий переопределять настройки tsconfig для заданных папок. Например, включать strict (или часть настроек из strict) постепенно при рефакторинге приложения
Полностью согласен. В долгосрочной перспективе в умелых руках TypeScript только ускоряет разработку. Минимизируя количество багов и делая код понятнее. Но для неопытного разработчика в начале изучения языка TypeScript может стать проблемой. Особенно если типизация нетривиальна
Требования к технической и визуальной составляющей фронтендов растет, фокусы смещаются в сторону удобства использования, UX, консистентного дизайна. Даже в b2b интерфейсах. Поэтому растет и потребность в экспертах в этой области
Необходимость использования, разработки дизайн-систем, тулинга, постоянное общение с дизайнерами "на одном языке", экспертиза во фронтовой инфраструктуре – всё это не всегда получается совмещать ещё и с разработкой на бэкенде
Само собой, мы не отказываемся от фуллстеков. Есть проекты, где не так важна именно "внешняя" сторона фронтенда, а больше инженерная экспертиза. Есть фуллстеки, которые могут и хотят уделять достаточно времени и сил на фронтовые задачи, хорошо верстают. Но на тех проектах, где нужно быть фуллтайм погруженным во фронтовый контекст, мы делаем выбор в сторону фронтендеров. И таких проектов сейчас достаточно много
Я смотрел в эту сторону. Мы используем tsc только для проверки типов (no-emit: true). Аналогично работе webpack-fork-ts-checker или vite-plugin-checker. К сожалению, project references не работают без физической сборки js/d.ts файлов
Как вы правильно отметили, в WebStorm существует проблема, которая решается добавлением алиаса в tsconfig.json
"paths": {
"#*": [
"*"
]
},
Но это приводит к проблемам, в случае использования монорепы с воркспейсами. Например, в воркспейсе @app/ui есть файл shared/utils.ts и в @app/main есть аналогичный файл shared/utils.ts
Тогда при выполнении tsc в @app/main мы получаем ошибку:
Module '"#shared/utils"' has no exported member 'UIConfig'
В общем, проблемы из-за коллизий псевдонимов путей в двух воркспейсах. При удалении paths из tsconfig.json проблема пропадает, но автоимпорты и go to definition в IDE перестают работать корректно
Кажется, это мой комментарий 4-летний давности. Почему-то отображается, что был добавлен 52 минуты назад. Раз уж я тут - перечитал код. Тут не хватает двух фигурных скобок, а самое главное - та самая "висящая" стрелочная функция не обёрнута в dispatch:
Код
return (
// Теперь мы хотим обновить данные внутри дерева
// для этого нам нужно как-то получить самое актуальное состояние
// этого дерева в момент вызова экшена, можно сделать это через callback:
<div
onClick={() => {
// Сделаем так, чтобы экшен возвращал callback,
// который внутри testReducer будет передавать самый актуальный state
dispatch(state => {
const { tree_1 } = state;
return {
tree_1: {
...tree_1,
tree_2_1: {
...tree_1.tree_2_1,
tree_3_1: `tree_3_1 UPDATE`,
},
},
};
});
}}
>
{JSON.stringify(state)}
</div>
);
Не могли бы Вы пояснять, что происходит в данном примере? Почему стрелочная функция просто «висит» внутри onClick? Попытался скопировать данный код в IDE и насчитал минимум 4 синтаксических ошибки.
Код
...
return (
// Теперь мы хотим обновить данные внутри дерева
// для этого нам нужно как-то получить самое актуальное состояние
// этого дерева в момент вызова экшена, можно сделать это через callback:
<div onClick={() => {
// Сделаем так, чтобы экшен возвращал callback,
// который внутри testReducer будет передавать самый актуальный state
(state) => {
const {tree_1} = state;
return {
tree_1: {
...tree_1,
tree_2_1: {
...tree_1.tree_2_1,
tree_3_1: 'tree_3_1 UPDATE'
},
},
};
}>
{JSON.stringify(state)}
</div>
)
...
https://www.chrisdalke.com/doom.svg
Спасибо за ответ!
А если в таком случае изменится файл A, который в свою очередь импортируется в файле B (который не был изменен), получится ли отследить, что файл A мог поломать B?
Спасибо за упоминание в статье и интересный материал!
Пара вопросов:
В случае с IDE, как вы решаете кейс, когда в одной папке располагаются сразу много файлов и вы хотите включить стрикт только для части из них? Из очевидного приходит в голову — переместить часть файлов в другую папку. Но это повлечет к изменениям в структуре проекта, что не всегда может быть приятно
Не совсем понял часть про "Взаимодействие с сервером TypeScript". В каких кейсах это используется?
По этой проблеме я создал issue, описал в комменте, что сейчас получилось выяснять. Но пока прогноз неутешительный.
По второй проблеме – если вам не сложно, создайте issue. Как будет время, я обязательно займусь. Но сейчас, к сожалению, большая загруженность
При использовании Webpack, есть также возможность использовать данный плагин. Как при использовании ts-loader, так и fork-checker. В ридми плагина описан способ подключения
Также вторая часть статьи будет как раз про это
Я почитал исходный код плагина, что вы указали. Реализация очень похожа с моей. В плане отличий в моём плагине:
Можно более гибко настроить, какие именно strict правила нужно включить (например только strictNullChecks)
Все файлы по умолчанию не strict. И нет необходимости добавлять //@ts-strict-ignore в каждый файл, что не strict (или добавлять exclude)
Есть возможность указания glob-паттерна в paths
Применены некоторые методы оптимизации из данной статьи
Спасибо! Но я не совсем понял, о каком количестве нюансов идет речь? В статье разбирается процесс написания плагина. Подключение же его в проект состоит всего лишь из уставки из npm самого плагина и добавления в tsconfig:
Этого будет достаточно для его работы в IDE (как раз воспроизводит тот функционал, что реализует указанный вами плагин). Если же нужно отображать ошибки strict также и из консоли, то установить дополнительно ts-patch, запускать проверку типов командой tspc и отредактировать tsconfig:
Плюс ко всему этому – хотелось подробнее разобраться как устроены плагины в TypeScript и как проверка типов работает под капотом
Вы имеете в виду что-то вроде этого https://github.com/JaroslawPokropinski/eslint-plugin-strict-null-checks?
Можно было бы пойти и по этому пути – имплементировать часть правил проверки типов на стороне eslint
Но с линтером были свои проблемы на проекте. В пайплайне он не запускался, носил больше информационный характер. Поэтому в коде накопилось достаточно много ошибок, которые нужно было бы исправить
Плюс хотелось сделать более универсальное решение, не привязанное к другим инструментам, кроме TypeScript. Чтобы разработчики смогли им пользоваться даже если кроме TypeScript на проекте ничего и нет. Или если разработчик захочет переопределять любую другую настройку, помимо strict
Нет, это не линтер плагин. Это плагин для TypeScript, позволяющий переопределять настройки tsconfig для заданных папок. Например, включать strict (или часть настроек из strict) постепенно при рефакторинге приложения
Полностью согласен. В долгосрочной перспективе в умелых руках TypeScript только ускоряет разработку. Минимизируя количество багов и делая код понятнее. Но для неопытного разработчика в начале изучения языка TypeScript может стать проблемой. Особенно если типизация нетривиальна
У меня на keenetic hopper команда выглядит как no opkg dns-override
Требования к технической и визуальной составляющей фронтендов растет, фокусы смещаются в сторону удобства использования, UX, консистентного дизайна. Даже в b2b интерфейсах. Поэтому растет и потребность в экспертах в этой области
Необходимость использования, разработки дизайн-систем, тулинга, постоянное общение с дизайнерами "на одном языке", экспертиза во фронтовой инфраструктуре – всё это не всегда получается совмещать ещё и с разработкой на бэкенде
Само собой, мы не отказываемся от фуллстеков. Есть проекты, где не так важна именно "внешняя" сторона фронтенда, а больше инженерная экспертиза. Есть фуллстеки, которые могут и хотят уделять достаточно времени и сил на фронтовые задачи, хорошо верстают. Но на тех проектах, где нужно быть фуллтайм погруженным во фронтовый контекст, мы делаем выбор в сторону фронтендеров. И таких проектов сейчас достаточно много
Прошу прощения, вы уже ответили на этот вопрос. Ещё раз спасибо!
Спасибо! Попробуем. А по скорости сборки есть существенная разница?
Я смотрел в эту сторону. Мы используем
tscтолько для проверки типов (no-emit: true). Аналогично работеwebpack-fork-ts-checkerилиvite-plugin-checker. К сожалению, project references не работают без физической сборки js/d.ts файловСпасибо огромное за статью! Всё получилось, но:
Как вы правильно отметили, в WebStorm существует проблема, которая решается добавлением алиаса в
tsconfig.jsonНо это приводит к проблемам, в случае использования монорепы с воркспейсами. Например, в воркспейсе
@app/uiесть файлshared/utils.tsи в@app/mainесть аналогичный файлshared/utils.tsТогда при выполнении
tscв@app/mainмы получаем ошибку:В общем, проблемы из-за коллизий псевдонимов путей в двух воркспейсах. При удалении
pathsизtsconfig.jsonпроблема пропадает, но автоимпорты и go to definition в IDE перестают работать корректноКажется, это мой комментарий 4-летний давности. Почему-то отображается, что был добавлен 52 минуты назад. Раз уж я тут - перечитал код. Тут не хватает двух фигурных скобок, а самое главное - та самая "висящая" стрелочная функция не обёрнута в dispatch:
Код
Очень странно, я не писал этот комментарий) И вообще не читал эту статью. Почему комментарий оказался здесь от моего имени - не понимаю