Auto: Плагин: применяйте метки PR на основе сообщений коммитов в стиле семантического выпуска.

Довольно странно, как это зависит от ESM

Вероятно, он должен использовать esm для сборки, а не для производства.

это похоже на использование babel-register вместо того, чтобы просто создавать его и публиковать папку dist

Сначала я думал так же, но взгляд на исходный код говорит об обратном.

edit: О, nvm, вы говорите, что esm можно использовать для компиляции перед публикацией. Мы должны отправить PR.

В остальном вроде хороший модуль. Красиво и худощаво

Похоже, esm не предназначен для компиляции: https://github.com/standard-things/esm/issues/13#issuecomment -321710199

Я говорю, что мы пока делаем форк и преобразуем синтаксис import и export в CommonJS.

хм, да, я просто читал ридми. Похоже, я неправильно понял

esm кажется добавляет 65kb 😮

https://packagephobia.now.sh/result?p=parse-commit-message
https://bundlephobia.com/[email protected]

Сделаю пр для перехода на https://github.com/developit/microbundle и возможно он добавит.

Вместо этого вам следует рассмотреть возможность использования https://github.com/egoist/bili . Он имеет вдвое меньший размер установки, но может иметь и другие компромиссы. Точно сказать не могу.

https://github.com/tunnckoCoreLabs/parse-commit-message/pull/55

Кстати, присоединиться к вечеринке. git-commits-since и detect-next-version могут быть здесь более полезными?

Я использую esm из-за гарантий и потому, что это стоит за флагом функции Node esm. Я мог бы использовать ascjs или что-то подобное, например, rewrite- imports, но esm поддерживает гораздо больше, чем просто импорт/экспорт. И поскольку я не буду _ничего_ строить шаг или что-то в этом роде, для тестирования я просто использую его как крючок для своего бегуна.

Что подводит нас к этому, мы можем переключиться на ascjs или asbundle .

@aleclarson, почему размер у меня такая большая проблема? Даже в мире узлов наши менеджеры пакетов уже достаточно умны, чтобы выполнять дедупликацию.

@aleclarson, почему размер у меня такая большая проблема? Даже в мире узлов наши менеджеры пакетов уже достаточно умны, чтобы выполнять дедупликацию.

Я никогда не упоминал о дублирующихся зависимостях как о проблеме. Я просто опасаюсь раздутых инструментов в целом. "Чем легче, тем лучше" - мое правило, но каждому свое. Мне не очень интересно это обсуждать. :)

Кстати, присоединиться к вечеринке. git-commits-since и detect-next-version могут быть здесь более полезными?

Я бы предпочел использовать parse-commit-message , так как эти пакеты, кажется, дублируют логику, которая уже существует в auto-release , но, возможно, @hipstersmoothie будет готов заменить существующую логику этими пакетами, чтобы уменьшить нагрузку на обслуживание.

:rocket: Выпуск был выпущен в версии 10.0.0 :rocket: