Вот это действительно стоит посмотреть.

Ни кто иной как Matt Pocock сделал курс по MCP.

Его вклад в JS экосистему сложно переоценить - XState, Total TypeScript и всегда очень качественные обучающие видео.

Для меня это значит две вещи: MCP - это действительно штука, которую стоит изучить подробнее. И то, что теперь можно сделать это без лишней шелухи, с грамотным объяснением от Мэтта.

https://www.aihero.dev/model-context-protocol-tutorial

Что по трекеру?

Изначально идея была лишь в том, чтобы выложить в Google Play хоть какое-то приложение.

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

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

В общем планов много, да и как-то прикипел я к этому проекту. Прикольно наблюдать как он из простейшей поделки на Expo Go становится взрослым приложением, у которого есть своя страничка на Google Play. А дальше ведь еще больше всего.

А еще проект решил поддержать мой товарищ - UI/UX дизайнер. И теперь приложение будет еще и приятным на вид и удобным в использовании.

Понятное дело фронт работы значительно увеличился, поэтому переносим сроки релиза - предварительно на конец июня.

Кстати, если вы знаете кого-то, или возможно сами захотите присоединиться к проекту - напишите мне в личку.

Вся разработка в опен сорсе. Кроме приложения ещё есть классические фронт задачи. Из приоритетного уже понятно, что нужно делать мультиязычный лэндинг и блог на Next.js.

Только NX нормально работает с Expo

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

Сейчас существует несколько вариантов для организации монорепо - нативный функционал бандлеров (NPM/Yarn/PNPM Workspaces), NX и хайповый Turborepo.

Мой стандартный выбор - это NX. Обожаю NX.

Но тут решил посмотреть, что же предлагает Turborepo. Turbo используют популярные темплейты типа t3-stack, вообщем-то все темплейты, которые я нашёл, использовали Turbo - думаю, наверное, должно работать хорошо. 

И оно работает. До тех пор пока не делаешь собственный дев билд с помощью prebuild. С Expo Go работает прекрасно, как только делаешь пребилд - все разваливается. А без пребилда по сути нельзя делать нормальные приложения.

В моем случае билд не собирается, потому что при сборке в Turbo откуда-то появляется старая версия Котлина. Есть ещё и другие приколы - типа в Турбо нужно прямо указывать в конфиге какие энв переменные нужно передавать в билд (например ANDROID_HOME) - зачем, я так и не понял - но это не баг конечно, скорее скилл ишью с моей стороны, они решили сделать именно так, и в доке это прописано. Просто странно.

В NX в случае с Expo не работает терминал Expo CLI - не работают шорткаты a, r, shift+m и т.д. Но если запускать напрямую, не через NX CLI - то все прекрасно работает.

И вот тут основная прелесть NX. По сути если упростить, то NX сейчас - это утилита, которая раскидывает твои проекты по папкам, и корректно настраивает пути в tsconfig. Все, после этого ты можешь пользоваться своими проектами как обычно. И только если это требуется, сверху уже можно добавлять кэшинг, общий конфиг линтеров, зависимости между задачами и т.д. У NX есть куча аддонов, как от самой команды NX, так и от коммьюнити, которые позволяют расширять функционал.

В моем случае проект также работает на Bun, с Biome в качестве линтера, и забирает компонент с библиотеки, которая будет отдельным пайплайном публиковаться в NPM. Просто теперь этим стало чуть удобнее управлять.

К сожалению, релиз сегодня отменяется - Курсор удалил весь мой код

Одно из главных преимуществ Expo всегда было удобство разработки. 

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

В Expo Go не работают нативные функции, но теперь для этого появилась возможность создать кастомный клиент на подобие Expo Go, но конкретно под ваше приложение с помощью команды prebuild.

Этот клиент тоже будет просить ссылку на дев сервер и сперва я думал, что придется крутить собственный сервер, к которому будут подключаться заинтересованные лица (в моем случае дизайнер). Сделал даже пайплайн в GitHub Actions, который собирает текущий коммит в докер образ, и деплоит это все на сервер.

И оно даже работает, правда медленно - каждый раз дев сервер пересобирает бандл, что даёт задержку при первой загрузки дев версии приложения.

