🎉 Результаты розыгрыша:

Победитель:
1. Маша 🌿 (@m_hodeneva)

Проверить результаты

Refactoring with Codemods to Automate API Changes: часть 3 - Codemods в других языках

Предыдущие части (обзор в канале 1 и 2) показывали примеры на JS. Однако такие инструменты есть и на других языках.

Эта часть статьи фокусируется на обзоре других инструментов.

Например JavaParser для Java работает на основе по паттерна Visitor и там доступны все те же техники, что и для jscodeshift

Также есть инструменты типа OpenRewrite, которые работают не просто с AST, а с LST - Lossless Semantic Trees. Это деревья, в которых отображается не только синтаксис, но и семантика. К сожалению, конкретных примеров использования LST в статье нет.

Hypermod - AI инструмент для генерации кодмода на основе текстового запроса.

Codemod.com - платформа сообщества и продукт. На платформе можно делиться своими кодмодами и брать чужие. Но также предлагается CLI и IDE, которые позволяют удобно работать с кодмодами и генерировать их с помощью AI.

https://martinfowler.com/articles/codemods-api-refactoring.html#CodemodsInOtherLanguages

#development #martinFowler #codemod #hypermod #refactoring

Hypermod

Hypermod - инструментарий для кодмодов. Пока еще в бете. Я его упоминал в предыдущем посте и мне он показался интересным

Что представляет собой этот инструментарий:
- Удобный плейграунд для разработки и дебага кодмодов
- Предоставляется экспирименс разработки Codemod'а как разработки проекта: каждый CodeMod - отдельный проект, к которому можно писать доку, писать тесты, проверять его в плейграунде, делиться с коллегами или сообществом.
- AI для работы с кодмодами. Прикольно что ребята сделали кастомный GPT в openai чате с ChatGPT.

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

https://www.hypermod.io

#development #javascript #typescript #codemod #refactoring

Дайджест за 2025-02-03 - 2025-02-06

Bun 1.2
Вышел огромный апдейт Bun 1.2. Release Notes просто огромные. Если совсем коротко, то продолжается работа по совместимости с Node.js, добавлены встроенные клиенты для s3 и Postgres, добавлен lock-файл. Также expressjs, запущенный в Bun, теперь в 3 раза быстрее, чем запущенный Node.js.

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

Type Predicate Generator
Подписчик канала принес ссылку на свое творение - генератор предикатов для типов. В чем суть: в typescript есть возможность писать рантайм функции, которые уточняют тип. Но писать их руками не всегда прикольно.

Например, функция, уточняющая тип до boolean - function foo(v: unknown): v is boolean { return typeof v === 'boolean' }. Выглядит просто, однако, для составных объектов уже так не получится

Refactoring with Codemods to Automate API Changes: часть 3 - Codemods в других языках
Предыдущие части (обзор в канале 1 и 2) показывали примеры на JS. Однако такие инструменты есть и на других языках.

Эта часть статьи фокусируется на обзоре других инструментов.

Hypermod
Hypermod - инструментарий для кодмодов. Пока еще в бете. Я его упоминал в предыдущем посте и мне он показался интересным

Что представляет собой этот инструментарий:

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Docxtemplater

Docxtemplater - библиотека на JS, которая позволяет генерировать docx, pptx, xlsx документы на основе шаблонов.

Выглядит интересно, особенно если вам достаточно на коленке генерировать документы по шаблону. Из минусов: базовая версия библиотеки бесплатная, а вот все дополнительные плюшки (например, вставка HTML) - платная.

https://docxtemplater.com

#development #javascript #docx #library

The modern way to write JavaScript servers

Достаточно интересная статья, которая показывает возможности для упрощения в кодовой базе и в DX при прямом использовании Request и Response вместо node:http

node:http - механизм для поднятия веб-сервера на ноде и он достаточно хорошо работает. Многие фреймворки очень сильно завязаны на node:http не только на уровне, где должна быть связь с сетью, но и внутри бизнес-логики. Вместо этого автор предлагает использовать стандартизированные в Web Request и Response

Вы очень часто работаете с Request и Response, ведь это те самые объекты, с которыми работает fetch. Поэтому вместо завязок на фреймворки или node:http, можно было бы завязываться на эти самые объекты и описывать свои обработчики запросов примерно так

