React, Vite и TypeScript: начните менее чем за 2 минуты

Хотелось ли вам когда-либо читать пособие и реализовывать команды, содержащиеся в нём, одновременно? Думаю, у всех иногда возникало такое желание, но заставляли ли вы себя это сделать? Это не так важно, ведь прямо сейчас мы дадим вам возможность создать приложение (не для начинающих )с использованием трёх классных технологий параллельно с нашей статьёй. Вы сможете не волноваться о том, что у вас что-то не получится, ведь каждое действие будет расписано.

Итак, давайте создадим наш проект React + Vite + TypeScript!

Традиционно вы могли бы подумать о том, что мы будем использовать именно Create-React-App (CRA). Но что, если я скажу вам, что есть лучшая альтернатива, обеспечивающая:

Я говорю о Nx. Nx поставляется с набором плагинов, которые обладают возможностями генерации кода и помогают абстрагироваться от некоторых настроек инструментов более низкого уровня. И это может быть действительно интересно для варианта, который мы хотим рассмотреть сегодня.

Итак, давайте пойдем и создадим наш проект с использованием React + Vite + TypeScript.

Чтобы создать новый проект, просто вызовите следующую команду:

npx create-nx-workspace@latest awesomereactapp --preset=react-standalone

Обратите внимание, что awesomereactapp - это имя создаваемого приложения и папки, а --preset=react-standalone указывает Nx, какой шаблон использовать при развёртывании начальной настройки. Вы также можете вызвать его следующим образом:

npx create-nx-workspace@latest awesomereactapp

А затем выберите предпочитаемый вами вариант в командной строке терминала:

В конце концов, вы получите следующую структуру:

Во-первых, давайте запустим наше новое приложение. Просто вызовите...

npm start

... и в считанные миллисекунды ваше приложение должно обслуживаться через http://localhost:4200 /.

npm start просто вызывает скрипт, определённый в package.json:

Он передаётся nx serve, где serve - это Nx target (цель), которая должна быть вызвана. Вы можете найти её в project.json:

Здесь вы можете увидеть все цели, доступные для данного проекта, а также можете добавить свои собственные! В двух словах, Nx target содержит:

Вы можете более подробно ознакомиться с Nx docs, если хотите.

Точно так же, как и при обслуживании нашего веб-приложения, мы можем создать его с помощью

npx nx build

Это помещает выходные данные в папку dist. Теперь, когда мы увидели целевые объекты project.json, вы, вероятно, догадались, что вы можете настроить эту выходную папку в этих настройках.

Вы сразу можете провести тестирование, выполненное с использованием Vitest. Думаю, вы уже догадались, что можете просто запустить тесты с помощью команды...

npx nx test

Возможно, вы обратили внимание на папку e2e. Это полностью функционирующая установка Cypress для выполнения интеграционных или даже полных тестов.

Это отлично, потому что вам вообще не нужно ничего настраивать. Нет необходимости в...

Всё, что нам нужно сделать, это использовать команду...

npx nx e2e e2e

Поначалу, это может показаться странным, но в основном мы запускаем таргет e2e (см. e2e/project.json) в проекте e2e.

По умолчанию, эти тесты выполняются в headless mode (безголовом режиме), но вы можете воспользоваться --watch, чтобы запустить тесты в интерактивном режиме с Cypress test runner. Тогда они будут выполняться повторно всякий раз, когда мы будем менять наш исходный код.

Линтинг можно запустить, выполнив следующую команду:

npx nx lint

В корне рабочей области уже есть файл .eslintrc.json, содержащий некоторые правила для линтинга.

Установка проекта выполнена таким образом, что вы можете легко настроить Vite и Vitest. Просто откройте предварительно сгенерированный файл vite.config.ts в корне вашей рабочей области и добавьте пользовательские плагины Vite или настройте Vitest.

Nx известен своим кэшированием, которое помогает оптимизировать скорость в монорепозитории. Кэширование принимает входные данные (команду, исходные файлы, переменные среды...) и вычисляет хэш.

При каждом запуске, Nx сравнивает этот хэш с локальной папкой кэша. Если хэш существует, Nx восстанавливает вывод командной строки и потенциальные артефакты (JS, CSS,... файлы), созданные предыдущим запуском. Это помогает ускорить вычисления, потому что вы не запускаете их, если вам это не нужно.

Пока это, очевидно, имеет большой смысл в монорепозитории, это может помочь ускорить работу над проектом. Большинство проектов имеют несколько целей, таких как сборка, тестирование, линтинг. Они также могут быть кэшированы! Представьте, что у вас есть PR, в котором вы изменяете некоторые файлы *.spec.ts, потому что добавляете тест или исправляете некоторые из них. Ваш сценарий CI, вероятно, постоянно запускает все целевые объекты (build, test, lint). И он должен полностью это сделать. Но вы могли бы избежать этапа сборки, потому что ваш файл спецификации не должен влиять на результат. Таким образом, он может быть восстановлен из кэша. Необходимо запустить test и, возможно, lint, если вы запускаете линтинг также для файлов спецификаций.

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

