Делаем TypeScript по-настоящему «строго типизированным»

TypeScript утверждает, что является строго типизированным языком программирования, построенным на основе JavaScript и предоставляющим лучшие инструменты в любом масштабе. Однако включает тип , который часто может неявно проникнуть в базу кода и привести к потере многих преимуществ TypeScript. TypeScript any В этой статье рассматриваются способы взять под контроль тип в проектах TypeScript. Будьте готовы раскрыть возможности TypeScript, добившись максимальной безопасности типов и улучшив качество кода. any Недостатки использования Any в TypeScript TypeScript предоставляет ряд дополнительных инструментов для улучшения опыта и производительности разработчиков: Это помогает обнаружить ошибки на ранних стадиях разработки. Он предлагает отличное автодополнение для редакторов кода и IDE. Он позволяет легко проводить рефакторинг больших баз кода с помощью фантастических инструментов навигации по коду и автоматического рефакторинга. Он упрощает понимание базы кода, предоставляя дополнительную семантику и явные структуры данных через типы. Однако как только вы начнете использовать тип в своей кодовой базе, вы потеряете все перечисленные выше преимущества. тип — это опасная лазейка в системе типов, и его использование отключает все возможности проверки типов, а также все инструменты, которые зависят от проверки типов. В результате теряются все преимущества TypeScript: пропускаются ошибки, редакторы кода становятся менее полезными и многое другое. any any Например, рассмотрим следующий пример: function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any В приведенном выше коде: Вы пропустите автозаполнение внутри функции . Когда вы вводите в вашем редакторе вам не будут предложены правильные варианты доступных методов для . parse data. data В первом случае возникает поскольку мы передали число вместо строки. TypeScript не может выделить ошибку, поскольку отключает проверку типов. TypeError: data.split is not a function any Во втором случае переменная также имеет тип . Это означает, что однократное использование может оказать каскадный эффект на большую часть кодовой базы. res2 any any Использовать допустимо только в крайних случаях или для нужд прототипирования. В общем, лучше избегать использования, чтобы получить максимальную отдачу от TypeScript. any any Откуда взялся тип Any Важно знать об источниках типа в базе кода, поскольку явное написание — не единственный вариант. Несмотря на все наши усилия избежать использования типа, иногда он может неявно проникнуть в базу кода. any any any В кодовой базе есть четыре основных источника типа: any Параметры компилятора в tsconfig. Стандартная библиотека TypeScript. Зависимости проекта. Явное использование в кодовой базе. any Я уже писал статьи « и по первым двум пунктам. Пожалуйста, ознакомьтесь с ними, если вы хотите улучшить безопасность типов в своих проектах. Ключевые аспекты tsconfig» «Улучшение типов стандартных библиотек» На этот раз мы сосредоточимся на автоматических инструментах для управления появлением типа в базе кода. any Этап 1. Использование ESLint — популярный инструмент статического анализа, используемый веб-разработчиками для проверки лучших практик и форматирования кода. Его можно использовать для обеспечения соблюдения стилей кодирования и поиска кода, который не соответствует определенным рекомендациям. ESLint ESLint также можно использовать с проектами TypeScript благодаря плагину . Скорее всего, этот плагин уже установлен в вашем проекте. Но если нет, вы можете следовать официальному . typectipt-eslint руководству по началу работы Наиболее распространенная конфигурация выглядит следующим образом: typescript-eslint module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, }; Эта конфигурация позволяет понимать TypeScript на уровне синтаксиса, что позволяет вам писать простые правила eslint, которые применяются к типам, написанным вручную, в коде. Например, вы можете запретить явное использование . eslint any набор настроек содержит тщательно отобранный набор правил ESLint, направленных на повышение корректности кода. Хотя рекомендуется использовать всю предустановку, для целей этой статьи мы сосредоточимся только на правиле . recommended no-explicit-any нет-явного-любого Строгий режим TypeScript предотвращает использование подразумеваемого , но не препятствует явному использованию. Правило помогает запретить ручное написание -либо в кодовой базе. any any no-explicit-any any // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response ): Array {} // ✅ Correct function parsePokemons(data: Response ): Array {} // ❌ Incorrect function reverse >(array: T): T {} // ✅ Correct function reverse >(array: T): T {} Основная цель этого правила – предотвратить использование внутри команды. Это средство укрепления согласия команды с тем, что использование в проекте не рекомендуется. any any Это важнейшая цель, поскольку даже однократное использование из них может оказать каскадное воздействие на значительную часть кодовой базы из-за . Однако до достижения максимальной типовой безопасности еще далеко. any вывода типов Почему «никакого явного» недостаточно Хотя мы уже имели дело с явным использованием , в зависимостях проекта все еще существует множество подразумеваемых , включая пакеты npm и стандартную библиотеку TypeScript. any any Рассмотрим следующий код, который, вероятно, можно увидеть в любом проекте: const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any И переменным , и неявно был присвоен тип. Ни ни строгий режим TypeScript не предупредят нас в этом случае. Еще нет. pokemons settings any no-explicit-any Это происходит потому, что типы для и взяты из стандартной библиотеки TypeScript, где эти методы имеют явную аннотацию . Мы по-прежнему можем вручную указать лучший тип для наших переменных, но в стандартной библиотеке встречается около 1200. Практически невозможно запомнить все случаи, когда мог проникнуть в нашу кодовую базу из стандартной библиотеки. response.json() JSON.parse() any any any То же самое касается внешних зависимостей. В npm много плохо типизированных библиотек, большинство из которых до сих пор написаны на JavaScript. В результате использование таких библиотек может легко привести к появлению большого количества неявных в кодовой базе. any В общем, у еще есть много способов проникнуть в наш код. any Этап 2. Расширение возможностей проверки типов В идеале нам хотелось бы иметь в TypeScript настройку, которая бы заставляла компилятор жаловаться на любую переменную, получившую тип по какой-либо причине. К сожалению, такой настройки в настоящее время не существует и не ожидается. any Мы можем добиться такого поведения, используя режим проверки типов плагина . Этот режим работает в сочетании с TypeScript для предоставления полной информации о типах от компилятора TypeScript в правила ESLint. С помощью этой информации можно писать более сложные правила ESLint, которые существенно расширяют возможности TypeScript по проверке типов. Например, правило может найти все переменные типа, независимо от того, каким образом были получены. typescript-eslint any any Чтобы использовать правила с учетом типов, вам необходимо немного настроить конфигурацию ESLint: module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, }; Чтобы включить вывод типа для , добавьте в конфигурацию ESLint. Затем замените пресет на . Последний пресет добавляет около 17 новых мощных правил. В рамках данной статьи мы остановимся только на пяти из них. typescript-eslint parserOptions recommended recommended-type-checked нет-небезопасный-аргумент Правило ищет вызовы функций, в которых переменная типа передается в качестве параметра. Когда это происходит, проверка типов теряется, а также теряются все преимущества строгой типизации. no-unsafe-argument any Например, давайте рассмотрим функцию , которая требует объект в качестве параметра. Предположим, мы получаем JSON, анализируем его и получаем тип. saveForm any // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`. Когда мы вызываем функцию с этим параметром, правило помечает ее как небезопасную и требует от нас указать соответствующий тип для переменной . saveForm no-unsafe-argument value Это правило достаточно мощное, чтобы глубоко проверять вложенные структуры данных в аргументах функции. Поэтому вы можете быть уверены, что передача объектов в качестве аргументов функции никогда не будет содержать нетипизированные данные. // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. }); Лучший способ исправить ошибку — использовать TypeScript или библиотеку проверки, например или . Например, давайте напишем функцию , которая сужает точный тип анализируемых данных. сужение типов Zod Superstruct parseFormValues // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues); Обратите внимание, что разрешено передавать тип в качестве аргумента функции, которая принимает , поскольку при этом не возникает проблем с безопасностью. any unknown Написание функций проверки данных может оказаться утомительной задачей, особенно при работе с большими объемами данных. Поэтому стоит рассмотреть возможность использования библиотеки проверки данных. Например, для Zod код будет выглядеть так: // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues); нет-небезопасное-назначение Правило ищет назначения переменных, в которых значение имеет тип. Такие присваивания могут ввести компилятор в заблуждение, заставив его думать, что переменная имеет определенный тип, тогда как на самом деле данные могут иметь другой тип. no-unsafe-assignment any Рассмотрим предыдущий пример анализа JSON: // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value Благодаря правилу мы можем перехватить тип даже до того, как передать куда-либо еще. Стратегия исправления остается прежней: мы можем использовать сужение типа, чтобы придать значению переменной определенный тип. no-unsafe-assignment any formValues // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues нет-небезопасного-доступа к членам и не-небезопасного-вызова Эти два правила срабатывают гораздо реже. Однако, исходя из моего опыта, они действительно полезны, когда вы пытаетесь использовать плохо типизированные сторонние зависимости. Правило запрещает нам доступ к свойствам объекта, если переменная имеет тип, поскольку она может иметь значение или . no-unsafe-member-access any null undefined Правило не позволяет нам вызывать переменную типа как функцию, поскольку она может не быть функцией. no-unsafe-call any Давайте представим, что у нас есть плохо типизированная сторонняя библиотека под названием : untyped-auth // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value. Линтер выделяет две проблемы: Вызов функции может быть небезопасным, поскольку мы можем забыть передать ей важные аргументы. authenticate Чтение свойства из объекта небезопасно, поскольку в случае неудачной аутентификации оно будет равно . name userInfo null Лучший способ исправить эти ошибки — рассмотреть возможность использования библиотеки со строго типизированным API. Но если это невозможно, вы можете самостоятельно . Пример с фиксированными типами библиотек будет выглядеть так: дополнить типы библиотеки // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); } нет небезопасного возврата Правило помогает случайно не вернуть тип из функции, которая должна возвращать что-то более конкретное. Такие случаи могут ввести компилятор в заблуждение, заставив его думать, что возвращаемое значение имеет определенный тип, тогда как на самом деле данные могут иметь другой тип. no-unsafe-return any Например, предположим, что у нас есть функция, которая анализирует JSON и возвращает объект с двумя свойствами. // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null Функция может привести к ошибкам во время выполнения в любой части программы, где она используется, поскольку анализируемое значение не проверяется. Правило предотвращает такие проблемы во время выполнения. parseForm no-unsafe-return Это легко исправить, добавив проверку, гарантирующую, что проанализированный JSON соответствует ожидаемому типу. На этот раз давайте воспользуемся библиотекой Zod: // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); } Примечание о производительности Использование правил с проверкой типов приводит к снижению производительности ESLint, поскольку для вывода всех типов он должен вызывать компилятор TypeScript. Это замедление в основном заметно при запуске линтера в pre-commit хуках и в CI, но не заметно при работе в IDE. Проверка типов выполняется один раз при запуске IDE, а затем типы обновляются по мере изменения кода. Стоит отметить, что простой вывод типов работает быстрее, чем обычный вызов компилятора . Например, в нашем последнем проекте с примерно 1,5 миллионами строк кода TypeScript проверка типа с помощью занимает около 11 минут, в то время как дополнительное время, необходимое для загрузки правил ESLint с учетом типов, составляет всего около 2 минут. tsc tsc Для нашей команды дополнительная безопасность, обеспечиваемая использованием правил статического анализа с учетом типов, стоит того. В небольших проектах это решение принять еще проще. Заключение Контроль использования проектов TypeScript имеет решающее значение для достижения оптимальной безопасности типов и качества кода. Используя плагин , разработчики могут выявлять и устранять любые вхождения типа в своей кодовой базе, что приводит к созданию более надежной и удобной в обслуживании кодовой базы. any typescript-eslint any При использовании правил eslint с учетом типов появление ключевого слова в нашей кодовой базе будет преднамеренным решением, а не ошибкой или недосмотром. Такой подход ограждает нас от использования в нашем собственном коде, а также в стандартной библиотеке и сторонних зависимостях. any any В целом, линтер с учетом типов позволяет нам достичь уровня безопасности типов, аналогичного уровню статически типизированных языков программирования, таких как Java, Go, Rust и других. Это значительно упрощает разработку и сопровождение крупных проектов. Надеюсь, вы узнали что-то новое из этой статьи. Спасибо за чтение! Полезные ссылки Библиотека: typescript-eslint Статья: Ключевые моменты в tsconfig Статья: Улучшение типов стандартных библиотек Документы: сужение типов в TypeScript Документы: вывод типов в TypeScript Библиотека: Зод Библиотека: Суперструктура