type MyApp = (req: Request) => Promise<Response>;

Плюсы от такого описания:
- Это кросс-платформенная запись для всех JS-рантаймов, поддерживающих веб-стандарты
- Работать с такими хендлерами удобнее. Например, их легче и быстрее тестировать (в 300 раз быстрее)

Есть правда один нюанс: в самой nodejs пока так нельзя. Но можно рассчитывать на скорую поддержку.

Подчеркну, что статья интересна не тем, что её легко применить для разработки веб-серверов в nodejs, а в следующих двух поинтах:
- Отделение обработчиков запросов от работы с реальным сетевым стеком ускоряет тестирование (в 289 раз по бенчу автора)
- Лучше завязываться на веб-стандарт, а не на веб-платформу т.к. в этом случае вы можете менять рантайм в зависимости от контекста

https://marvinh.dev/blog/modern-way-to-write-javascript-servers/

#development #javascript #node

Standard Schema - A common interface for TypeScript validation libraries

Внезапно (для меня по крайней мере), но авторы популярных пакетов для валидаций собрались и стандартизировали схемы для валидации данных в TS. На сайте описывается состав спеки и библиотеки и фреймворки, которые уже её поддерживают.

Стандартизация руками сообщества - это большое благо. Теперь можно спокойно переиспользовать схемы между проектами и быть уверенными в их совместимости.

https://standardschema.dev

#development #javascript #typescript #schema

Миграция на строгий TypeScript: наш путь и собственное решение

Статья от Selectel про миграцию на строгий TS. Проблема, рассматриваемая в статье, стара как строгий режим TS: проект писался изначально не на TS, решено было его перевозить на TS на нестрогий режим т.к. ни у кого нет столько времени, чтобы переписать весь проект на строгие типы

В идеале хотелось бы, чтобы часть файлов (новый код и тот код, который уже был написан в строгом режиме) всегда проверялись в строгом режиме, а старый код проверялись в нестрогом режиме. В IDE это решается просто - TS поддерживает иерархию tsconfig в проекте, что позволяет вручную размечать, какой файл как следует проверять. Однако для CI такого простого решения нет

Одно из рассматриваемых решений - подключить плагин для TS. В сообществе есть 2 таких решения и оба в selectel не понравились: нужны кастомные настройки tsconfig и встраивание в сборку

Поэтому команда Selectel решила написать ~~свой велосипед~~ свое решение этой проблемы. Так на свет появилась библиотека @selectel/ts-check. Она умеет запускаться из кли и, если я правильно понял, повторяет логику того, как работает проверка в IDE. Также ребята сразу сделали поддержку code quality report в gitlab, поэтому ошибки @selectel/ts-check отображаются сразу в МР.

В статье все описано чуть подробнее, в том числе раскрывается немного деталей работы с TS Language Server.

https://habr.com/ru/companies/selectel/articles/879980/

#development #javascript #typescript #strictMode #habr

Обзор на книгу "Рискуя собственной шкурой" от Насима Талеба

Насим Талеб - человек, давший миру очень популярные книги "Черный лебедь" и "Антихрупкость". Я их не читал, но мне рекомендовали прочесть "Рискуя собственной шкруой", что я и проделал на новогодних каникулах.

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

Есть несколько основных идей в книге
- Для взвешенных решений необходимо "ставить шкуру на кон", т.е. рисковать чем-то. Тот, кто не рискует, не может принимать хороших решений.
- Диктатура меньшинства. Если есть какое-то непримиримое меньшинство (3-4% от общества), которое равномерно распределено по обществу, которое хочет протолкнуть какое-то решение, а большинство готово подстроится - то решение меньшинства будет принято
- Эффект Линди: Чем дольше что-то существует, тем дольше оно будет существовать дальше.

Это общие идеи, которые можно применить к очень многим аспектам жизни общества.

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

Те, кто не "ставит шкуру на кон", не могут принимать взвешенных решений. Если человек что-то предлагает, но при этом он сам ничем не рискует, а рискует кто-то другой, то мы не можем полагаться на то, что человек предлагает хорошее решение. Наверняка вы на работе сталкивались с "экспертами" из других команд или отделов, которые не являются частью вашей команды, но дают вам советы про то, как надо работать. Иногда эти советы по делу, иногда нет. Но есть общая закономерность - люди, дающие советы из других команд и отделов ничем не рискуют, а вот вы, применяя эти советы, рискуете. Поэтому решение о применение совета должно быть у вас, а не у внешних экспертов. Иначе эксперты могут принимать решения, за которые будете расплачиваться вы. Типичный пример в IT - спускаемые "сверху" стандарты процессов или изменения.

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