Представьте себе приложение на витрине магазина. Вероятно, у вас будут такие доменные области, как:

Единственный способ управлять такой структурой с помощью текущего инструментария (включая CRA) - организовать эти домены в папках. Таким образом, у вас было бы что-то подобное в настройке CRA:

Большинство devtools (включая CRA) вынуждают вас создавать монолитную структуру, в которой вы разделяете свои функции по папкам. Однако папки ограничены с точки зрения изоляции; по мере роста вашего приложения, всё это может быстро выйти из-под контроля.

Мы можем создать другую, более прочную структуру с помощью Nx, выделив эти области в специальные библиотеки или модули. Они работают бок о бок с вашим приложением. Допустим, у нас есть папка с именем “domains”, которая содержит эти доменные области. Затем вы можете легко сгенерировать новую библиотеку с помощью следующей команды:

npx nx g @nrwl/react:lib checkout --directory=domains/orders/checkout --bundler=none

Приведённая выше команда создаёт новую "cheсkout" библиотеку в папке domains/orders/. Вот как это выглядит:

Обратите внимание на domains/orders/checkout/src/index.ts: это общедоступный API "checkout" библиотеки, где вы можете решить, что экспортировать, а что должно оставаться приватным в библиотеке. Этот сознательный процесс выбора того, что показывать, а что нет, приводит к гораздо более сильной инкапсуляции, чем просто структура папок. Это также значительно помогает в аспекте ремонтопригодности по мере роста вашего приложения.

При создании библиотеки автоматически создаётся отображение пути к TypeScript в tsconfig.base.json корневого уровня:

Таким образом, всё, что экспортируется из "checkout" библиотеки, может быть использовано как

import { SomeComponent } from '@awesomereactapp/domains/orders/checkout';

Вы также можете просто запустить компоновку или тестирование для этих новых библиотек:

npx nx test domains-orders-checkout

И, очевидно, кэширование (как было показано ранее) также будет работать с этими новыми библиотеками.

Другим побочным эффектом разделения вашей кодовой ба

npx nx graph

Это становится ещё интереснее, если вы установите флажок на “Группировать по папкам”, поскольку в этот момент домены становятся видимыми:

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

Чтобы помочь с этим, в Nx есть встроенное правило определения границ модуля. Проектам могут быть присвоены “теги”, такие как type:domain, type:utils, type:shared и domain:products, domain:orders, domain:auth. Эти теги могут быть назначены в project.json, например:

Затем в файле .eslintrc.base.json вы можете определить правила. Здесь, например, мы заявляем, что библиотека type:utils может зависеть только от других служебных библиотек, в то время как type:domain может зависеть как от других библиотек домена, так и от служебных библиотек.

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

Если вам интересно, вы можете прочитать больше здесь: https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4

В такой модульной структуре (как показано выше), где ваш код организован в более мелкие модули / библиотеки, очень часто данный член команды работает только в пределах одной доменной области. Следовательно, очень часто PR просто касаются подмножества всего набора библиотек. Nx поставляется с резервной командой, которая позволяет вам воспользоваться преимуществами CI, используя так называемые “affected commands”.

Допустим, мы вносим изменения в product-detail библиотеку нашего приложения. Это повлияло бы на все другие библиотеки, которые зависят от неё. Вы также можете визуализировать это, запустив...

npx nx affected:graph

Чтобы запускать задачи только для затронутых областей, используйте:

npx nx affected:

Чтобы привести конкретный пример, запустите только тесты для этих проектов:

npx nx affected:test

Если вы не являетесь разработчиком типа интерфейса командной строки и предпочитаете что-то интегрированное в вашу IDE, то у нас есть хорошие новости. Команда Nx core также поставляет специальное расширение VSCode: Nx Console.

Он имеет специальное представление в VSCode для запуска общих команд, просмотра структуры рабочей области и даже встроенного рендеринга график

Он также поставляется с контекстными меню для быстрого доступа к большинству часто используемых функций:

Чтобы рабочие пространства оставались "вечнозелеными", Nx поставляется с автоматической миграцией кода, которая:

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

npx nx migrate latest

Nx собирает установленные в данный момент пакеты и обновляет их до последней версии. Если пакет поставляется со скриптами миграции Nx, Nx собирает их в файл migrations.json. Вы можете проверить, а затем запустить их. Это значительно помогает поддерживать инструментарий вашего проекта в актуальном состоянии.

Подробнее о том, как работают миграции Nx, читайте в документации.

Если в настоящее время вы используете настройку CRA, вы можете легко перейти к настройке на основе Nx + React + Vite, выполнив следующую команду в вашем проекте CRA:

npx nx init

Подробнее читайте в документах Nx: https://nx.dev/recipes/adopting-nx/migration-cra

Готовы? Пробуйте:

npx create-nx-workspace mycoolapp --preset=react-standalone

И дайте нам знать, что вы об этом думаете :)

Статья была взята из следующего источника: