node-workspaces plugin creates inconsistent changelog and release name

[sir-captainmorgan21]

1. Is this a client library issue or a product issue?
   Library issue

2. Did someone already solve this?
   I could not find anything

3. Do you have a support contract?
   No

Issue

Hi. We are using the node-workspace plugin. When using it, however, the resulting changelog and release name is inconsistent with release-please's normal output. Below is a screen shot of the output. The form-field package was modified in this instance. It received the normal output with (has a version number heading, and is not prefixed with @snagajob/. The input package relies on the form-field package, so it was added by the node-workespace plugin. You can see the output is different. We'd like or release naming conventions and changelog output to remain consistent.

Environment details

• OS: MacOS Monteray v12.4
• Node.js version: 16.15.0
• npm version: 8.5.5
• release-please version: 13.18.5

Steps to reproduce

1. Create two separate node packages where package A has package B listed as a dependency
2. Configure the release-please config to use the node-workspaces plugin
3. Make a change to package B and commit/push with feat: blah blah
4. Run release-please -- release-pr to create the release PR

Thanks!

[vizio360]

Just experienced this one myself. It seems that packages that are updated because one of their dependency has changed, miss out the header of the change in the changelog.

In the example above the header should be 3.0.2 (2022-07-19)

[michael-land]

also related to #1581

[vizio360]

I think the issue is in the newCandidate method of the NodeWorkspace class in node-workspace.ts, see comments in code below.

const pullRequest: ReleasePullRequest = {
      title: PullRequestTitle.ofTargetBranch(this.targetBranch),
      body: new PullRequestBody([
        {
          component: updatedPackage.name,
          version,
          notes: appendDependenciesSectionToChangelog(
            '',  // <------- HERE
            dependencyNotes,
            this.logger
          ),
        },
      ]),
      updates: [
        {
          path: addPath(updatedPackage.location, 'package.json'),
          createIfMissing: false,
          updater: new RawContent(
            jsonStringify(packageJson, updatedPackage.rawContent)
          ),
        },
        {
          path: addPath(updatedPackage.location, 'CHANGELOG.md'),
          createIfMissing: false,
          updater: new Changelog({
            version,
            changelogEntry: appendDependenciesSectionToChangelog(
              '',  // <------- AND HERE
              dependencyNotes,
              this.logger
            ),
          }),
        },
      ],
      labels: [],
      headRefName: BranchName.ofTargetBranch(this.targetBranch).toString(),
      version,
      draft: false,
    };

the appendDependenciesSectionToChangelog function does the correct thing, but the problem is that it is passed '' as the first parameter which should instead be populated with the 3.0.2 (2022-07-19) header.

function appendDependenciesSectionToChangelog(changelog, notes, logger = logger_1.logger) {
    if (!changelog) { // <---- this is empty so it just adds the header on the line below
        return `### Dependencies\n\n${notes}`;
    }

@chingor13, I tried to create the release notes for the dependencies on the fly by using the buildReleaseNotes method of the Base.ts class (the base class for the strategy), but (rightly so) the NodeWorkspace class has no reference/knowledge of that.

Happy to help but not completely sure where to look for a fix for this. Do we need to somehow compute the release notes for the packages that are just versioned bumped before hand? and then pass those release notes in the newCandidate method?

[vizio360]

Any updates on this one? We are a bit stuck as we cannot use release please until this has been fixed or all our Changelogs will be messed up.

[vizio360]

@chingor13 any chance of this getting fixed? As mentioned above, I will be happy to contribute I just need a bit of guidance.

[chrispcampbell]

This issue may have been resolved by PR #2112 (released in 16.6.0), though I haven't been able to confirm. More details in the similar issue that I filed in #2089.

[chrispcampbell]

I confirmed that this issue has been resolved in 16.6.0, see related comment in #2089, which I just closed as fixed.

@sir-captainmorgan21 @vizio360 @chingor13: Once you verify the above, I think this issue can be closed as well.

[vizio360]

@chrispcampbell yes this seems to be fixed now, at least based on my tests