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

We Replaced Our React Frontend with Go and WebAssembly

Чуваки из Dagger переписали React на Go. Внимание, не повторять в домашних условиях. Команда Dagger столкнулась со сложностью - у них был интерфейс в вебе и интерфейс в терминале и необходимо было все UI-фичи дублировать в двух разных кодовых базах (собственно React и Go). Решение простое: переписать один из двух UI на ~~typescript~~ Go.

Выбор достаточно храбный, но обоснованный. Команда имеет широкую экспертизу в Go и слабую в web-e, поэтому принято решение попробовать переехать полностью на Go. Статья рассказывает о проблемах, с которыми столкнулась команда и что из этого вышло.

Ребята взяли Go-App - это тулинг для написания PWA-приложиков на go, с применением WASM.

Какие нюансы вскрылись при написании Go приложения для веба:
- Нужно было очень аккуратно оптимизировать потребление памяти. В проекте есть кейсы, когда требуется отрисовывать более 200 тысяч строчек логов, что может привести к развалу приложения.
- Go WASM оказался неповоротливым в обработке огромных объемов JSON, из-за чего пришлось менять архитектуру решения.
- WASM файл получился большим - 32 МБ. Даже после сжатия brotli он остается 4.6 МБ
- Думали, что будет сложно писать UI-компоненты, но оказалось что это не так
- Научились использовать npm библиотеки из Go-кода
- По сравнению с React, прямая работа с UI позволяет лучше оптимизировать код. Можно сделать много разных решений, замерить и выбрать лучшее.
- Дебаг средствами Go - удобен
- За бесплатно получили PWA приложение (в целом, могли и раньше воткнуть конечно)

Следует ли вам проделывать такое? Скорее всего нет. У Dagger специфичный юзкейс:
- Делают непростой UI. Далеко не каждому продукту нужно выводить сотни тысяч элементов на странице
- Команда из сильных go-разработчиков
- Требование синхронизации двух интерфейсов

Я же отмечу, что Go-разработчики не перестают меня удивлять путями, которые они выбирают. Кейс же очень интересный.

https://dagger.io/blog/replaced-react-with-go

#development #javascript #golang #wasm

Дайджест за 2025-02-24 - 2025-02-28

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

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

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

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

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

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

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

We Replaced Our React Frontend with Go and WebAssembly
Чуваки из Dagger переписали React на Go. Внимание, не повторять в домашних условиях. Команда Dagger столкнулась со сложностью - у них был интерфейс в вебе и интерфейс в терминале и необходимо было все UI-фичи дублировать в двух разных кодовых базах (собственно React и Go). Решение простое: переписать один из двух UI на typescript Go.

Выбор достаточно храбный, но обоснованный. Команда имеет широкую экспертизу в Go и слабую в web-e, поэтому принято решение попробовать переехать полностью на Go. Статья рассказывает о проблемах, с которыми столкнулась команда и что из этого вышло.

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

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

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era

Ссылка от подписчика про разрабатываемый им продукт - RushDB. RushDB - это база данных, которую легко развернуть и начать использовать. Основная фишка - это то что БД забирает на себя организацию данных - нормализацию, лейблинг, организацию связей между сущностями. И это очень подходит для AI-решений - вы закидываете данные, БД сама все структурирует, а структуру и связи уже может использовать AI

Также все сделано для того, чтобы работа с БД была простой: есть SDK на typescript и python, можно селф-хостить, можно хостить в клауде, есть гарантии транзакций, возможность работать ничего не настраивая.

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

https://rushdb.com/blog/rushdb-the-zero-config-database-for-modern-apps-and-ai-solutions

#development #javascript #database #ai

The TypeScript Agent Framework

Mastra - фреймворк на Typescript для создания ИИ-агентов. Выглядит достаточно хорошо - поддерживает много разного: кастомные тулы, воркфлоу (и контроль их исполнения), RAG, память.

Тут еще не было постов про ИИ-агентов, поэтому небольшая вводная. LLM сами по себе могут лишь предсказывать, какой текст должен следовать за предыдущим. Это достаточно прикольный инструмент, но чтобы что-то сделать нужно а) дать им какие-то данные; б) вести с ними диалог в каком-то фреймворке (дать данные, попросить проанализировать, дать дополнительные данные, снова что-то попросить). ИИ-агенты как раз позволяют закрыть полный флоу работы с LLM - добавляются инструменты (tools), которые позволяют достать какие-то данные, и добавляются воркфлоу или сценарии, которые ведут LLM.

Например, вы хотите сделать код ревью своего МР-а. Как это делается с LLM - создается чат, дается контекст, кидается много файлов и на каждый просится фидбек. Как это делается с ИИ-агентом - вы строите агента, который умеет ходить в апи gitlab или github (и другие апи) для получения данных, в агенте настраиваете воркфлоу как делаются код-ревью. А дальше заходите в чат с ИИ-агентом и говорите "сделай код ревью моего последнего МР-а", а дальше ИИ-агент сам пройдется по всем инструментам и сценариям и сделает для вас код ревью

Возвращаемся к статье. Mastra - фреймворк для описания ИИ-агентов. Я прямо сейчас играюсь с LangChain.js для создания агента, но, видимо, попробую теперь и Mastra.

https://mastra.ai

#development #javascript #ai #aiAgents

Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite

Вышел Deno 2.2. Заехали прикольные фичи: поддержка из коробки sqlite и OpenTelemtry, улучшения линтера, поддержка QUIC (http3), улучшение совместимости с Nodejs API, а также различные работы по перформансу.

Я бы хотел отдельно выделить поддержку Open Telemetry в Deno. Open Telemetry - это крайне важна штука, для обеспечения observability ваших систем. Open Telemetry - это набор соглашений о том, как следует логировать операции в IT-системах. Обычно OT встраивается в фреймворки, либо вы сами подключаете ОТ и инструментируете свой код. Deno же сам инструментирует основные методы (console.log, fetch, Deno.serve), а все что надо инструментировать сверх - остается на вас.

Также в Deno встроен Open Telemetry Exporter - вам достаточно запустить Deno с режимом OT и указать ендпоинт экспорта OT вашего Deno-приложения и телеметрия польется в вашу целевую систему, где вы можете отслеживать все действия юзера.



https://deno.com/blog/v2.2

#development #javascript #deno #releaseNotes

Bundling Dependencies

Статья разбирает, стоит или не стоит бандлить зависимости в свои библиотеки.

Сначала статья разбирает, зачем вообще может понадобится бандлить зависимости, а затем разбирает, какие есть плюсы и минусы у пребандлинга и приводятся примеры библиотек, которые пребандлятся

Зачем может понадобится бандлить зависимости:
- Если у вас зависимости в CommonJS, а делаете решение для браузеров. В этом случае вам проще забандлить эту зависимость
- Вы зависите от очень большого пакета, но используете лишь малую часть. В этом случае можно забандлить малую часть, чтобы не заставлять всех юзеров тянуть огромную зависимость
- Внутренние зависимости. Например, у вас моно-репо и куча мелких пакетов-утилок. Проще их забандлить, чем заставлять юзеров тянуть десятки внутренних мини-пакетов
- Если есть цель быть dependency free или zero dependency

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

Минусы пребандлинга:
- Пользователи не получат обновлений ваших зависимостей (например, обновлений безопасности)
- Зависимости все еще существуют, но теперь они никому не видны
- Нет возможности использовать преимущества пакетных менеджеров (дедупликация)
- Если находится проблема в вашем продукте, которая относится к зависимости, то проблему отрепортят вам, а не напрямую в зависимость (т.к. никто не в курсе про зависимость, кроме вас)

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

https://e18e.dev/blog/bundling-dependencies.html

#development #javascript #bundle

ESLint now officially supports linting of CSS

Eslint продолжает развиваться. Теперь он умеет линтить CSS, используя парсер CSSTree. Сделали хорошее базовое решение: пока есть малое количество встроенных правил, но при этом есть удобное АПИ для создания кастомных правил + есть АПИ для расширения синтаксиса CSS (например, есть готовый пресет для расширения синтаксиса для tailwind)

import css from "@eslint/css";

export default [
    {
        files: ["**/*.css"],
        plugins: {
            css,
        },
        language: "css/css",
        rules: {
            "css/no-empty-blocks": "error",
        },
    },
];

https://eslint.org/blog/2025/02/eslint-css-support/

#development #javascript #eslint #css

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

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era
Ссылка от подписчика про разрабатываемый им продукт - RushDB. RushDB - это база данных, которая легко развернуть и начать использовать. Основная фишка - это то что БД забирает на себя организацию данных - нормализацию, лейблинг, организацию связей между сущностями. И это очень подходит для AI-решений - вы закидываете данные, БД сама все структурирует, а структуру и связи уже может использовать AI

Также все сделано для того, чтобы работа с БД была простой: есть SDK на typescript и pythin, можно селф-хостить, можно хостить в клауде, есть гарантии транзакций, возможность работать ничего не настраивая.

The TypeScript Agent Framework
Mastra - фреймворк на Typescript для создания ИИ-агентов. Выглядит достаточно хорошо - поддерживает много разного: кастомные тулы, воркфлоу (и контроль их исполнения), RAG, память.

Тут еще не было постов про ИИ-агентов, поэтому небольшая вводная. LLM сами по себе могут лишь предсказывать, какой текст должен следовать за предыдущим. Это достаточно прикольный инструмент, но чтобы что-то сделать нужно а) дать им какие-то данные; б) вести с ними диалог в каком-то фреймворке (дать данные, попросить проанализировать, дать дополнительные данные, снова что-то попросить). ИИ-агенты как раз позволяют закрыть полный флоу работы с LLM - добавляются инструменты (tools), которые позволяют достать какие-то данные, и добавляются воркфлоу или сценарии, которые ведут LLM.

Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite
Вышел Deno 2.2. Заехали прикольные фичи: поддержка из коробки sqlite и OpenTelemtry, улучшения линтера, поддержка QUIC (http3), улучшение совместимости с Nodejs API, а также различные работы по перформансу.