А оказывается все было проще. В Expo есть сервис EAS Update, который позволяет упаковать текущее состояние приложения, и открыть его из дев клиента. И никакого сервера не нужно. Достаточно ссылку дизайнеру ссылку на apk дев клиента и QR апдейта. 

А вот уже сами апдейты можно собирать в GH Actions по коммиту.

Все больше крупных компаний вводят владение AI инструментами как базовый навык для своих сотрудников.

На это раз Spotify https://x.com/tobi/status/1909251946235437514

Всё, теперь это база. Потому что работает.

Эксперимент с NativeWind закончился неудачно.

Проблема не с синтаксисом TW (работать с ним как раз очень удобно, и если нет специфичных требований в виде расширенной темизации, и тем более если делаешь прототип - очень приятно).

Проблема в том, как NativeWind сейчас работает - под капотом NativeWind преобразует ваши TW классы в React Native StyleSheet - и этот дополнительный шаг вызывает дополнительные проблемы. Во первых, это заметно во время разработки - ты добавляешь класс, и долю секунды бандлер думает, просчитывает, и добавляет нужный StyleSheet.

Во вторых, иногда он просто их не добавляет. Реально. Есть куча ишью на ГХ, где люди описывают свои пропавшие стили. В основном, такие ишью закрыты как stale, и складывается что люди просто не получают решения и уходят от NativeWind (как и я).

В вебе это в целом так же работает, но видимо из-за того, что в вебе тулинг для TW более взрослый и оптимизированный, задержек и тем более потерей стилей нет.

Выходит, что NativeWind добавляет ещё один слой в систему, в которой и так уже слишком много слоев.

Складывается впечатление, что если core команда React Native не добавит нативную стилизацию с помощью TW, комфортно работать с ним в React Native так и не получится.

В итоге, пока переехал на Tamagui - про него кстати тоже много плохого пишут, но пока он выглядит как вариант, который предоставляет достойный набор дефолтных компонентов и кастомизацию как через собственные токены, так и через нативный StyleSheet.

Последнее время не слежу за новостной повесткой и кажется упустил действительно важную новость.

Next добавляет поддержку Rspack.

А это действительно может означать увеличение скорости без сломанного проекта (в отличие от злополучного Turbopack, с котором они так носятся - ну или делают вид, потому что прогресса там никакого).

Вчера полез в исходники их вебпаковских конфигов и там действительно появились коммиты про Rspack. Пока пишут про экспериментальную поддержку, но это уже огромный прогресс. Экспериментальная поддержка стартует с последней минорной версии 15.3

Как появится свободное время поэксперементирую с рабочим проектом, чтобы "в полях" посмотреть, что работает, что нет.

https://rspack.dev/blog/rspack-next-partner

Сегодня вышел релиз OpenNext 3.6.6 с моими изменениями и я стал полноценным контрибьютором в open source.

OpenNext - это проект, который позволяет деплоить Next.js в инфраструктуру других провайдеров помимо Vercel, причем делать это похожим на Vercel способом - а именно, исполняя код необходимый для ревалидации страниц не в Node сервере, а в серверной функции облачного провайдера.

В результате отпадает необходимость держать Node сервер, а SSR и ISR остаются. Ну и кроме этого появляются другие плюшки, вплоть до того, что можно деплоить разные пути своего приложения в разные регионы - например локаль /de/ - приземлить во Франкфурт, а /en/ в Лондон. Ну и в целом OpenNext дает возможность более широкого контроля над ресурсами, которые составляют приложение.

Проблемы, которые потребовали изменений возникли при апгрейде на Next 15 - мы делали апгрейд сразу с 13 на 15 версию, и это потребовало апгрейда со 2 на 3 версию OpenNext.

А в 3 версии OpenNext перестал складывать CSS файлы в серверный бандл, и как бы они там вообще-то и не нужны, за одним исключением - если они не будут использоваться во время ревалидации.

А вот мы как раз используем - для того, чтобы собрать Critical CSS и положить его прямо в генерируемый HTML.

В итоге пришлось возвращать CSS в бандл.

Кстати нужно сказать большое спасибо команде OpenNext за быстрое ревью и комменты. Ребята открыты для общения в Discord и максимально быстро отвечают на PR.

https://github.com/opennextjs/opennextjs-aws/releases/tag/v3.6.6