Диктатура меньшинства в айтишке также хорошо видна. Вы также наверняка сталкивались с ней в прямой работе:
- Всем комфортны командные синки 2 раза в неделю, кроме 1го человека, считающего что синк должен быть каждый день (дейлик). Теперь все собираются каждый день
- Всем комфортно писать любой код, но есть 1 человек, которвый считает, что надо писать код в функциональном стиле. Теперь все пишут код в ФП стиле.

Диктатура меньшинства устанавливается только тогда, когда большинство готово подстроиться. Если среди большинства есть непримеримые к изменениям меньшинства люди, то меньшинство не сможет внедрить это изменение. Скажем, вряд ли у вас в команде получится внедрить правило минимум 4-х апрувов на код ревью - кто-то точно будет против (ну, я надеюсь на это)

Эффект Линди следует следующей логике: если что-то смогло прожить 100 дней, значит оно достаточно живучее, чтобы прожить еще 100 дней. Если что-то прожило 1000 дней, значит оно достаточно живучее, чтобы прожить еще 1000 дней. В общем, можно сказать с большой уверенностью, что React проживет еще 11 лет :)

При этом в книге это все описано прям очень сочно и в примерах. Так сочно, что даже удивляешься, как далеко заходит автор. Внезапно в книге появляются: Путин, НАТО, Трамп, Иисус, саудиты, современная повесточка. Есть и упоминания "психолухов" и ругательства в сторону современных социальных наук. Есть и интересная аббревиатура - ИНИ - Интеллектуал, но идиот, которую очень хочется сразу брать на вооружение т.к. она очень точно передает поведение людей в отдельные моменты времени.

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



#note #book

Дайджест за 2025-02-10 - 2025-02-14

Docxtemplater
Docxtemplater - библиотека на JS, которая позволяет генерировать docx, pptx, xlsx документы на основе шаблонов.

Выглядит интересно, особенно если вам достаточно на коленке генерировать документы по шаблону. Из минусов: базовая версия библиотеки бесплатная, а вот все дополнительные плюшки (например, вставка HTML) - платная.

The modern way to write JavaScript servers
Достаточно интересная статья, которая показывает возможности для упрощения в кодовой базе и в DX при прямом использовании Request и Response вместо node:http

node:http - механизм для поднятия веб-сервера на ноде и он достаточно хорошо работает. Многие фреймворки очень сильно завязаны на node:http не только на уровне, где должна быть связь с сетью, но и внутри бизнес-логики. Вместо этого автор предлагает использовать стандартизированные в Web Request и Response

Standard Schema - A common interface for TypeScript validation libraries
Внезапно (для меня по крайней мере), но авторы популярных пакетов для валидаций собрались и стандартизировали схемы для валидации данных в TS. На сайте описывается состав спеки и библиотеки и фреймворки, которые уже её поддерживают.

Стандартизация руками сообщества - это большое благо. Теперь можно спокойно переиспользовать схемы между проектами и быть уверенными в их совместимости.

Миграция на строгий TypeScript: наш путь и собственное решение
Статья от Selectel про миграцию на строгий TS. Проблема, рассматриваемая в статье, стара как строгий режим TS: проект писался изначально не на TS, решено было его перевозить на TS на нестрогий режим т.к. ни у кого нет столько времени, чтобы переписать весь проект на строгие типы

В идеале хотелось бы, чтобы часть файлов (новый код и тот код, который уже был написан в строгом режиме) всегда проверялись в строгом режиме, а старый код проверялись в нестрогом режиме. В IDE это решается просто - TS поддерживает иерархию tsconfig в проекте, что позволяет вручную размечать, какой файл как следует проверять. Однако для CI такого простого решения нет

Обзор на книгу "Рискуя собственной шкурой" от Насима Талеба
Насим Талеб - человек, давший миру очень популярные книги "Черный лебедь" и "Антихрупкость". Я их не читал, но мне рекомендовали прочесть "Рискуя собственной шкруой", что я и проделал на новогодних каникулах.

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

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Обзор на книгу "Чистый дизайн. Практика эмпирического проектирования ПО" от Кента Бек

