ES модули в nodejs перестают быть экспериментальными

Уже на следующей неделе ESM будут помечены как стабильные. При этом некоторые саб-фичи всё ещё остаются экспериментальными, правда я не нашёл о чём именно речь 🙁

Видимо речь о таких штукак как import.meta.main и подобных.

Поддержка Hermes в React Native на iOS

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

Кстати, сам фэйсбук тоже рендерится через Hermes.

Рома Дворнов, автор csstree, завёл канальчик. Сечас пишет о разработке поточного джейсон парсера.

Вчера наконец сделал первую имплементацию поточного парсера JSON. Месяцы обдумывания что нужно сделать, и пара часов на начальную версию плюс часа три на оптимизацию и полировку. Текущие цифры не так сильно удручают как первичные, но пока далеко до нативного JSON.parse()
(тут parse: начальная версия -> текущая)

Webpack stats (~500mb с форматированием)
parse: 13.047s -> 4.946s
JSON.parse(): 1.258s

fixture 100mb
parse: 5.661s -> 1.424s
JSON.parse(): 559.153ms

fixture 13.7mb
parse: 303.423ms -> 140.015ms
JSON.parse(): 39.643ms

fixture 2mb
parse: 204.93ms -> 102.851ms
JSON.parse(): 11.838ms

Это будет частью json-ext, пока живет в ветке. Еще нужно просмотреть свежим взглядом, добавить тестов и обкатать на живых проектах.

Docker Compose на Apple Silicon

Пояилось ишью в котором, ведётся работа по запуску Docker Compose. Есть проблемы с питон-зависимостями, но их скоро решат. Ну и он отлично запускается через розетту.

Рейт-лимиты Docker Hub

Не так давно докер выкатили ограничение на пул образов с Docker Hub. А гитлаб, в свою очередь, выкатили кеширующую проксю и написали статью про мониторинг лимитов.

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

Вокруг React

Я очень редко слушаю подкасты, но мимо UnderJS с Дэном Абрамовым пройти не смог. Час с небольшим Дэн рассказывает про будущее реакта.

Больше всего меня заинтересовал топик «Suspense в SSR». И, к сожалению, я не услышал того, что хотел услышать. На сколько я понял, планов сделать так, чтобы саспенс работал на сервере и можно было дождаться чего-то асинхронного прям в компоненте у ребят нет. Вместо этого они хотят сделать стриминг и рендерить фолбек, а как только данные будут получены, продолжать рендер и подменять фолбек на настоящий контент.

Получается, что у нас набор каких-то костылей:
* getServerSideProps в next.js;
* renderToStringWithData в Apollo, который делает рекурсивный рендер;
* самописные решения с двойным (и более) рендером для сбора промисов;
* react-ssr-prepass, который страшно (ну, лично мне) тащить в продакшн.

Webpack 5 в Storybook

Почти год назад появилось ишью про обновление вебпака (он тогда ещё в бете был) и было 3 пул-рерквеста, которые делали апргейд примерно одинаково плохо и неполнеценно. И вот за дело взялся один из мэйнтейнеров.

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

Простите, я глупенький.

Если что, таким нехитрым образом я пытаюсь понять, имеет ли смысл писать о каких-то нововведениях и проблемах в инструментах из опросов выше 🙂

Пятничное: ребята из ClickHouse загрузили в базу кучу статистики про GitHub и сделали кучу готовых запросов, очень много рассказывающих про культуру и опенсорс вцелом. Если вас интересует эта тема - обязательно посмотрите, много неожиданных открытий. Например теперь понятно, какая компания делает самый популярный опенсорс. Или какой контент на гитхабе самый популярный вообще https://gh.clickhouse.tech/explorer/

Docker dev preview для Apple Silicon

Ребята из докера исправились и компенсировали невнятный роадмап рабочим дев билдом Получить его можно через developer preview program (вас добавят в слак-канал, в котором можно будет скачать докер и оставить отзыв о работе). Сейчас там пример 400 человек.

