Book

centos 8 trac и mercurial

А что в центосе есть из багтрекеров? Trac пропал из EPEL. Я так понимаю, альтернатива либо собирать trac самому, либо неподдерживаемый докер имидж, собранный индусами.

Аналогично с mercurial-server (но его по-моему и не было). Есть ли ssh-пуши для меркуриала чуть более продвинутые, чем родные?
Book

Рабочая область языка

> как именно формализовать рабочую область языка?

Есть несколько вариантов. Например:

1. Если проект X писать на языке Y, и проект провалится, будет ли обвинён выбор языка?

Ну то есть игру или архиватор на С++ писать - риска обвинения нет.

2. Если на форуме любителей Y задавать вопросы по проблемам в проекте Y, есть ли вероятность получить квалифицированный ответ?

Грубо говоря, SO по JS завалено нубами, и ответ на трудный вопрос получить трудно, так как даннинг-крюгеровцы набигают, а опытные товарищи не мониторят.

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

3. Разбив инструментально-библиотечную поддержку по областям: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
Book

С - слабая типизация

Всё та же история. Выяснилось что сорцы не просто 1 ревизия 2 файлов в 2 копиях - они ещё и нерабочие. Видимо, я подумал что раз оно собирается - то оно и работает. Щаз.

В-общем я перепутал синтаксис и вместо async foo => { ... } написал foo => async () { ... }

И кроме того я поленился, и написал в .d.ts, что эта функция возвращает any.

А должна была быть функция, принимающая foo и возвращающая Promise<String>. Ну и получилось что она стала возвращать не промис, а функцию. Но с этой функцией работал кусок жс-кода, написанный не мной, и этот кусок умел работать как с промисами строк, так и со строками.

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

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

Так и прошёл день. Завтра буду дальше разбираться.
Book

Мержим в монорепу-2

Оказалось, что мало того, что 1 коммит - так ещё и сорцы были закоммичены в 2 экземплярах. Слава богу, в двух одинаковых экземплярах. И 2 файла сорцов - это заготовки, копи-паста из другого места. Короче мой монументальный проект импорта истории коммитов из гита в меркуриал совсем не имел смысла. Ну чо, зато закрепил пройденный ранее материал (с hg-git я дружу давно) и узнал, что ответ с SO про то, как в hggit клонировать локальные репы - неправильный. Не надо указывать схему, просто путь, и он сам понимает, что это гит, только надо чтобы git.exe был в PATH.

В-общем скопировал солюшен и проект.

Но мне этого оказалось мало, и я ещё потратил полчасика на то, чтобы билд-продукты ложились куда положено, и это всё подхватывалось по ctrl-f5 и генерировало стектрейсы с учётом sourceMaps.

1. Куда нужно - это снаружи сорс-контрола, а не JS-рядом-с-TS. Сишные объекты и экзешники туда кладутся на ура, так что прописал пару путей - типа outDir: "../../../foo/bar" в tsconfig.js

2. Для Ctrl-F5 в свойствах проекта прописал путь к главному файлу в аутпут-каталоге, и NODE_PATH=foo\node_modules, чтобы зависимости находились. Они у меня тоже лежат не как у людей, а в специально отведённом месте. На линуксовом продакшене, впрочем, лежат таки как у людей - в ~/node_modules внутриконтейнерного юзера.

3. Для стектрейсов надо установить source-map-support и передавать ноде --require source-map-support/register

Теперь надо это всё запушить на линукс-виртуалку, играющую у меня роль CI/CD. И там уже заниматься созданием имиджа.

И да, чтобы 2 раза не вставать - MS внезапно напоследок выпустила обновление 2020-1 для семёрки, и очередное 250 мб обновление студии - они каждую неделю что-то закрывают, что немного заёбывает, но это повод отлынивать от работы, как в xkcd было "compiling".
Book

Мержим в монорепу

TLDR: промучался полчаса, но в результате понял что это не нужно

Я некоторое время (годы) писал на жс без IDE. А тут решил (тоже уже давненько) писать на TS и в Студии. Ну в студии 2019 изкоробочно Git, так что для нового компонента я сделал (пресловутые 3 месяца назад) мини пилотный проект - создал проект визардом в дефолтовой папке Студии (они исправились и создают в %userprofile%\source\repos вместо "моих документов") налепил туда нужную функциональность, поправил руками tsconfig.json и убедился, что в студии не поломалось (раньше ломалось).

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

Ну у меня был уже настроен hg-git, но в данной конфигурации он не работал. Ну и я мучался искал полчаса, в чём же проблема. Оказалось, меркуриал не находит git.exe. Ну я нашёл ему git.exe обрезанный внутри Студии, открыл cmd, добавил в нём локально Git в PATH, и всё сконвертировалось.

Сделал из меркуриаловской версии репы пулл монорепы, с ключиком -f для пулла несвязанной репы - но оно отпало на подрепах. Причём сообщения об ошибках совершенно дебильные.

hg clone %userprofile%\source\repos\gitrepa hgrepa
cd hgrepa
hg pull -f ..\monorepa
hg merge MONOREPAHEAD

В этом места падает с сообщением, внимание, "подрепа %userprofile%\source\repos\gitrepa\hgpodrepa не найдена"

Решилось совершенно дебильным методом: cp -R monorepa\hgpodrepa %userprofile%\source\repos\gitrepa

Ну то есть я меркуриаловскую подрепу тупо как подкаталог поместил в гитовую репу, даже ничего не коммитил. И прокатило!

Но тут обнаружилось, что в гитрепе всего 3 коммита: импорт, добавление .gitignore и собственно добавление всего остального. Ну то есть нахуй-нахуй, завтра тупо скопирую файлики и создам 1 коммит