@js-templates/typescript-library

✨ Your Library Description ✨

Template Features

• 🚀 Blazingly fast and easy installation
• 💡 CI workflows configured for changelogs and release/prerelease cycles
• 🧱 Perfect and easy-to-support tooling setup without any conflicts with CI environment
• 📚 Well-documented conventions for project maintaining (commits, pull-requests, branches)

Using template

1. Replace everything

• Replace all @js-templates/typescript-library entries with your library name
• Replace all js-templates/typescript-library entries with your repo path
• Replace all Your Library Description entries with your library description
• Replace all Your Name entries with your library name
• Update logo.svg
• Update logo's alt

2. Add secrets

• NPM_TOKEN
• FULL_ACCESS_GITHUB_TOKEN if you plan to set up the branch protection

3. (optional) Set up branch protection

• Go to Settings > Branches > Add rule
• Specify main branch
• Enable the following options:
  • Require a pull request before merging (without approvals)
  • Require status checks to pass before merging (you need to run them at least once to appear):
    • test-and-build
    • pr-labeler
  • Include administrators
  • Allow force pushes
• Repeat, but using release/* instead of main
• Create a new Personal Access Token with repo permissions
• Use it as a new Secret named FULL_ACCESS_GITHUB_TOKEN
  It's needed to bypass the branch protection on CI runs

4. The last step

Remove Template Features and Using Template sections from README

Before you start

The README on main branch may contain some unreleased changes.

Go to release/latest branch to see the actual README for the latest version from NPM.

Navigation

• Installation
• Contrubuting
• Maintenance
  • Regular flow
  • Prerelease from
  • Conventions

Installation

NPM:

npm install @js-templates/typescript-library

Yarn:

yarn add @js-templates/typescript-library

Contributing

• Fork this repo
• Use the Regular flow

Please follow Conventions

Maintenance

The dev branch is main - any developer changes is merged in there.

Also, there is a release/latest branch. It always contains the actual source code for release published with latest tag.

All changes is made using Pull Requests - push is forbidden. PR can be merged only after successfull test-and-build workflow checks.

When PR is merged, release-drafter workflow creates/updates a draft release. The changelog is built from the merged branch scope (feat, fix, etc) and PR title. When release is ready - we publish the draft.

Then, the release workflow handles everything:

• It runs tests, builds a package, and publishes it
• It synchronizes released tag with release/latest branch

Regular flow

• Create feature branch
• Make changes in your feature branch and commit
• Create a Pull Request from your feature branch to main
  The PR is needed to test the code before pushing to release branch
• If your PR contains breaking changes, don't forget to put a BREAKING CHANGES label
• Merge the PR in main
• All done! Now you have a drafted release - just publish it when ready

Prerelease flow

• Assume your prerelease tag is beta
• Create release/beta branch
• Create feature branch
• Make changes in your feature branch and commit
• Create a Pull Request from your feature branch to release/beta
  The PR is needed to test the code before pushing to release branch
• Create Github release with tag like v1.0.0-beta, pointing to release/beta branch
  For next beta versions use semver build syntax: v1.0.0-beta+1
• After that, the release workflow will publish your package with the beta tag
• When the beta version is ready to become latest - create a Pull Request from release/beta to main branch
• Continue from the Regular flow's #5 step

Conventions

Feature branches:

• Should start with feat/, fix/, docs/, refactor/, and etc., depending on the changes you want to propose (see pr-labeler.yml for a full list of scopes)

Commits:

• Should follow the Conventional Commits specification
• You can find supported types and scopes into .cz-config.js

Pull requests:

• Should have human-readable name, for example: "Add a TODO list feature"
• Should describe changes
• Should have correct labels (handled by PR Labeler in most cases)