npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@corva/fe-fix-cli

v0.1.20

Published

A CLI to simplify hot fixing process

Downloads

738

Readme

@corva/fe-fix-cli

This is a CLI that automates fixes creation process

Process that it automates

You need to make a hot-fix, which means you need to do a bunch of PRs to all environment branches you have & bump the version & create PRs. This CLI automates that by auto-creation of your fix branches, cherry-picking your fix & creating a PR.

So, the idea is very simple, you create your main fix branch, e.g.: hot-fix/dc-777 for your production branch and the script automatically generates fixes for your downsteam environments, doing exactly the next:

  • bumps the version of your hot-fix/dc-7777 branch and creates a PR for production branch
  • creates fix branch beta-fix/dc-77777 for beta, bumps the version, makes a PR
  • creates fix branch release-fix/dc-77777 for release, bumps the version, makes a PR
  • creates fix branch fix/dc-77777 for development, bumps the version, makes a PR

You never interact directly with those other envs fix branches, scripts just applies your changes on your main fix branch to those other environments

Important

This is a concept of such CLI, it mostly handles the ideal case where you don't have any merge conflicts when the script cherry-picks your fix to the other branches. So, simply speaking, if the script fails - you will need to create those PRs manually.

Requirements

  • Install GitHub CLI. gh command should be available in the terminal
  • login to GitHub CLI by running gh auth login
  • add fe-fix-cli-config.js to the root of your project (see details in config section)
  • run corva-fe-fix-cli apply-fix

Usage

  • create fix branch, e.g.: hot-fix/dc-777
  • commit your fix to your fix branch - hot-fix/dc-777 in this case. IMPORTANT: IT SHOULD BE A SINGLE COMMIT ON TOP OF YOUR BRANCH (as the script will be cherry-picking this single fix commit to the other branches). So if you want to add some additional changes later to your fix, you need to commit using git commit --amend to apply your changes to the previous commit
  • run corva-fe-fix-cli apply-fix
  • the script will create a PR for your fix + PRs for all downstream environments

Use cases

Basic use case

You have 4 environments - prod, beta, release, develop. You're doing a hot-fix, so you do checkout from the prod branch, and create hot-fix/dc-77777 branch, you commit your fix as a SINGLE COMMIT, you test the changes on your fix branch, looks like everything works as it should, it's time to merge the changes. Now, standing on your fix branch, run the next command

  corva-fe-fix-cli apply-fix

This will do exactly the next things

$ corva-fe-fix-cli apply-fix

bumping the version of your fix branch: hot-fix/dc-77777-test
✔ bumping version in package.json from 2.113.18 to 2.113.19
✔ committing package.json
trying to push your fix branch: hot-fix/dc-77777-test
pushed fix branch: hot-fix/dc-77777-test
creating a PR for main fix branch: hot-fix/dc-77777-test
created a PR from branch: hot-fix/dc-77777-test: https://github.com/corva-ai/corva-web-frontend/pull/4803

checkout to BETA environment branch
Pulling the updates before applying the fix
Creating a new fix branch beta-fix/dc-77777
cherry-picking the fix
bumping the version of beta-fix/dc-77777 branch
✔ bumping version in package.json from 2.114.6 to 2.114.7
✔ committing package.json
creating a PR for branch: beta-fix/dc-77777
created a PR from branch: beta-fix/dc-77777: https://github.com/corva-ai/corva-web-frontend/pull/4804

checkout to RELEASE environment branch
? Type release branch name release/2.114
you selected the release branch: release/2.114
Pulling the updates before applying the fix
Creating a new fix branch release-fix/dc-77777
cherry-picking the fix
bumping the version of release-fix/dc-77777 branch
✔ bumping version in package.json from 2.114.6 to 2.114.7
✔ committing package.json
creating a PR for branch: release-fix/dc-77777
created a PR from branch: release-fix/dc-77777: https://github.com/corva-ai/corva-web-frontend/pull/4805

checkout to DEV environment branch
Pulling the updates before applying the fix
Creating a new fix branch fix/dc-77777
cherry-picking the fix
creating a PR for branch: fix/dc-77777
created a PR from branch: fix/dc-77777: https://github.com/corva-ai/corva-web-frontend/pull/4806

Returning to the original fix branch: hot-fix/dc-77777-test
CREATED PRs:
PROD : https://github.com/corva-ai/corva-web-frontend/pull/4803
BETA : https://github.com/corva-ai/corva-web-frontend/pull/4804
RELEASE : https://github.com/corva-ai/corva-web-frontend/pull/4805
DEV : https://github.com/corva-ai/corva-web-frontend/pull/4806

