maik3345 / projex-toolbet

Projex CLI

---

A command line to manage the workflow of the projects with git, vtex and bash commands

Installation

npm i projex

npm i -g projex

Available commands:

$ projex

    A command line to manage the workflow

    VERSION
      projex/1.26.0 darwin-x64 node-v18.20.1

    USAGE
      $ projex [COMMAND]

    TOPICS
      bash  Utilities for manage the bash process and workflow
      git   Utilities for manage the git repository
      vtex  Utilities for manage the vtex process and workflow

    COMMANDS
      help     display help for projex

Local development

Start npm run dev

local sudo npm link ò node npm link

Post in npm

Publish to npm npm run postrelease

How to create new module

Create the command file in the folder ./src/commands with the name of the command, for example ./src/commands/git/git.ts, create the examples, flags and args options in the file and export the command, you can check the hello-word example app of oclif to see how to create a command or check the existent commands in the folder ./src/commands

List of commands

You can see the list of commands with the command projex --help and you can see the help of a specific command with the command projex <command> --help

Command	Description
projex git init	Initialize base files for managing documentation and versioning in a Git repository
projex git setup husky	Set up Husky for selected repositories (only for Git users)
projex git setup devops template	Add necessary files and folders for Azure DevOps setup
projex git update changelog	Update the changelog file with the latest changes in the current branch or with the provided content. (Only for git users)
projex git clone	Clone the specified repositories (Only for git users)
projex git release	Bumps the app version, commits, and pushes the app to the remote repository (Only for git users).
projex bash run	Run a command in the current directory or select multiple directories
projex vtex login	Command to log in to VTEX. This command uses the API key and API token to obtain the authentication token and save it in the VTEX config file, allowing the process to use the VTEX CLI.
projex vtex cms backup	Download the files from the checkout files of a VTEX site
projex vtex cms deploy	Deploy local files in the checkout of the current account
projex vtex run	Run a command and automatically accept any "Yes/No" questions by default.
projex vtex run-script	Run a command from the manifest.json file, if the command not exist in this file pass to search in the package.json file default.

Manage the release version of your project

The command projex git release allows you to manage the release version of your project, check the usage of the command:

Bumps the app version, commits, and pushes the app to the remote repository (Only for git users).

USAGE
  $ projex git release [RELEASETYPE] [TAGNAME] [-v] [-h] [-y] [--no-push] [--no-deploy] [--no-check-release]
    [--no-tag] [--get-version]

ARGUMENTS
  RELEASETYPE  (pre|major|minor|patch|prerelease) [default: patch] The type of release. Defaults to "patch".
  TAGNAME      (stable|beta|hkignore) [default: beta] The name of the tag. Defaults to "beta".

FLAGS
  -h, --help              Shows this help message.
  -v, --verbose           Shows debug level logs.
  -y, --yes               Automatically answer yes to all prompts.
      --get-only-version-number  Get the version number only.
      --get-release-type         Get the release type of the current version.
      --get-version              Only get the current version without performing any release actions.
      --no-check-release         Do not automatically check if the release is valid and does not have local changes.
      --no-deploy                Do not automatically run the preRelease script from the manifest file.
      --no-post-release          Do not automatically run the postRelease script from the manifest file.
      --no-pre-release           Do not automatically run the preRelease script from the manifest file.
      --no-push                  Do not automatically push all changes to the remote repository.
      --no-tag                   Do not automatically tag the release.

DESCRIPTION
  Bumps the app version, commits, and pushes the app to the remote repository (Only for git users).

EXAMPLES
  projex git release

  projex git release patch

  projex git release patch beta

  projex git release minor stable

  projex git release pre

To use the command you need to have the package.json file in the root of the project and the version field in the file, the command will update the version of the project in the package.json file and create a tag with the version in the git repository.

When make the update of the version, the command will update the CHANGELOG.md file with the new version making a release section with the structure:

## [1.25.0] - 2024-04-24

The changelog file need to manage the next structure:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).

## [Unreleased]

Your changes all need to be under the ## [Unreleased] section, the command will move the changes to the new release section with the new version.

Manage the changelog of your project

The command projex git update changelog allows you to manage the changelog of your project, check the usage of the command:

Update the changelog file with the latest changes in the current branch or with the provided content. (Only for git users)

USAGE
  $ projex git update changelog [RELEASETYPE] [CHANGELOGCONTENT] [-v] [-h]

ARGUMENTS
  RELEASETYPE       (Added|Changed|Fixed|Major) [default: Changed] The type of release for the changelog.
  CHANGELOGCONTENT  Pass the list of comments in a string. This content is used to generate the changelog file changes
                    without using git rev-list. Example: 'test-change-01\ntest-change-02'. Use '\\n' to separate the
                    comments without adding space between them.

FLAGS
  -h, --help     Shows this help message.
  -v, --verbose  Shows debug level logs.

DESCRIPTION
  Update the changelog file with the latest changes in the current branch or with the provided content. (Only for git users)

EXAMPLES
  projex git update changelog [releaseType]

  projex git update changelog Major 'test-change-01\ntest-change-02'

To use the command you need to have the CHANGELOG.md file in the root of the project, the command will update the changelog file with the latest changes in the current branch or with the provided content.

Setup husky in your project

The command projex git setup husky allows you to setup husky in your project, check the usage of the command:

Create a basic git files

The command projex git init allows you to create the basic files for managing documentation and versioning in a Git repository, check the usage of the command:

