frontend — готовый фронтенд для студента-бекендера

Интернет-магазин комплектующих на React + Mantine + Vite + TypeScript. Студент его не пишет — он подключает собранную сборку и реализует под неё API. Экраны: главная с промо-блоками, каталог с фильтрами и пагинацией, карточка товара, корзина, оформление заказа, регистрация и вход, личный кабинет с историей заказов.

Публикуется как npm-пакет @hexlet/python-online-store-frontend, в пакет уезжает только dist.

Команды

make install   # npm install
make build     # tsc + vite build → dist/
make dev       # дев-сервер на :5173, проксирует /api на $API_URL (дефолт http://localhost:8080)
make types     # перегенерировать src/schema.js из ../contract/openapi.yaml
make publish   # npm publish (вручную, нужен токен)

Публикация

Первая версия 1.0.0 уезжает целью make publish, дальше make release (release-it: подъём версии, тег, npm publish). Нужен npm-токен с правом публиковать в скоуп @hexlet, он читается из ~/.npmrc.

Отказ E404 Not Found — PUT https://registry.npmjs.org/@hexlet%2f… означает отсутствие авторизации, а не отсутствие пакета. Реестр не подтверждает существование scoped-пакета неавторизованному клиенту и отвечает 404 вместо 401, поэтому сообщение указывает не туда. Различается одной командой:

$ npm whoami
npm error code E401
npm error 401 Unauthorized - GET https://registry.npmjs.org/-/whoami

Лечится npm login --scope=@hexlet или новым Automation-токеном в ~/.npmrc. Если npm whoami отвечает логином, а публикация всё равно даёт 404 — нет права публикации в скоуп.

Как он попадает в приложение

code/package.json зависит от этого пакета, make -C code build копирует его dist в public/, откуда статику раздаёт сервер студента. Запросы идут по относительным путям /api/... — тот же origin, что и приложение; абсолютного адреса API в сборке нет. Сессия живёт в httpOnly-cookie, запросы уходят с credentials: 'same-origin'.

Зависимость в code/package.json объявлена версией из реестра (^1.0.0), а пакет ещё не опубликован. Значит образ решения пока не собирается: npm ci в его первой стадии не найдёт пакет. Так сделано намеренно — контекст сборки образа это каталог решения, и file: на соседний каталог за его пределы не достаёт, то есть локальная зависимость работала бы только мимо контракта запуска. Порядок такой: сначала публикация, потом npm install в code/ рождает code/package-lock.json, и только после этого проходит первый прогон грейдера.

Ссылки на ADR в комментариях

Код перенесён из projects/ru/frontend_online_store_project (там магазин пишет студент-фронтендер), и комментарии ссылаются на решения вида «(ADR 0011)». Эти документы живут в том проекте, в docs/adr/, — здесь их нет намеренно: дублировать журнал решений в двух репозиториях значит завести второй источник правды. Ссылки оставлены как след: по номеру решение находится в исходном проекте.

Типы клиента

src/schema.js — сгенерированный артефакт цепочки TypeSpec → OpenAPI → TypeBox (@geut/openapi-box, пакета openapi-box в npm не существует). Он коммитится, чтобы сборка не зависела от тулчейна контракта, и пересобирается целью make types из ../contract/openapi.yaml. Руками его не правят: расхождение фронтенда с контрактом должно быть ошибкой компиляции.

Тексты интерфейса

Тексты лежат в src/locales/ru/translation.json, а собирает этот файл i18next-cli из вызовов t (make i18n-extract, настройки — i18next.config.ts). Объявления ресурсов в src/@types генерирует make i18n-types. И то и другое коммитится и руками не правится.

Ключ передаётся селектором, а не строкой: t(($) => $.nav.catalog). Путь проверяет компилятор, поэтому опечатка не доживает до экрана. Ключи, которые собираются по данным (тексты ошибок по problem.type), объявлены селекторами в словарях — lib/problems.ts; статически их не видно, и в i18next.config.ts они перечислены в preservePatterns, иначе extract вычистил бы их как неиспользуемые.

Чего здесь намеренно нет

• Мониторинга фронтенда. Vite подставляет VITE_* на сборке, а собираем этот пакет мы — студент свой DSN сюда не запечёт. Мониторинг в проекте требуется только от бэкенда.
• Любой реализации API. Всё, что фронт знает о бэкенде, — контракт: относительные пути /api/* и формы ответов. Готового решения задачи бекендера в этом каталоге быть не должно.