Some time ago, I saw Slate’s update log for managing the base library with Changesets and thought it was a good idea. Considering some of the drawbacks we have with standard-version, I decided to look into how it works to see if it would solve my current problems.

The preliminary test found that the demand matching degree is very high, the operation process is clear, and there is no black box processing.

Changesets is introduced

Simply put, it is a tool for generating Changelog.

Official: Changesets is a tool for managing version and change logs, focusing on multi-package management.

How did you do that?

The generated Changelog follows the semantic version 2.0.0. The specific approach is to first generate changeset files based on your code changes, and then merge these Changeset files, change the version number, and generate Changelog.

How to use it?

Installing dependent libraries

DevDependencies: {"@changesets/changelog-github": "^0.3.0", "@changesets/cli": "^2.19.0"}Copy the code

Initial Configuration

npx changeset init
Copy the code

Manually Modifying configurations

{" $schema ":" https://unpkg.com/@changesets/[email protected]/schema.json ", "changelog" : ["@changesets/ Changelog-Github ", {"repo": "worktile/slate-angular" // change your Github repository}], "commit": false, "linked": [], "access": "public", "baseBranch": "master", "updateInternalDependencies": "patch", "ignore": [] }Copy the code

@changesets/ Changelog-Github is a plug-in that generates Changelog. If you do not modify this configuration, it will work, but the generated Changelog is not perfect!

Generate chanegset

1. Select a version type

2. Enter the update summary

3. Make sure to generate the Changeset file

4. Commit changes

5. Generate Changelog

npx changeset version
Copy the code

  1. Delete the Changeset file
  2. More semantic new version number
  3. Generate the changelog
    1. Contains the code submitter
    2. Links to commit
    3. Change the

other

To find the package. The json

Json was in the root directory of the project, while my base library code and package.json were in the packages directory. I expect that this tool can change the version number under packages/package.json together with me. Finally, I find that I need to configure workspace in package.json under the root directory, as shown in the figure below:

The main reason for the package configuration is that my project only has one library, so packages is directly under the source code. If multiple libraries have a secondary directory together, it can be configured as “Packages /*”.

Another problem with this is that I have to move my Changelog files to the Packages directory, which also shows that the core of Changesets is dealing with multi-package scenarios.

Configuration GITHUB_TOKEN

As mentioned in the previous screenshot, CHANGELOG needs to access your Github information, so you need to configure an environment variable here.

  1. Generate GITHUB_TOKEN (github.com/settings/to…)
  2. Configuring environment Variables

Adding a configuration record:

export GITHUB_TOKEN=your_token

A wrong

If you haven’t committed a commit yet, you can’t get the account address of the commit, so just push the local commit changes to Github.

Error 2

Note The GITHUB_TOKEN environment variable configuration does not take effect.

This can be temporarily generated using GITHUB_TOKEN=your_token NPX Changeset version.

More package management

Because my scene is not multi-package, the research is not very deep, but the feature of Changesets is multi-package support, I also looked at their source code warehouse github.com/changesets/… Is the multi-package management, it can distinguish the modified code in which package, prompt selection for that package to add update summary, very not black box.