Кент Бек - автор XP и TDD, один из создателей Agile Manifesto, снова ворвался в публицистику и выпустил новую короткую книгу. Книга короткая и, по ощущениям, состоит из кучи собранных вместе блог-постов.

Книга в целом о том, как делать "очистку" - это новый термин, проще описать его как "простой рефакторинг". Разница между очисткой и рефакторингом как между прибрать пыль и сделать генеральную уборку. Книга поделена на 3 части: список простых очисток, как проводить очистку, когда проводить очистку

Первая часть супер простая и очень похожа на чистый код: описывается плохой паттерн, его проблемы, и как провести небольшой рефакторинг, улучшающий код. Каждая глава буквально 2-4 страницы.

Вторая часть и третья части уже намного интереснее.

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

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

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

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

Простое (на мой взгляд) определение связности и зацепления из книги:
> Отдельный фрагмент кода понять легче, если он представляет единое целое и имеет единый смысл ... Это связность. Кроме того, понять происходящее в контексте отношений с другими частями кода проще, если эти отношения немногочисленны, относительно слабы или сильно ограничены. Это сцепление. Сцепление и связность ... означают ... то, как ваш мозг воспринимает сложные системы.

Книга очень короткая. Я прочел буквально за 3 вечера. Сам формат мне понравился - вместо того, чтобы читать талмуд на 400+ страниц про все подряд, есть супер короткая книга, которая покрывает небольшую тему, раскрывает её с разных сторон (хотя в этой книге некоторые идеи раскрыты не очень глубоко), и эту тему можно впитать в себя буквально за рабочую неделю.

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



#note #book

Introducing Fusion - write PHP inside Vue and React components

Мы достигли технологической сингулярности: теперь можно писать php внутри vue или react внутри php! Создатель Laravel (фреймворк для php) сделал инструмент, который позволяет в Laravel писать vue и react файлы, внутри которых будет использоваться php.

Это не просто рендер vue-шаблонов с использованием php, это и вызов php-методов из браузерного кода, и синхронизация стейта на вебе и на беке. ИМХО, неплохая тема, особенно веб-для разработчиков на проекте с laravel.

Сниппет кода на странице с примером включает только отображение:

<!-- app.vue -->
<php>
    $user = prop(Auth::user()->email);
</php>
 
<template>
    <div>{{ user }}</div>
</template>

https://laravel-news.com/introducing-fusion

#development #javascript #php #vue

Tutorial: publishing ESM-based npm packages with TypeScript

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

Основной полезный контент - это настройка ESM-модулей, которая делается теперь проще, благодаря поддержке ESM различным тулингом, через объявление поля exports в package.json, вместо описания 4-х разных полей ранее.

Настройка экспорта зависит от ответов на несколько вопросов:
- Собираемся ли мы экспортировать все через под-директории (import someThing from "package-name/sub/index") или из рута (import someThing from "package-name")
- Собираемся ли мы указывать расширение для файлов для экспортов под-директорий?

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

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

// Bare export
".": "./dist/src/main.js",

// Subpaths with extensions
"./util/errors.js": "./dist/src/util/errors.js", // single file
"./util/*": "./dist/src/util/*", // subtree

// Extensionless subpaths
"./util/errors": "./dist/src/util/errors.js", // single file
"./util/*": "./dist/src/util/*.js", // subtree

Также в статье настраивается:
- mocha
- tsc
- typedoc
- publint
- knip
- madge
- и куча других тулов

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

https://2ality.com/2025/02/typescript-esm-packages.html

#development #typescript #npm

Read-only accessibility in TypeScript

Пост, разбирающий все аспекты создания readonly свойств и объектов в TS: от свойств объекта, до readonly Set и Map.

Я знал про readonly (и даже иногда использовал), но я не знал что в TS есть Readonly вариации массива, tuple, Set и Map. В статье показывается как они работают и какие есть особенности их работы.

Для меня самым шоком оказалось, что объект Readonly объект можно кинуть аргументом в функцию, которая принимает не Readonly объект, а значит может его поменять. При этом для массива, Set и других Readonly типов все работает корректно - я не могу кинуть Readonly версию типа в функцию, которая ожидает не-readonly версию.