✨  Done in 67.36s.

So, as you see we automatically created 4 pull requests for 4 envs.

Existing fix use case. You generated 4 PRs via the script, but it now appears that you need to modify the fix

  • Remove the bump commit from you main fix branch by running git reset --hard head~1. This will remove the last commit - which is a version bump commit.
  • do your changes and update your existing fix commit via git commit --amend. As it's important to have a single commit with your fix as the last commit on your branch
  • And just run corva-fe-fix-cli apply-fix It'll ask you to remove your old fix branches, and will create new ones

Required: Provide environments config

You need to add fe-fix-cli-config.js file to the root of your project. This config describes the environments you have and info needed by the CLI. See the code for more details:

const ENVS_NAMES = {
  DEV: 'DEV',
  RELEASE: 'RELEASE',
  BETA: 'BETA',
  PROD: 'PROD',
};

const standardVersionBumpConfig = {
  noVerify: true,
  releaseAs: 'patch',
  skip: {
    tag: true,
    changelog: true,
  },
};

module.exports = [
  {
    // Name of the environment
    name: ENVS_NAMES.DEV,
    // Main branch of the environment
    branch: 'main',
    // Function that returns fix branch name for the requirement
    getFixBranchNameForTicketId: ticketId => `fix/${ticketId}`,
    // Function that returns ticket id from the envronment branch
    getTicketIdFromFixBranch: fixBranchName => fixBranchName.match(/^fix\/(\w+-\d+).*/)?.[1],
    // When you do the fix for this environment, it should also be applied to those environment
    applyFixForEnvs: [],
    // If config exists, the CLI will bump the version running standard-version library: https://www.npmjs.com/package/standard-version
    standardVersionBumpConfig: null,
  },
  {
    name: ENVS_NAMES.RELEASE,
    branch: 'PROMPT',
    getFixBranchNameForTicketId: ticketId => `release-fix/${ticketId}`,
    getTicketIdFromFixBranch: fixBranchName =>
      fixBranchName.match(/^release-fix\/(\w+-\d+).*/)?.[1],
    applyFixForEnvs: [ENVS_NAMES.DEV],
    standardVersionBumpConfig,
  },
  {
    name: ENVS_NAMES.BETA,
    branch: 'beta',
    getFixBranchNameForTicketId: ticketId => `beta-fix/${ticketId}`,
    getTicketIdFromFixBranch: fixBranchName => fixBranchName.match(/^beta-fix\/(\w+-\d+).*/)?.[1],
    applyFixForEnvs: [ENVS_NAMES.RELEASE, ENVS_NAMES.DEV],
    standardVersionBumpConfig,
  },
  {
    name: ENVS_NAMES.PROD,
    branch: 'production',
    getFixBranchNameForTicketId: ticketId => `hot-fix/${ticketId}`,
    getTicketIdFromFixBranch: fixBranchName => fixBranchName.match(/^hot-fix\/(\w+-\d+).*/)?.[1],
    applyFixForEnvs: [ENVS_NAMES.BETA, ENVS_NAMES.RELEASE, ENVS_NAMES.DEV],
    standardVersionBumpConfig,
  },
];

Development Information

Instalation steps

Clone this repository and run yarn inside the directory. On postinstall git hooks would be configured for this repository.

Development flow

To develop new feature or implement fix one need to create new branch from main one and name it properly: branch-type/JIRA_ID-jira_ticket_description i.e.

  • feature/DC-1234-add-Table-component
  • fix/DR-9999-fix-broken-page

When changes are ready please create commit with meaningful description using Conventional Commits specification. Commit message should have form commit-type(JIRA_ID): commit message. All types of commits could be found here

Please note that feat and fix commits messages will be used during automatic changelog creation while chore, docs and others will not.

Do not create 2 commits with same name and consider amending previous commit instead with git commit --amend --no-edit.


⚠⚠⚠ In case commit introduces breaking changes incompatible with existing API special commit message have to be used. Just type git commit and commit template will be opened to edit. The main difference with regular commit messages - such commit MUST have footer(s) BREAKING CHANGES⚠⚠⚠


On merging the PR to main branch an automatic release flow will be triggered. New package version will be determined based on changes introduced by commit. fix corresponds to patch, feat to minor and breaking changes to major version release.

More details on semantic versioning could be found in official SemVer specification.

Note: untill first major version is released the package is considered as under development and breaking changes will correspond to minor release.