iamchathu / changeset-conventional-commits Goto Github PK

There seems to be a bug in the code that is not picking up commits with multiple lines.
When I run the git command used to describe the commit, I do not get an error, but the body is ignored as implied by the formatting function (%s only containing the subject).

Impact

Crucial information may be missing from changelogs, including but not limited to message body and footers (possibly containing ticket refs and information about breaking changes).

Current behavior

Given a commit message with a body matching the convetional commit spec
WHEN I run changeset-conventional
THEN an error is logged: fatal: No tags can describe 'sha1'.
THEN the change is not added as changeset

Expected behavior

Given a commit message with a body matching the convetional commit spec
WHEN I run changeset-conventional
THEN the change is added as changeset

How to reproduce

Add a commit message as allowed by the conventional commit spec.

Add a commit to your repo with the following content:

feat(scope): a commit subject

Add a body paragraph to explain the change.

Follow by a second paragraph as allowed by the conventional
commit spec.

Refs: #123

Possible fix

Replace %s token in the git pretty format with %B to retrieve the unwrapped message body instead of the message subject.

when I tried to run npx changeset-conventional-commits
it does nothing there

I'm not sure if I'm doing this correctly. I'm using npm running npx changeset-conventional does nothing really.

Overview

• Real Repo(s) Based Tests
• Replace git calls by NodeGit - probably not (possible install horror) - maybe optional some day...
• Replace execSync by Execa
• Optimize git calls - get data in one go
• Use Effect - The "Glue of God"
• Better CLI Tooling
• Changelog Writer for Changesets
• Inline Changelog Generation
• Root Changesets
• Clean Git Fetch Output
• Enhanced Documentation/README
• Better Detection of Commits of Branch
• Many Options/Flags
• Show Covered Packages Within List of New Changesets
• Show Filenames of Generated Changesets
• Configurable Commit Types
• Own Config File
• Go by Changesets' Config for Private Packages
• Recognize Changesets' Config
• Output Extensive Info/Logging

Details

• Better CLI Tooling

  Like Nuxi uses Citty and Consola › Clack.

• Changelog Writer for Changesets

  Own changelog writer package for Changesets to support our features like associating changesets by hash.

  "changelog": ["changeset-conventional-commits-changelog-writer", { "repo": "iamchathu/changeset-conventional-commits" }]
  

• Inline Changelog Generation

  Pretty "inline" changelog generation like Changelogen.

• Root Changesets

  Implement support for root changesets within Changesets.

  2023-04-18: Changesets for the monorepo root workspace (#1137))

Last updated on 2024-04-28 23:32

I'm looking at integrating this into the release flow for a new monorepo I'm working on.

I generated the changesets once locally, but then deleted them all (still working on the bugs of the workflow). But then when I run pnpm dlx changeset-conventional-commits again, I don't get anything generated...

Is this expected behavior? (Or maybe I'm doing something stupid?)

Hi 👋

First of all, let me thank you in advance for your for making this a public npm package.

My question is probably better suited to the pull request that served as the basis for this package. Nevertheless, is there a reason why this package purposely drops private packages?

In my use case, I have a set of private packages from which I'd like to generate a changeset based on the conventional commits pattern.

I'm not sure if this sneaked in by some updated external package(s), or if it really stayed undetected for so long, but it generates the same Changesets over and over again, because its duplicate detection fails on the still trailing line break \n it gets from git.

Imagine this example data it holds while duplicate checking.

const changesets = ...:

// Data from Commits
[
  {
    releases: [ [Object], [Object] ],
    summary: 'chore(root): add two test packages\n',
    packagesChanged: [ [Object], [Object] ]
  }
]

const currentChangesets = ...:

// Data from Changesets
[
  {
    releases: [ [Object], [Object] ],
    summary: 'chore(root): add two test packages',
    packagesChanged: [ [Object], [Object] ]
  }
]

The issue is here:

An added .replace(/\n$/, '') fixes it:

return a.summary.replace(/\n$/, '') === b.summary && JSON.stringify(a.releases) == JSON.stringify(b.releases);

MR/PR coming - one of at least a few, haha! 😻

Beside other ideas, I think there should likely be some --verbose flag option, that would be great.

E.g. while running first tests, I'd already a tag on the latest commit, so there were just no commits for it to process, but there was no feedback, so I put a bunch of console.log() into node_modules/changeset-conventional-commits/bin/index.js and saw that they all gave empty arrays, which made finding the issue (me and myself) quite easy! 🥳🎉

It also simplified resolving this issue of duplicate generation.

So, yeah, there'll be more MRs/PRs - because for me, Conventional Commits/Changelogs missing was a total deal breaker on Changesets at first, so this is a great addition to Changesets we should push forward - HARD! 😹💦

Hi, thanks for your great project.
While trying to set up changesets and conventional commits we discovered that there is one issue that may or may not be intentional that is breaking the changelog (for us).

When creating a PR with multiple comits we want to run changeset-conventional to create the changesets and add a comit to the PR. This works great, however, the only reference the changelogs have is the commit when the changesets have been added.

This means that if there is a PR that deals with multiple workspaces and dependency updates the log is not very helpful. The format used may drop essential information.

There are multiple options, depending on how far you want to go. I could also take a stab at implementing if you are willing to accept PRs. I have just briefly looked into the code and maybe this change is not necessary, given the has is already in the returned object. Basically we want to be able to generate a changelog like this:

[**scope**](link-to-repository?id=commitHash): feat: some message

The git command here could be updated to either be configurable or by default add all information to the changelog. This could open the tokens up to be used by a formatter - or simply return the message with the hash included (snas the regex magic) and use a changeset custom log format to do this.

const commitsWithMessages = commitsSinceBase.map((commitHash) => {
  const commitMessage = execSync(`git log -n 1 --pretty=format:%s\n\n%b ${commitHash}`)
  const [,type, scope, breaking, subject, body] = commitMessage.match(/([^(:]+)(?:\(([^)]+)\))?(!)?: (.+)(?:\n{2,}([\s\S]+))?/))
  return {
    commitData: { type, scope, breaking, subject, body },
    commitHash,
    commitMessage: 
  }
});

Let me know if I should elaborate more.

What do you think of pulling in Effect-TS (Git)?

Especially in our case of CLI apps, the now quite ready for prime-time Effect-CLI looks promising:

• The "(in)famous" in general "clean everything" of Effect,
• part of an already whole universe of niceties,
• replacing an otherwise hunch-load of partly even more or less rather legacy packages.

Checking the Example of ANSI Terminal Pretty Printer for Effect-TS, I'm already curious how well this Pretty Printer for Effect-TS works for our output - as in CLI output, but looking at it, yeah, maybe it's also an option for more - eying on the actual changeset/changelog generation.