Comments 8

Хорошее руководство, несколько примечаний:


  • tslint в скором времени обещают забросить в пользу typescript-eslint
  • вместо standard-version зачастую хватает команды npm version
C tslint согласен. Хотя typescript'еры не очень охотно переводят на него свои проекты, рано или поздно придется. Кстати, вот здесь roadmap tslint на закрытие пакета в несколько стадий

В пункте про `standard-version` я хочу показать возможность решить вопросы о наименовании коммитов, ведении changelog-файла и версионировании разом. npm version в данном случае решает только третью задачу
Хорошая статья. По своему опыту еще могу порекомендовать комбинацию semantic-release + commitizen для честного и прозрачного версионирования, хотя не всем такое по душе.
Давайте еще воспользуемся npm-хуками и добавим postbuild скрипт, который будет копировать README.md в папку со сборкой. Так мы никогда не забудем обновить описание пакета на NPM.

Почему бы не добавить README.md и папку со сборкой в секцию files в package.json?


И еще вопрос: кто или что в итоге вызывает npm-скрипт release? По идее, он должен вызываться при merge в master-ветку?

Привет!

Мне нравится, что мы можем положить в npm не только необходимые файлы, но и оставить в этих файлах только самое необходимое. `files` в `package.json` будет достаточно для обычной JS библиотеки. Если взять, например, Angular Workspace с библиотекой, то там создание отдельной папки для публикации просто необходимо, потому что мы передаем в npm иной `package.json` — очищенный от зависимостей и информации, которые не относятся к финальной либе

Да, вызов release остался открытым. Если проект будет развиваться, то стоит настроить авторелиз release-веток
Only those users with full accounts are able to leave comments. Log in, please.