https://2ality.com/2025/02/typescript-readonly.html

#development #typescript #readonly

Beej's Guide to Git

Огромный гайд по git'у. Кажется в этом гайде покрыто вообще все, при этом все описано достаточно компактно и разобраны основные кейсы работы с git'ом, которые нужные разработчику.

Читать я бы такое не стал, но ссылку бы сохранил, чтобы открывать периодически интересующие темы. Для джунов вообще хорошо. В первый раз столкнулся с тем что надо сделать форк? Сначала прочти в туториале про форки и работу с ремоутами, а потом приступай к работе.

https://beej.us/guide/bggit/html/split/

#development #git #tutorial

Дайджест за 2025-02-17 - 2025-02-21

Обзор на книгу "Чистый дизайн. Практика эмпирического проектирования ПО" от Кента Бек
Кент Бек - автор XP и TDD, один из создателей Agile Manifesto, снова ворвался в публицистику и выпустил новую короткую книгу. Книга короткая и, по ощущениям, состоит из кучи собранных вместе блог-постов.

Книга в целом о том, как делать "очистку" - это новый термин, проще описать его как "простой рефакторинг". Разница между очисткой и рефакторингом как между прибрать пыль и сделать генеральную уборку. Книга поделена на 3 части: список простых очисток, как проводить очистку, когда проводить очистку

Introducing Fusion - write PHP inside Vue and React components
Мы достигли технологической сингулярности: теперь можно писать php внутри vue или react внутри php! Чел из сообщества Laravel (фреймворк для php) сделал инструмент, который позволяет в Laravel писать vue и react файлы, внутри которых будет использоваться php.

Это не просто рендер vue-шаблонов с использованием php, это и вызов php-методов из браузерного кода, и синхронизация стейта на вебе и на беке. ИМХО, неплохая тема, особенно веб-для разработчиков на проекте с laravel.

Tutorial: publishing ESM-based npm packages with TypeScript
Туториал по публикации ESM-пакетов с поддержкой TS, которые работают и в браузере и в ноде. Туториал разбирает все - от структуры файлов и конфигов, до настройки тулов. Есть, конечно, небольшой минус - гайд немного предвзят по некоторым моментам

Основной полезный контент - это настройка ESM-модулей, которая делается теперь проще, благодаря поддержке ESM различным тулингом, через объявление поля exports в package.json, вместо описания 4-х разных полей ранее.

Read-only accessibility in TypeScript
Пост, разбирающий все аспекты создания readonly свойств и объектов в TS: от свойств объекта, до readonly Set и Map.

Я знал про readonly (и даже иногда использовал), но я не знал что в TS есть Readonly вариации массива, tuple, Set и Map. В статье показывается как они работают и какие есть особенности их работы.

Beej's Guide to Git
Огромный гайд по git'у. Кажется в этом гайде покрыто вообще все, при этом все описано достаточно компактно и разобраны основные кейсы работы с git'ом, которые нужные разработчику.

Читать я бы такое не стал, но ссылку бы сохранил, чтобы открывать периодически интересующие темы. Для джунов вообще хорошо. В первый раз столкнулся с тем что надо сделать форк? Сначала прочти в туториале про форки и работу с ремоутами, а потом приступай к работе.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Style-observer: JS to observe CSS property changes, for reals

В вебе относительно давно есть разные Observer'ы, с некоторыми из которых, кажется, столкнулся каждый - Mutation Observer и Intersection Observer. Но чего нам не хватает - это Style Observer. Статья от Lea verou про то, как сообщество решало задачу "реагировать на изменения в стилях" и как Lea Verou и другие неравнодушные люди сделали Style Observer

Первые решения этой задачи появились еще в 2018 году и было реализованы на полинге - JS код периодически запрашивал стили и реагировал на их изменения. Затем были сделаны решения, которые работали на основе селекторов и transitionstart. Затем в какой-то момент появился transition-behavior: allow-discrete, который позволяет делать более общие решения. На его основе и построен style-observer

Рекомендую посмотреть на библиотечку. Вероятно, рано или поздно она окажется вам полезной.

https://lea.verou.me/blog/2025/style-observer/
https://observe.style

#development #css #leaVerou

Move on to ESM-only

