Валя читает ишью

2021-05-07 17:43:54 Автоматическое обновление Docker

Пожалуй, пост, достойный пятницы. Начиная с 3 версии, докер автоматически устанавливал апдейты. Само собой, такое поведение не очень удобно, особенно когда в новой версии что-то ломается (а оно ломается). Этому было посвещено ишью Please don't upgrade docker without asking first. Месяц назад вышла версия 3.3 в которой это почнили, но сделали крайне забавно.

1. Автоматические апдейты действительно выключили.
2. Когда выходит апдейт, иконка в трее меняется, мол, обнови меня.
3. После 2 недель каждый день появлется попап, который можно закрыть либо обновиться. А ещё можно запретить показывать попап, но доступно это только Pro и Team пользователям. Но самое смешное, это то, что владельцы Team подписки могут отключить такие уведомлениям всем сотрудникам. Видимо, это связано с тем, что нередко бывают проблемы формата «ну я обновил докер, всё сломалось и теперь я не могу работать работу».

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

Подробней про механизм и мотивациюю можно почтитать в релизном блог-посте и в ишью. Открыть/Комментировать

2021-05-07 16:29:20 На Гитхабе появился простой способ обновить форк из апстрима одним нажатием на кнопку. До сих пор погружать изменения из основного репозитория приходилось вручную, в клоне форка — теперь это можно сделать прямо в интерфейсе.

https://twitter.com/github/status/1390382527588798477 Открыть/Комментировать

2021-05-06 02:12:06 RemoteHub

В посте о том, как сделать гитхаб более удобным я упоминал github1s (он, кстати, научился в поиск по проекту). В VS Code Insiders появился RemoteHub. В общем-то идея точно такая же: за пару секунд открыть любой репозиторий с гитхаба, но уже используя нативный VS Code. Открыть/Комментировать

2021-05-06 02:07:06 Табы в терминале в VS Code доехали в версии 1.56, но остались спрятаны под экспериментальным флагом. Чтобы их включить, добавьте в конфиге “terminal.integrated.tabs.enabled": true.

Подробней про табы можно почитать в релизном блог-посте. Открыть/Комментировать

2021-05-06 01:48:33 В комментариях сказали, что сафари неконкурентноспособен, но это конечно же не так. Мне сафари не нравится, но это единственный браузер, который покрывает 100% фич из ES2015. Правда по части более новых стандартов он отстаёт: 91% против 100% в хроме и фаерфоксе.

Но вот почему нельзя отвязать обновление браузера от обновлений операционной системы для меня загадка. Открыть/Комментировать

2021-05-05 14:33:24 В Safari 14.1 сломан localStorage

Вчера Jake Archibald обнаружил, что localStorage сломан в последнем релизе Safari таким образом, что каждая вкладка читает свой собственный экземпляр хранилища, а не делит общий с другими вкладкми origin'а. И хотя при записи в localStorage вкладки получают событие change, они не могут получить новое значение, так как читают из своего собственного экземпляра хранилища.
Эта механика используется как для синхронизации между вкладками, так использовалась и для коммуникации между вкладаками, пока не появился BroadcastChannel. Сегодня BroadcastChannel важен для PWA, так как используется для коммуникации между Service Worker'ом и закладками. Интерфейс появился в Chromium и Firefox 5 лет назад, в Edge с переходом на Chromium. В Safari же тикет на имплементацию висит без движения уже почти 5 лет. Поэтому для Safari используют полифилы, которые использует синхронизацию через localStorage, которая сейчас сломана.
Баг связан с самим Safari, а не его движком (WebKit) и затрагивает только macOS – Safari на iOS не затронут. Инженеры Apple уже пофиксили проблему, но когда выкатится патч не известно, так как они не могут это комментировать, хотя понимают, что это существенная регрессия... Вероятно патч выйдет со следующим релизом macOS.
Пока обходное решение использовать IndexedDB в связке с Service Worker'ом. Открыть/Комментировать

2021-05-05 00:46:34 Rome Tools, Inc.

Себастьян Маккензи анонсировал Rome Tools — компанию, которая будет развивать Rome и платные сервисы в довесок к нему. Управлять компанией он будет вместе с Джейми Кайлом, который ради этого ушёл из Discord. Вместе они успели поработать над Yarn, Babel и Lerna.

Парни получили 4.5 миллионов долларов инвестиций. При этом они делаю акцент на том, что это будет «open source first» компания. Под этим подразумевается, что основная цель — разработка Rome, а всё остальное уже дополнительные активности.

Возможно, одним из первых сервисов будет «Code quality tracking». В нём они хотят объединить трекинг покрытия кода тестами, бюджетирование размера бандла, документацию, фича-флаги, сбор ошибок, менеджмент пакетов и другое. В общем-то идея такая же как и в самом Rome (объединить всё, чем мы пользуемся по отдельности воедино) только про сервисы. Подробней об этих планах можно глянуть в презентации.