this command will create the following files:

  - docs - Folder to store the documentation of the project
  - README.md - File with the description of the project
  - CHANGELOG.md - File with the changelog of the project
  - .gitignore - File with the gitignore rules

projex-toolbet's Issues

change the process to update the changelog content

Implementar manejo de cambios en el changelog en base a los pull request que hay en master integrados

Se plantea tener el siguiente flujo de trabajo

1. Un dev realiza la creación de un pull request siguiente el estandar de conventional commits types: build:, chore:, ci:, docs:, style:, refactor:, perf:, test: para el manejo de un major release se usará los mismos types pero con el signo ! ejemplo feat!:
2. El pull request deberá contener al final un númeral con el id de la issue sobre la cual se está trabajando
3. El pull request una vez aprobado se integrará en la rama principal
4. Si hay varios pull request por integrar en la rama master no será necesario crear una rama release, se integraran uno a uno en la rama principal estos cambios y luego se creará el release
5. para la creación del release se empleará el comando projex git update changelog el cual deberá de hacer lo siguiente

ejemplo de creación de un título

fix(expo): android version now correctly builds as a number (#1770)

<type>[optional scope]: <description> (issue)

[optional body]

[optional footer(s)]

• (no se trabajó) se deberá crear un comando para crear un pull request con el release, se plantea lo siguiente:

  • (no se trabajó) se deberá crear una rama con un nombre en especifico por defecto o que se pueda indicar ejemplo release please ellos usan el nombre release-please--branches--main--components--release-please siempre, con esta rama lo que hacen es crear el cambio del release y lo suben a git, luego crean el pull request de esta rama a la rama principal con la siguiente descripción y título
  esto se hace para que al ir a ver el historial de commits se pueda ver así el commit de release sobre la rama principal se tiene el título y el id del pull request y no queda solo con un texto como se ha venido trabajando
  • Para cuando se realice el release de la aplicación se deberá dar soporte para azure y github en lo siguiente

la parte de la versión y la fecha deberá contener el link para comparar el tag creado vs el tag anterior, ejemplo del código para github "## 16.10.0 (2024-03-11)" y ejemplo para azure "https://dev.azure.com/repo/_git/340204-094d-48a0-a1f5-acf3b3608541/branchCompare?baseVersion=GTv1.22.1&targetVersion=GTv1.29.1-2&_a=commits"

• Se obtendran los commits sobre la rama actual donde se esté ejecutando el comando y se obtendran solo los commits que estén hasta antes de un commit que cumpla con la estructura 15.1.2(2023-01-17), se podría usar una expresión regular para detectar la versión o la fecha y así identificar que commits se usarán solamente
• Una vez obtenidos los commits se deberá validar el título del commit y ver que tipo de cambio es para agruparlos y armar algo como esto

si es un tipo fix: se usará el título "### Bug Fixes" y para el resto de tipos se usará "### Features"

en el caso de los breaking changes se separará de esta forma. donde si se usa fix!: se creará el mensaje debajo del título "### BREAKING CHANGES" pero también se creará en la sesión "### Bug Fixes" o si es feat!: o otro tipo diferente a fix: se ubicará debajó de la sesión "### Features"

• cada uno de los títulos del pull request se deberá poner removiendo la parte del type del commit dejando solo el scope si este lo tiene o el mensaje ejemplo

fix(expo): android version now correctly builds as a number (#1770)

una vez mapeado el título quedaría

expo: android version now correctly builds as a number (#1770) (378367b)

se deberá agregar el link para ir al commit dando soporte para azure y github. para estos dos el link es igual entonces solo es tomar el origen del repositorio y con esto se agrega el link

se deberá dar soporte para azure y github donde en azure solo se dejé "#1770" ya que azure toma y arma en el changelog el link del commit y para la url del comm

Implementar comparación de release para github y azure

La idea es implementar esta parte en la creación del versionamiento

En github se arma la url así

16.10.2 (2024-04-16)

y en azure

https://dev.azure.com/repo/_git/340204-094d-48a0-a1f5-acf3b3608541/branchCompare?baseVersion=GTv1.22.1&targetVersion=GTv1.29.1-2&_a=commits

Fix the use of the commit list when make a release version

Se necesita corregir que cuando se realiza un beta o release se toma la lista de commits pero se borran los commits que ya hizo el desarrollador, se deberá conservar los mensajes en el changelog que no existan en la lista de commits

Crear comando para hacer release completo

actualmente se tiene el comando projex git update changelog el cual se mejorará con el issue #6

pero se plantea crear un comando que al ser llamado haga lo siguiente

1. ejecutar la nueva logica de projex git update changelog
2. Determinar el tipo de release en base a los últimos commits, se deberá usar parte de la lógica que se haga para el comando projex git update changelog que permita saber esto, con el tipo de release identificado se ejecutará el comando projex git release
3. realizar un release usando el comando projex git release --no-deploy para que no se haga el proceso de deploy, solo haga el commit release y haga el tag subiendo los cambios a la rama donde se esté ejecutando

Al realizar el release no se soporta bien el uso del scope

Al usar el siguiente título en el pull request no se toma bien el scope al generar el changelog

feat(product-card): ✨ update layout to show pickup point data

Change the order of the CHANGELOGRELEASETYPE parameter in the release command

Se plantea cambiar el orden del parametroCHANGELOGRELEASETYPE en el comando release, ponerlo antes de TAGNAME ya que este es opcional y si no se pasa TAGNAME se toma por defecto beta y así no se tiene que pasar cuando realmente se tiene que usar CHANGELOGRELEASETYPE