Пора перестать делать пакеты с поддержкой CJS и работать только в ESM. Автор статьи 3 года назад писал гайд, как делать пакет с поддержкой ESM & CJS, но теперь считает, что сообщество и тулинг за эти 3 года ушли далеко вперед и от поддержки CJS можно отказываться.

Изначально весь движ к ESM-only пакетам делался снизу-вверх - некоторые библиотеки (типа execa) переехали на ESM-only и, таким образом, заставляли двигаться всю экосистему. Это достаточно крутой мув, но, по мнению автора, он оказался менее эффективен, чем поддержка ESM у тулинга и фреймворков.

Почему стоит переезжать на ESM-only и не стоит оставаться на CJS & ESM?
- Не смотря на то, что Nodejs позволяет импортировать CJS в ESM, экспорты CJS сделаны по-другому, из-за его возникает необходимость делать двойную работу. Автор не погружается глубоко в проблематику, но указывает, например, на необходимость генерировать 2 файла с типами
- Зависимости, которые поставляются как ESM и как CJS в код приложения, могут конфликтовать друг с другом. Также это большая проблема для пакетов-синглотонов
- Размер пакетов, которые поддерживают CJS & ESM, увеличиваются (т.к. им нужно держать 2 версии кода)

Где следует уже использовать ESM-only^
- Новые пакеты
- Пакеты, которые должны работать в браузере
- CLI
- Node.js пакеты, таргетирующиеся на новые версии ноды


https://antfu.me/posts/move-on-to-esm-only

#development #javascript #esmodules

The Popover API is now Baseline Newly available

Popover - это база. Теперь официально. Popover - это стандартизированное API для реализации всплывающих окон в браузере. Вообще Popover реализовали в Firefox еще в апреле 2024 года, но реализация оказалась проблемной для iOS и iPadOS - нельзя было закрыть Popover ~~без уважения~~ кликнув по свободному месту. Поэтому пришлось ждать свежего релиза сафари, чтобы сказать, что Popover - это база

Что это значит для нас: можно считать что Popover прекрасно работает с января 2025. Когда значительная часть пользователей перейдёт на браузеры с версией выше, чем выпущенные в январе 2025 года, можно будет использовать Popover по полной.

https://web.dev/blog/popover-baseline

#development #javascript #popover

How to refactor code with GitHub Copilot

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

Статья делится на несколько частей: что такое рефакоринг => как его начать => как сделать мелкий рефакторинг => как набросать план рефакторинга

Рефакторинг - изменение кода без изменения поведения. По сути, изменение структуры кода. Самые популярные примеры: упрощение условий, вынесение общей логики, декомпозиция функций

Перед тем как начать рефакторинг, нужно убедиться, что мы изменениями не поменяем поведение. Но для этого это поведение необходимо понять. Хорошо, когда код хорошо написан и есть комментарии - в этом случае легко погрузиться в то, как работает код. Но бывает так, что понять поведение очень сложно. Тут то на помощь и может придти Copilot - он проанализирует код и расскажет, что он делает и почему

Дальше можно перейти к простым рефакторингам. В статье предлагается очень наивный подход - просто закинуть промпт "сделай красиво"

- How would you improve this?
- Improve the variable names in this function.
- #file:pageInit.js, #file:socketConnector.js Offer suggestions to simplify this code.

Но как стартовая точка - сойдет. Вместе с Copilot можно идти в более сложные рефакторинги, когда вы накидываете контекст, а Copilot предагает решения.

Все кто использовали Copilot и ChatGPT уже, скорее всего, пробовали подход "сделай красиво". Однако команда Copilot рекомендует идти дальше и составлять план рефакторинга вместе с Copilot. Эта фича есть в Copilot Workspace и она выглядит достаточно неплохо. В чем суть: вместо того, чтобы просить Copilot сделать код красивее, можно скормить ему контекст (что делаем, зачем, какие цели, какие файлы) и попросить составить план рефакторинга. Этот план можно затем полировать вместе с Copilot, а затем уже проводить рефакторинг по плану. В целом, похоже на обычный здоровый процесс рефакторинга - перед тем как делать что-то сложное, лучше обсудить с коллегой план.

Также в статье приводится реальный кейс рефакторинга вместе с Copilot из команды Github

https://github.blog/ai-and-ml/github-copilot/how-to-refactor-code-with-github-copilot/

#development #javascript #ai #copilot #refactor #github