Я бы хотел отдельно выделить поддержку Open Telemetry в Deno. Open Telemetry - это крайне важна штука, для обеспечения observability ваших систем. Open Telemetry - это набор соглашений о том, как следует логировать операции в IT-системах. Обычно OT встраивается в фреймворки, либо вы сами подключаете ОТ и инструментируете свой код. Deno же сам инструментирует основные методы (console.log, fetch, Deno.serve), а все что надо инструментировать сверх - остается на вас.

Bundling Dependencies
Статья разбирает, стоит или не стоит бандлить зависимости в свои библиотеки.

Сначала статья разбирает, зачем вообще может понадобится бандлить зависимости, а затем разбирает, какие есть плюсы и минусы у пребандлинга и приводятся примеры библиотек, которые пребандлятся

ESLint now officially supports linting of CSS
Eslint продолжает развиваться. Теперь он умеет линтить CSS, используя парсер CSSTree. Сделали хорошее базовое решение: пока есть малое количество встроенных правил, но при этом есть удобное АПИ для создания кастомных правил + есть АПИ для расширения синтаксиса CSS (например, есть готовый пресет для расширения синтаксиса для tailwind)



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

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

Если вы вдруг хотите выступить на FrontendConf, но не уверены в своих скиллах или теме - зайдите 13го марта на стрим от FrontendConf, где программный комитет расскажет об интересных темах. От себя отмечу, что много раз уже выступал на FrontendConf и программный комитет всегда хорошо помогал как с выбором направления и темы для доклада, так и с подготовкой самого доклада. Поэтому не стесняйтесь заходить

Встреча потенциальных докладчиков с программным комитетом FrontendConf 2025

13 марта в 19:00 пройдет встреча с потенциальными докладчиками, на которой мы обсудим:
- на какие темы мы хотим говорить на конференции в этом году,
- как проходят отбор заявок,
- как готовить доклад с Программным комитетом.

Приходите! Я уже восьмой год подряд провожу эту встречу (как же быстро растут чужие дети), расскажу, какой видим программу, и обсудим ваши идеи докладов.

Регистрация: https://conf.ontico.ru/event/join/open_fc2025-online.html

Подробнее про программу и форма подачи докладов: https://cfp.frontendconf.ru

TypeScript: the satisfies operator

Большой пост про satisfies оператор в TypeScript. Объясняется что такое satisfies оператор и какие основные юзкейсы у него есть

satisfies проверяет, что значение соответствует какому-то типу, не меняя тип значения.

Чтобы понять разницу между satisfies и as достаточно взглянуть на 1 пример, где as сделает тайпкаст, а satisfies укажет на ошибку

type Point = { x: number, y: number };
const point5 = { x: 2 } as const as Point; // OK
const point6 = { x: 2 } as const satisfies Point; // ERROR

В статье показываются юзкейсы, когда применение satisfies очень полезно для проверки на соответствие какому-то типу, но при этом тип переменной не меняется

Например, у вас есть конфиг для стилей

type TTextStyle = {
  html: string,
  latex: string,
};

const TextStyle  = {
  Bold: {
    html: 'b',
    latex: 'textbf',
  },
}

Если вы используете начнете описывать тип переменной TextStyle, то вы можете столкнуться с тем, что случайно сделаете тип более широким

type TTextStyle = {
  html: string,
  latex: string,
};

const TextStyle: Record<string, TTextStyle>  = {
  Bold: {
    html: 'b',
    latex: 'textbf',
  },
}
TextStyle.KEK // OK

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

Оператор satisfies тут как нельзя кстати

type TTextStyle = {
  html: string,
  latex: string,
};

const TextStyle  = {
  Bold: {
    html: 'b',
    latex: 'textbf',
  },
} satisfies Record<string, TTextStyle>
TextStyle.KEK // ERROR

В статье есть еще разные примеры использования оператора - рекомендую ознакомиться самостоятельно.

Однако, есть прикольные моменты, которые обозначу в посте. Хотя satisfies обычно не меняет тип проверяемой переменной, есть исключения.

Например, satisfies может уточнить тип

type Robin = {
  name: 'Robin',
};

const robin1 = { name: 'Robin' };
// robin1.name имеет тип string
const robin2 = { name: 'Robin' } satisfies Robin;
// robin2.name имеет тип 'Robin'

https://2ality.com/2025/02/satisfies-operator.html

#development #typescript #satisfies

import-in-the-middle

import-in-the-middle - библиотека для патчинга экспортов ESM-библиотек. Достаточно интересная штука, которая должна использоваться с умом. Для работы библиотеки необходимо регистрировать её как загрузчик в node.js

node --loader=import-in-the-middle/hook.mjs my-app.mjs

Пример

import { Hook } from 'import-in-the-middle'
import { foo } from 'package-i-want-to-modify'

console.log(foo) // whatever that module exported

Hook(['package-i-want-to-modify'], (exported, name, baseDir) => {
  // `exported` is effectively `import * as exported from ${url}`
  exported.foo += 1
})

console.log(foo) // 1 more than whatever that module exported

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

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

https://github.com/nodejs/import-in-the-middle

#development #javascript #library #esmodules