Мне стало интересно что же случилось с краудфандингом. Себастьян хотел собрать $100 000 в декабре 2020 года, но сейчас форма не работает. Но в презентации указано, что удалось собрать только $40 000, хотя и это достаточно много для опен-сорс проекта.

Лично я не испытываю симпатии ни к Себастьяну, ни к Джейми, т.к. оба достаточно быстро покидали проекты, над которыми работали, а после частенько устраивали токсичные набросы в твиттере в духе «yarn is dead, long live npm» или изменение лицензии в lerna. Однако идея победить знаменитый Javascript Fatigue действительно очень крутая и очень-очень сложная.

А если вы впервые слышите про Rome, то идея в том, чтобы объединить форматтер, линтинг, тесты, бандлер, тайп-чек и всё-всё-всё, что лежит рядом. В обще что-то в духе тулинга Rust. Открыть/Комментировать

2021-04-29 02:56:53 Судьба Corepack: голосование

Я уже несколько раз писал про Сorepack — менеджер для пакетных менеджеров в node.js. Кажется, это одна из самых драматичных историй вокруг ноды. И история получила продолжение!

Комитет не стал делать опрос пользователей (видимо, ни у кого не было сил и желания), а просто провёл закрытое голосование внутри комитета.

Было доступно 3 варианта:
— оставить всё как есть (просто поставлять npm)
— добавить yarn v1
— добавить Сorepack

«Добавить Сorepack» набрал 63.2% голосов и, пожалуй, это лучший вариант для экосистемы, т.к. он сразу же привносит возможность установки yarn и pnpm. Здесь может возникнуть пространство для дискуссий в духе «а какие пакетные менеджеры должен поддерживать корпак», но это уже совсем другая история.

Вот пул-реквест с интеграцией в node.js, а здесь можно взглянуть на сам Corepack и его документацию. Учтите, что API может поменяться, т.к. это пока что эксперимент.

P.S. Искренне рад за Маэля, ему удалось пошатнуть статус-кво npm. Надеюсь, что никаких подводных камней не возникнет и в следующий раз вернусь к теме со словами «замерджили!». Открыть/Комментировать

2021-04-27 13:08:15 Вчера опубликовали докер-образы node@16.0.0, теперь можно и обновляться.

Кстати, я не являюсь сторонником того, что нужно использовать только LTS версии ноды. Но если ступили на эту дорожку, то не забывайте про строгий engines в package.json и .nvmrc для nvm и подобных, чтобы все разработчики во всех окружениях использовали одну и ту же версию. Открыть/Комментировать

2021-04-26 02:52:55 Работа с веб-воркерами в Webpack 5, как быть со scope при регистрации сервис-воркера?

В пятом вебпаке появилась нативная поддержка веб-воркеров. Раньше для работы с ними нужно было использовать сторонние плагины (например workbox-webpack-plugin), а теперь ничего допонительно устанавливать не нужно. На примеры работы с воркерами можно взглянуть в примерах использования в репозитории вебпака.

Но при работе с сервис-воркерами возникает один важный нюанс.

Сервис-воркер по умолчанию может перехватывать запросы совпадающие с путем до файла с воркером. Т.е. сервис-воркер расположенный в domain.com/static/service-worker.js сможет работать с запросами domain.com/static/**, а вот domain.com/some-path перехватить уже не выйдет. При регистрации сервис-воркеру можно передать опцию scope, однако таким способом можно только сузить допустимые URL, а расширить не выйдет — будет ошибка при регистрации. Это важно, т.к. часто ассеты как раз таки раздают из какой-нибудь отдельной директории, например static, т.к. таким образом проще управлять кешом и другими заголовками.

У этой проблемы есть два решения.

1. HTTP заголовок service-worker-allowed
С помощью этого заголовка можно расширить скоуп. Это более чем валидный способ, но для этого надо лезть в настройки сервера, который отвечает за ассеты на проде (условный nginx) и добавлять заголовки для дев-сервера. А в идеале применять этот заголовок только к ассету с сервис-воркером, что ведет к усложению конфигурации.

2. «Магический» комментарий webpackEntryOptions
Magic comments, кажется, появились ещё во втором вебпаке. Они нужны, чтобы конфигурировать асинхронные импорты. Например, через них можно задать название для чанка. С воркерами эти комментарии тоже работают, но нас интересует другой комментарий — webpackEntryOptions (он, кстати, не задокументирован). Через этот комментарий можно указать любые опции, доступные для энтри-поинта (это advanced API, мало кто знает, что в качестве точки входа можно передать объект). Таким образом для всех ассетов в конфиге можно указать output.filename: “static/[name].js”, а при регистрации воркера добавить комментарий /* webpackEntryOptions: { filename: "[name].js" } */. И тогда не придётся проставлять никакие заголовки и проблема со скоупом отпадёт сама собой.

А начиная с 5.33 версии для энтри-поинта так же можно указывать и кастомный publicPath. Открыть/Комментировать