Remove bundles and set up package's autopublish

[talyguryn]

Remove bundles from repo and ignore dist directory.

Publish a new package on push to release/** branch.

[khaydarov]

а нельзя вынести все это в sh-файл и его вызывать?

[talyguryn]

не могу сейчас ответить на этот вопрос. может возникнуть проблема с секретными переменными. этот код работает стабильно на плагинах

[semoal]

Just saying, but Github workflows can be manually dispatched, I usually build my workflows with a dispatch action that triggers the release action, in that way i can store on "next|master" branch all the commits with conventional naming, and when a version is ready, just press the button to deploy.

It's pretty easy:

...

on:
  workflow_dispatch:
    inputs:
        distTag:
          description: 'Dist tag to publish'
          required: true
          default: 'latest'

....

      - name: Release
        if: ${{github.event.inputs.distTag == 'latest' || github.event.inputs.distTag == 'next'}}
        run: npm run release

Normally I found unmaintainable moving code from branches only to deploy. 🚀

[gohabereg]

I think ideal flow is:

1. We merge something to next/master
2. Push a git tag with version number
3. Action publishes the package

We need master for releases (npm latest tag) and next for release candidates (npm next tag).
I'm not sure if action can update versions in package json automatically, but would be cool to have such a feature.

I'm also not sure if we still need release/* branches (as we have git tags) but at the moment I don't know another way to patch previous versions in case of vulnerabilities.
I was thinking of this flow:

1. Checkout new branch from release tag we need to patch
2. Make fixes, publish to npm

However I don't know how to save those fixes in git history (as we can't just merge them to the master branch). Some investigation of best practices is required here

[semoal]

I think ideal flow is:

1. We merge something to next/master
2. Push a git tag with version number
3. Action publishes the package

We need master for releases (npm latest tag) and next for release candidates (npm next tag).
I'm not sure if action can update versions in package json automatically, but would be cool to have such a feature.

I'm also not sure if we still need release/* branches (as we have git tags) but at the moment I don't know another way to patch previous versions in case of vulnerabilities.
I was thinking of this flow:

1. Checkout new branch from release tag we need to patch
2. Make fixes, publish to npm

However I don't know how to save those fixes in git history (as we can't just merge them to the master branch). Some investigation of best practices is required here

My actual flow on my libraries is using semantic-release package with conventional-commits.

The commit contains the following structural elements, to communicate intent to the consumers of your library:

• fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
• feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).

BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.

• types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.

Semantic release package automatically updates package.json version, generates changelog, and pushes the git tag (Also pushes to npm and creates a release on github)

On my libraries I merge commits from pull requests to next branch (with a decided roadmap), when the roadmap is closed, i just press the manual button release, semantic release will look up all the commits and will decide what version will release.

With next branch will release a pre-release tag, with master a stable release. I can provide help if you need

[gohabereg]

@semoal
Thanks for details! Sounds cool, I think we need something similar.

How do you handle cases when some vulnerability found in previous releases (e.g. current version is 2.0.0, affected version 1.0.0)? So you need to patch 1.0.0 to provide fix for a users who didn't update to 2.0.0 because of breaking changes.
If you mark releases with git tags in master branch, where can you save fix for 1.0.1?

[semoal]

@semoal
Thanks for details! Sounds cool, I think we need something similar.

How do you handle cases when some vulnerability found in previous releases (e.g. current version is 2.0.0, affected version 1.0.0)? So you need to patch 1.0.0 to provide fix for a users who didn't update to 2.0.0 because of breaking changes.
If you mark releases with git tags in master branch, where can you save fix for 1.0.1?

Basically on my listeners of branches, i also listen for "hotfix/**" branch.
When a hotfix is needed for 1.0.0 tag, i just search that tag on git.

git checkout "COMMIT-SHA of the 1.0.0 tag"
git checkout -b hotfix/1.0.1
git add .
git commit -m "fix: vulnerability blabla"
git push

On my github ci i contain a release action just for master and normal situations and one for hotfix.
The hotfix one except using git tags for knowning the version, it checks package.json number. In that way you can publish easily the hotfix you need for deprecated branches.

[semoal]

I could create a starter at the start of the next week, if you're confortable with it.
Meanwhile big tasks like read only or opening api tunes can consume better your time 😏

[neSpecc]

Outdated

[talyguryn]

see #1546