#Sintra

Потрібно мені було зробити свіжу збірку мобільного застосунку для Сінтри, яка наразі в розробницькій паузі. Та React Native там застарів аж майже… на 2 роки! Ціла вічність просто. Звісно ж, зі свіжим XCode 16.3 він не зібрався (чотири місяці тому на 16.2 ще збирався.)

Це не вперше з ним таке — десь в коді залежностей на С++ вилазить несумісність, яку, звісно, згодом виправляють, але тільки для нещодавніх версій.

Я чесно кажучи не знаю, чому воно так нестабільно себе поводить. Чи це всі проєкти на C++ так, чи то через розробників, чи то тому, що RN не типовий продукт на iOS та потребує особливих обходів.

Почав оновлювати… а там така круговерть. Спочатку RN, потім Node, потім просто React, Babel, React Native Navigation… В якийсь момент Yarn почав відвалюватися за браком памʼяті, що є поганим знаком.

Зрештою зʼясувалося, що оновлення взагалі не можливе, бо React Native Navigation не підтримує поки навіть найстарішу версію RN, яка була виправлена для XCode 16.3. Фініш?

Наступною ідеєю я вирішив збирати проєкт на GitHub Actions, на старій версії macOS. Це майже вийшло, але застопорився на підписі застосунку, там теж щось треба багато переробляти (бо я завжди збирав та підписував локально).

І тут несподівано знайшов, що стару версію XCode можна поставити й на мою машину! Осьо сайт Xcode Releases, де є посилання навіть на доісторичні версії. Тобто встановив собі поруч /Applications/Xcode 16.2.app та на ньому, ще після кількох чомусь потрібних виправлень все зібралося.

Гадаю, Apple ускладнили розробникам життя тим, що XCode встановлюється з App Store та через це неочевидно, що старі версії взагалі можна знайти. А виявляється, навіть asdf-xcodes є!

Як висновок… певно, треба навчитися зберігати всі залежності будь-якого проєкту, а можливо, разом із тулчейном. Місце на диску значно дешевше нервів.

Вчора в підтримку Сінтри надійшов лист про те, що у нас поламані листи підтвердження підписки. По-перше, дякую автору, бо небагато хто б потрудився це зробити. По-друге, чи це ще один випадок недостачі моніторингу та насамперед тестування в проєкті двох людей? Авжеж! Бо помилка сиділа роки з два. (І ні, це далеко не перша підписка за цей час.)

Помилка крилася в неправильному шаблоні для i18next. В нас там цікаве рішення для шаблонів листів. Технічно вони використовують “Handlebars”, але на практиці шаблони стають просто рядками перекладу для i18next.

Причин було відразу дві. Одна прямо зовсім проста — неправильний префікс ключа. Знаєте, в i18next можна написати підписка на $t(subscription_interval.{{interval}}) та підставити туди, наприклад, subscription_interval.monthly. Дуже зручно. Але на це немає перевірок — якщо такого ключа немає в словнику, i18next підставить сам ключ. Що й відбулося, бо я банально переплутав subscription_interval та subscription_period.

Зате рівно тільки що дізнався, що є налаштування відсутніх ключів — в тому числі обробник missingKeyHandler, який міг би кинути помилку.

Друга причина — в моєму форматувальнику дат формат читається з того ж словнику. Дуже зручно (та може варто окремої розповіді.) Але. Словник же ж потребує обраної мови! На фронтенді це працює зрозуміло: у нас є мова користувача, вона встановлена глобально. А на бекенді немає “глобально обраної мови”, бо бекенд надсилає пошту до всіх користувачів. Тому виходило так, що в пошті цей форматувальник не знав мови, використовував хибний формат (знову без помилки…) та видавав сміття.

Розвʼязалося все передачею мови параметром lng: format = i18next.t(format_name, {lng: userLanguage}).

Отак, наче нічого складного, але години дві витратив. До речі, дуже допомогло те, що в мене принаймні були скрипти для генерації тих листів.