peerDependencies
При разработке библиотеки очень важно знать про поле peerDependecies в
Это поле позволяет установить требования для пользователя библиотеки.
Например, при разработке библиотеки React-компонентов в
Это позволяет избежать дубликатов.
#npm #peerDependencies
При разработке библиотеки очень важно знать про поле peerDependecies в
package.json.Это поле позволяет установить требования для пользователя библиотеки.
Например, при разработке библиотеки React-компонентов в
peerDependencies нужно указать React (при этом подобрав максимально широкий диапазон версий), что будет означать, что пользователь библиотеки должен установить React в свой проект самостоятельно (NPM >= 7 сделает это автоматически).Это позволяет избежать дубликатов.
#npm #peerDependencies
Вчера у меня отвалился интернет и я решил протестировать свою домашнюю инфраструктуру на состоятельность.
Выяснилось, что по умолчанию официальный Docker-образ registry ежедневно удаляет все загруженные образы из локального хранилища, что делает невозможным использование его как резервный докерхаб на случай отключения интернета.
К счастью это поведение выключается в конфигурации хранилища параметром uploadpurging.
#docker #selfHosted
Выяснилось, что по умолчанию официальный Docker-образ registry ежедневно удаляет все загруженные образы из локального хранилища, что делает невозможным использование его как резервный докерхаб на случай отключения интернета.
К счастью это поведение выключается в конфигурации хранилища параметром uploadpurging.
#docker #selfHosted
В продолжение темы домашней инфраструктуры: я поставил на свой домашний сервер Verdaccio — фактически это опенсорсный селф-хостед NPM репозиторий. Его я указал в домашнем
В целом можно запустить его в Docker-контейнере на своей машине, чтобы ускорить установку зависимостей за счёт проксирования с кешем, хотя вполне вероятно в данном случае более эффективным решением будет использовать кеш пакетного менеджера, чтобы не тратить ресурсы на сервер.
В условиях отсутствия интернета эта штука сработала только в ситуациях, когда не нужно резолвить зависимости (установка конкретной версии или из локфайла), так что для полного оффлайна, видимо, придётся немного поплясать с бубном...
#npm #selfHosted
.npmrc, чтобы использовать как репозиторий по умолчанию.В целом можно запустить его в Docker-контейнере на своей машине, чтобы ускорить установку зависимостей за счёт проксирования с кешем, хотя вполне вероятно в данном случае более эффективным решением будет использовать кеш пакетного менеджера, чтобы не тратить ресурсы на сервер.
В условиях отсутствия интернета эта штука сработала только в ситуациях, когда не нужно резолвить зависимости (установка конкретной версии или из локфайла), так что для полного оффлайна, видимо, придётся немного поплясать с бубном...
#npm #selfHosted
@microsoft/api-extractor
Меня раздражают почти все потребительские продукты Microsoft, но то, что они делают для разработчиков, действительно воодушевляет.
Среди ассортимента крутых тулзов от них имеется api-extractor — утилита, которая, как следует из названия, "извлекает API" вашей библиотеки.
Под этим "извлечением" подразумевается сбор типов и комментариев в коде (для которых, кстати, разработана спецификация tsdoc) и формализация их в виде модели API библиотеки.
Возможно, звучит довольно скучно, но на практике эта модель позволяет без дополнительных телодвжений:
— упаковывать все
— валидировать публичный API библиотеки и централизованно следить за его изменениями, чтобы по более явным критериям определять наличие "breaking changes" при очередном релизе (с помощью автоматически генерируемого файла
— автоматически генерировать документацию по библиотеке (с помощью api-documenter);
— придумайте свой юзкейс.
Этот инструментарий уже зарекомендовал себя в опенсорс разработке и используется, например, в redux-toolkit.
#docs #tools #build
Меня раздражают почти все потребительские продукты Microsoft, но то, что они делают для разработчиков, действительно воодушевляет.
Среди ассортимента крутых тулзов от них имеется api-extractor — утилита, которая, как следует из названия, "извлекает API" вашей библиотеки.
Под этим "извлечением" подразумевается сбор типов и комментариев в коде (для которых, кстати, разработана спецификация tsdoc) и формализация их в виде модели API библиотеки.
Возможно, звучит довольно скучно, но на практике эта модель позволяет без дополнительных телодвжений:
— упаковывать все
*.d.ts файлы в один общий index.d.ts со всеми экспортируемыми типами;— валидировать публичный API библиотеки и централизованно следить за его изменениями, чтобы по более явным критериям определять наличие "breaking changes" при очередном релизе (с помощью автоматически генерируемого файла
api-report.md, который попадает в пулл реквесты и тоже становится предметом обсуждения);— автоматически генерировать документацию по библиотеке (с помощью api-documenter);
— придумайте свой юзкейс.
Этот инструментарий уже зарекомендовал себя в опенсорс разработке и используется, например, в redux-toolkit.
#docs #tools #build
В предыдущем посте была картинка с предлагаемым мной пайплайном для сборки библиотеки и первым этапом в нём является tsc — это компилятор тайпскрипта, который есть в самом пакете
Вероятно кто-то для сборки библиотеки решит взять Rollup или что-то подобное и накрутить гору плагинов, но на мой взгляд в подавляющем большинстве случаев это не будет иметь смысла и не принесёт ничего кроме усложнения сборки.
Единственное, чем может быть в данном случае полезен бандлер, — подключение не джаваскриптовых модулей. Например, для svg в react может понадобиться подключить svgr, но и у этого инструмента есть CLI, то есть его можно использовать и без бандлера. Не нужно использовать бандлер как таск-раннер. Кстати, я сейчас занимаюсь разработкой "умного" таск-раннера, который будет автоматически параллелить выполнение NPM-скриптов, так что ждите анонс.
Будет гораздо лучше доставить код до пользователя в максимально близком к исходному виде, чтобы уже пользователь библиотеки применял при необходимости какие-то свои оптимизации к модулям и добавлял полифиллы для новых возможностей языка, сохранив возможность использовать современный синтаксис.
Если скорость сборки с
В будущих постах расскажу ещё о нескольких инструментах и практиках сборки библиотек с помощью
#build #tools
typescript.Вероятно кто-то для сборки библиотеки решит взять Rollup или что-то подобное и накрутить гору плагинов, но на мой взгляд в подавляющем большинстве случаев это не будет иметь смысла и не принесёт ничего кроме усложнения сборки.
Rollup в отличии от tsc это бандлер — утилита, которая объединяет множество модулей в один файл (бандл). Но действительно ли это может быть полезно для библиотеки? На мой взгляд нет.Единственное, чем может быть в данном случае полезен бандлер, — подключение не джаваскриптовых модулей. Например, для svg в react может понадобиться подключить svgr, но и у этого инструмента есть CLI, то есть его можно использовать и без бандлера. Не нужно использовать бандлер как таск-раннер. Кстати, я сейчас занимаюсь разработкой "умного" таск-раннера, который будет автоматически параллелить выполнение NPM-скриптов, так что ждите анонс.
Будет гораздо лучше доставить код до пользователя в максимально близком к исходному виде, чтобы уже пользователь библиотеки применял при необходимости какие-то свои оптимизации к модулям и добавлял полифиллы для новых возможностей языка, сохранив возможность использовать современный синтаксис.
Если скорость сборки с
tsc вас не устраивает, можно просто заменить его на swc, но стоит учитывать, что tsc это на текщий момент единственный инструмент в экосистеме JavaScript, который умеет проверять типы (хотя вроде бы работа в этом направлении уже ведётся), остальные же просто их вырезают.В будущих постах расскажу ещё о нескольких инструментах и практиках сборки библиотек с помощью
tsc.#build #tools
One more thing!
В пайплайне сборки проекта помимо запуска
Для решения этой задачи я написал утилиту @lndsld/orc, которая сама запустит скрипты в нужной последовательности и распараллелит их, если это возможно. Для этого достаточно просто указать зависимости между скриптами прямо в
На текущий момент утилита имеет только самую базовую функциональность по оркестрации скриптов, но в будущем может стать более "умной", так что буду ждать вашего фидбэка :)
#tools #build
В пайплайне сборки проекта помимо запуска
tsc могут быть и другие утилиты (например, api-extractor), в таком случае просто запустить все скрипты параллельно не получится, так как необходимо соблюдать порядок их запуска (api-extractor должен быть запущен только после генерации .d.ts файлов).Для решения этой задачи я написал утилиту @lndsld/orc, которая сама запустит скрипты в нужной последовательности и распараллелит их, если это возможно. Для этого достаточно просто указать зависимости между скриптами прямо в
package.json.На текущий момент утилита имеет только самую базовую функциональность по оркестрации скриптов, но в будущем может стать более "умной", так что буду ждать вашего фидбэка :)
#tools #build
Мифология БЭМ
По моим наблюдениям, среди разработчиков распространён миф, что БЭМ — это просто довольно некрасивый и чрезмерно длинный способ нейминга CSS-классов, который не очень-то актуален в современной разработке ввиду наличия во фронтенд-экосистеме огромного количества более удобных инструментов, полностью заменяющих его. На самом деле, это в корне неверное суждение, поскольку БЭМ — это нечто большее, чем просто нейминг, и, на мой взгляд, он может быть полезен любому веб-разработчику независимо от технического стека...
#css #bestPractices
По моим наблюдениям, среди разработчиков распространён миф, что БЭМ — это просто довольно некрасивый и чрезмерно длинный способ нейминга CSS-классов, который не очень-то актуален в современной разработке ввиду наличия во фронтенд-экосистеме огромного количества более удобных инструментов, полностью заменяющих его. На самом деле, это в корне неверное суждение, поскольку БЭМ — это нечто большее, чем просто нейминг, и, на мой взгляд, он может быть полезен любому веб-разработчику независимо от технического стека...
#css #bestPractices
Telegraph
Мифология БЭМ
По моим наблюдениям, среди разработчиков распространён миф, что БЭМ — это просто довольно некрасивый и чрезмерно длинный способ нейминга CSS-классов, который не очень-то актуален в современной разработке ввиду наличия во фронтенд-экосистеме огромного количества…
Хранимые и вычисляемые данные
Состоянием приложения являются данные, сохраняемые в памяти на определённом этапе его работы. Очень важно понимать, что не любые данные и не в любой ситуации имеет смысл куда-либо сохранять...
#react #stateManagement #computerScience #bestPractices
Состоянием приложения являются данные, сохраняемые в памяти на определённом этапе его работы. Очень важно понимать, что не любые данные и не в любой ситуации имеет смысл куда-либо сохранять...
#react #stateManagement #computerScience #bestPractices
Telegraph
Хранимые и вычисляемые данные
Состоянием приложения являются данные, сохраняемые в памяти на определённом этапе его работы. Очень важно понимать, что не любые данные и не в любой ситуации имеет смысл куда-либо сохранять.
Инверсия зависимостей в React
Старые добрые принципы SOLID могут быть полезны в любой области разработки. Особенно важным я считаю принцип инверсии зависимостей. В React существуют механизмы, позволяющие реализовать этот принцип, и в этом очень помогает Typescript...
#react #bestPractices
Старые добрые принципы SOLID могут быть полезны в любой области разработки. Особенно важным я считаю принцип инверсии зависимостей. В React существуют механизмы, позволяющие реализовать этот принцип, и в этом очень помогает Typescript...
#react #bestPractices
Менеджмент зависимостей в Javascript
Для многих разработчиков процесс установки зависимостей представляет собой магию, которая происходит при выполнении
(Кнопка "посмотреть", видимо, только у ссылок на Telegraph появляется...)
#npm #tools
Для многих разработчиков процесс установки зависимостей представляет собой магию, которая происходит при выполнении
npm install. Разработчикам, имеющим у себя в проекте большое количество зависимостей и тем, кто разрабатывает эти самые зависимости, публикуя в виде NPM-пакетов, будет полезно разобраться в принципах работы этой магии, чтобы сделать установку более эффективной и не создавать проблемы коллегам....(Кнопка "посмотреть", видимо, только у ссылок на Telegraph появляется...)
#npm #tools
Tproger
Как реализован менеджмент зависимостей в JavaScript
В статье подробно поговорим про принципы управления зависимостями в Javascript и обсудим существующие пакетные менеджеры.
Релиз Rspack
Вчера вышла первая версия Rspack — бандлера, написанного на Rust, но с API, полностью совместимым с Webpack (ну пока что не полностью).
На бумаге это должно работать так: мы просто выкидываем Webpack из проекта, заменяем его на Rspack и получаем х10 скорость сборки.
На практике же всё пока не так радужно: я попробовал сделать такую замену в реальном проекте и получил кучу абсолютно нечитаемых исключений, выкинутых из Rust, поэтому я нашёл у себя маленький проект, в котором был простой Webpack-конфиг и попробовал сделать замену там, на сей раз успешно. Весьма нерепрезентативные результаты моих экспериментов в разных комбинациях вы можете видеть на приложенной картинке.
Помимо заявленной совместимости с Webpack Rspack предлагает также некоторое количество инструментов из коробки: например, самого быстрого результата удалось достичь без использования каких-либо лоадеров для Typescript-файлов, так как в Rspack уже встроен SWC.
Этот релиз — ещё один большой шаг к глобальной "растификации" Javascript-экосистемы. Предыдущим похожим проектом был Turbopack, но, несмотря на схожесть названия, он не предлагал такого простого способа для миграции с Webpack.
Посмотрим, во что в результате выльется такой проект. А он точно будет развиваться, поскольку разрабатывают его не опенсорс-энтузиасты, а небезызвестная компания ByteDance.
#tools #build
Вчера вышла первая версия Rspack — бандлера, написанного на Rust, но с API, полностью совместимым с Webpack (ну пока что не полностью).
На бумаге это должно работать так: мы просто выкидываем Webpack из проекта, заменяем его на Rspack и получаем х10 скорость сборки.
На практике же всё пока не так радужно: я попробовал сделать такую замену в реальном проекте и получил кучу абсолютно нечитаемых исключений, выкинутых из Rust, поэтому я нашёл у себя маленький проект, в котором был простой Webpack-конфиг и попробовал сделать замену там, на сей раз успешно. Весьма нерепрезентативные результаты моих экспериментов в разных комбинациях вы можете видеть на приложенной картинке.
Помимо заявленной совместимости с Webpack Rspack предлагает также некоторое количество инструментов из коробки: например, самого быстрого результата удалось достичь без использования каких-либо лоадеров для Typescript-файлов, так как в Rspack уже встроен SWC.
Этот релиз — ещё один большой шаг к глобальной "растификации" Javascript-экосистемы. Предыдущим похожим проектом был Turbopack, но, несмотря на схожесть названия, он не предлагал такого простого способа для миграции с Webpack.
Посмотрим, во что в результате выльется такой проект. А он точно будет развиваться, поскольку разрабатывают его не опенсорс-энтузиасты, а небезызвестная компания ByteDance.
#tools #build
Запуск сайта Hacknote.js
Переезд с Telegraph на Github Pages вдохновил меня на полноценное внедрение дизайн-системы, сделанной мной для этого блога на основе темы для VSCode, которой я пользуюсь, — Monokai.pro.
Блог — это контентно-ориентированный сайт, для которого самым важным фактором является скорость доставки контента до конечного пользователя, а самый быстрый способ — прислать готовый HTML. Для этого существуют различные фреймворки, поддерживающие SSR (Server Side Rendering), например, Next.js, а так же SSG (Static Site Generation), например, Gatsby.
SSR предполагает наличие сервера, что мне не подходит, поскольку я не могу запустить сервер на Github Pages, а вот SSG — именно то, что нужно, поскольку страницы создаются не в рантайме, а прямо во время сборки сайта.
Next.js и Gatsby мне совсем не понравились поскольку по какой-то причине без прикручивания к ним костылей прямо на старте они работать не захотели. Когда я уже почти начал реализовывать свой фреймворк, мне встретился Astro, и, как оказалось, он прямо из коробки делает абсолютно всё, что мне нужно, и невероятно прост в использовании. А ещё одной его крутой фишкой является то, что он может работать с любым UI фреймворком.
Заценивайте новый сайт, на который я уже перенёс несколько статей, включая ремастер статьи про менеджмент зависимостей с перерисованными картинками (кстати, весят они в 3 раза меньше, чем старые некрасивые).
#tools
Переезд с Telegraph на Github Pages вдохновил меня на полноценное внедрение дизайн-системы, сделанной мной для этого блога на основе темы для VSCode, которой я пользуюсь, — Monokai.pro.
Блог — это контентно-ориентированный сайт, для которого самым важным фактором является скорость доставки контента до конечного пользователя, а самый быстрый способ — прислать готовый HTML. Для этого существуют различные фреймворки, поддерживающие SSR (Server Side Rendering), например, Next.js, а так же SSG (Static Site Generation), например, Gatsby.
SSR предполагает наличие сервера, что мне не подходит, поскольку я не могу запустить сервер на Github Pages, а вот SSG — именно то, что нужно, поскольку страницы создаются не в рантайме, а прямо во время сборки сайта.
Next.js и Gatsby мне совсем не понравились поскольку по какой-то причине без прикручивания к ним костылей прямо на старте они работать не захотели. Когда я уже почти начал реализовывать свой фреймворк, мне встретился Astro, и, как оказалось, он прямо из коробки делает абсолютно всё, что мне нужно, и невероятно прост в использовании. А ещё одной его крутой фишкой является то, что он может работать с любым UI фреймворком.
Заценивайте новый сайт, на который я уже перенёс несколько статей, включая ремастер статьи про менеджмент зависимостей с перерисованными картинками (кстати, весят они в 3 раза меньше, чем старые некрасивые).
#tools
Hacknote.js
Блог со статьями для Telegram-канала Hacknote.js.