Comments 6
Минус dual packaging как верно замечено - только в увеличении node_modules и соответственно размера скачиваемых файлов. Для небольших библиотек это не то, чтобы проблема. Но вот если пакет резко переходит на esm-only (как например Chalk 5 в 2021 году), то только ради него переводить большие проекты на esm - не стоит усилий и бизнес не даст денег на рефакторинг без практической пользы. Тем более что тогда у node.js были серьезные проблемы с использованием cjs из mjs и многие пакеты не заводились, также и старые версии TS влияют (а их апгрейд связан с большими сложностями).
Даже сейчас есть немало проектов на старых node.js и TS, и если работа проектная или фрилансерская, но требуется использовать какой-нибудь новый пакет - то будет однозначно выбрана версия с dual packaging. И я очень сомневаюсь, что это 10% кейсов, скорее думаю больше 50%, по крайней мере из того, что мне встречается. Вывод - свои библиотеки выдаю в обоих форматах, а минус в виде небольшого увеличения node_modules несущественен по сравнению с увеличенной вдвое совместимостью.
По крайней мере, на сегодняшний момент так, а через пару лет думаю уже можно на esm-only переходить.
В 2021 было довольно отчаянным рубить cjs, сейчас более отчаянно — сидеть на post-EOL node с потенциалом уязвимостей.
Для новых библиотек стратегия "esm-only до первой жалобы" кажется адекватной, меньше заморочек для запуска MVP. Да, есть внешние инстументы с проблемами ESM (jest / TS / express), но непонятно, какая доля проектов на активной поддержке сидит на проблемных версиях. Например, для TS это как раз похоже на 10–12%
В любом случае, я даю информацию, решает каждый сам) Например, часто esm можно оторвать для внутренних библиотек, где мы точно знаем все версии nodejs и форматы кода наших проектов.
Для новых библиотек стратегия "esm-only до первой жалобы" кажется адекватной
Думаю, что для них как раз не подойдет. Первые пользователи будут скачивать, видеть что в их проекте не заводится, может быть сотый или тысячный заведет ишью, которое еще будет висеть, пока у мейнтейнера руки дойдут (а может он посчитает, что ему cjs не нужен - значит никому не нужен). Несложно сразу сделать сборку в 2 формата и увеличить охват потенциальных пользователей, вполне возможно, что среди них найдутся активные опенсорсеры, которые помогут развить библиотеку.
А на dual packaging жаловаться 100% никто не будет - мало кто лезет в node_modules чтобы смотреть финальные js-файлы, и еще меньше тех, кто заботится об экономии десятка килобайт в этой папке (особенно в современных проектах, где бандлер, линтер и фреймворк заставляют скачивать десятки доп. пакетов, как правило безальтернативных).
Для меня уже давно это критерий качества. Если нет esm - это плохая библиотека и ее не надо использовать. Есть исключения для некоторых, которые я все равно в esm конвертирую.
Для меня основной плюс. Из проекта, можно бандлер выкинуть, как обязательный элемент.
Изоморфный код это очень удобно.
Это я не рассматриваю проекты где используется cjs, но я с такими проектами уже давно не сталкивался. А если на поддержке есть такие, то там как правило с этим проблем не возникало. Что в проект заложено то и есть.
А это сложный момент, вот например сложно сказать что postcss — плохая библиотека. Там CJS не доставляет проблем, вот его и не трогают. Выглядит хорошим решением!
https://github.com/chialab/rna/tree/main
Я esbuild использую. Там все есть.
И я написал, что есть модули, ценность которых выше, чем качество их сборки. Но postcss точно к ним не относится.
Пока, dual packaging: в каком формате публиковать npm-библиотеки