В нём работают основные компоненты, но пока что есть проблемы с DNS, кубернетисом и ещё по мелочи.

На следующей неделе обещают сделать более публичный анонс (возможно открытая бета-версия).

Apple Silicon и фронтенд-тулинг

Мэнтэйнер Gatsby запустил бенчмарк производительности большинства инструментов, которые мы используем в ежедневной работе. Сравнивается мак мини на M1 и макбук про 2019 года на i9, и мини быстрее в 1.5 раза.

В качестве бенчмарка используется v8/web-tooling-benchmark. Его можно запустить на своей машине и сравнить

Проблема с фолбеком кеша в Gitlab CI

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

P.S. Кажется первое ишью на гитлабе, а не на гитхабе, в канале 🙂

Как Docker работает с разными архитектурами?

И что происходит, когда на разных архитектурах мы пулим один и тот же образ? Скажем, node:15.4.0-alpine3.12?

Если открыть ссылку, то можно увидеть информацию об образе. Но что более важно, можно увидеть переключатель OS/ARCH. На самом деле под каждую архитектуру собирается и публикуется отдельный образ, а затем эти они объединяются общим тегом. Саму структуру манифеста можно посмотреть через docker manifest inspect --verbose node:15.4.0-alpine3.12. Чтобы упростить работу с такими образами, докер будут использовать buildx. Подробней можно почитать вот здесь.

Докер сам выберет подходящий образ под текущую архитектуру, но на собственных процессорах эпл так же будет поддержка и amd64 через QEMU, но, само-собой, работать в разы медленнее, т.к. это эмуляция. На текущий момент, если нет образа под arm64, то докер просто падает и говорит, что не нашёл подходящий образ. Это решается через явное указание платформы --platform linux/amd64. Пока что непонятно как они будут решать этот момент, т.к. указывать явно не очень удобно.

Что ещё более непонятно, так это насколько безопасно (с точки зрения стабильности) разрабатывать на одной архитектуре, а в проде использовать другую? ARM инстансы, хоть и существуют (у amazon есть тип A1, который стоит дешевле EC2 и при этом эффективней), но пока что не пользуются популярностью. Во многом это обусловленно как раз таки архитектурой, которую мы используем для локальной разработки, так что здесь сложно определить где курица, а где яйцо.

Оказывается, в DTK (дев-кит эпл) не было поддержки виртуализации и именно по этой причине так поздно началась работа над Докером и Parallels для ARM

Jest неверно определяет количество процессоров в CI

Какое-то время мы испытывали странную проблему с джестом — он падал со словами out of memory, но при этом максимальные размер хипа (heap) ноды (2гб по умолчанию) не был достигнут, общий лимит джобы тоже.

Поиски привели меня в ишью Jest without --runInBand slow under Travis. Казалось бы, причём тут тревис? У джеста есть опция --maxWorkers, которая позволяет указать количество воркеров для прогона тестов. Чем больше воркеров, тем больше параллельных процессов, и тем быстрее тесты выполняются. Локально всё работает здорово, т.к. джест использует стандартное API require('os’).cpus().length. Проблемы начинаются в CI: например, Circle CI говорит, что доступно 32 процессора. Происходит это из-за того, что есть физическое кол-во процессоров, но каждой отдельной джобе доступна лишь какая-то часть.

В нашем случае проблема крылась в кубернетисе и его лимитах — nproc и нода говорили, что доступно 6 процов, но на деле настоящий лимит в 4 проца был указан через cgroup. Я написал небольшой баш-скрипт, который позволяет в таких случаях определить доступное кол-во. Там же ссылки на то, как работает менеджмент ресурсов в кубернетисе и ему подобным.

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

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

P.S. Мэйнтэйнер джеста написал скрипт available-cpu и результаты, прямо скажем, забавные.