package rename changelog validation

[kanthesha]

In the current released version, if we rename the package and would like to preserve the changelog, validation is failing for the format. Which is expected as package name doesn't match.

These changes will help to preserve the old package release/tag history and also works fine with new package release/s when we run the validation.
It addresses

1. Changelog validation working fine for the old package name in the entries and also for the new package release entries
2. An option to configure Old Tag Prefix and Old Package Version

original tag prefix and original latest version can be configured in package.json

"autoChangelog": {
    "packageRename": {
      "originalLastestVersion": "5.0.1",
      "originalTagPrefix": "json-rpc-middleware-stream@"
    }
  },

[MajorLift]

Looks good overall, especially with how quickly you got this to work!

Maybe you could add a barebones test case in changelog.test.ts with a mock renamed package to ensure that stringifyLinkReferenceDefinitions doesn't break in the future?

[mcmire]

I wonder if using a config file is the right way to go here? I've left some comments below.

[MajorLift]

Consistent typing for optional properties.

Suggested change

	readonly #versionBeforePkgRename: string | undefined;
	readonly #tagPrefixBeforePkgRename: string | undefined;
	readonly #versionBeforePkgRename?: string;
	readonly #tagPrefixBeforePkgRename?: string;

[mcmire]

An optional property and a property that can be undefined isn't the same thing in TypeScript. An optional property may or may not be set, but it looks like we do set this property in the constructor — it just might be undefined. So this one seems right to me, but does that make sense to you?

[MajorLift]

Yes, I like | undefined better than ?: here, since undefined is explicitly being passed in with these two variables, and not making them optional will prevent the code from breaking if exactOptionalPropertyTypes is turned on.

My concern is around consistent typing for the other properties in these files that are defined as optional. exactOptionalPropertyTypes would enforce that consistency.

[MajorLift]

Consistent typing for optional values. With exactOptionalPropertyTypes disabled, the | undefined is redundant.

Suggested change

	versionBeforePkgRename?: string | undefined;
	tagPrefixBeforePkgRename?: string | undefined;
	versionBeforePkgRename?: string;
	tagPrefixBeforePkgRename?: string;

[kanthesha]

@MajorLift I see you have added [] inconsistently around the params and few other changes in couple of places, which are not related to this PR! And if required, it can stay separate, which can be independently reviewed.

[MajorLift]

Yes, [] is the JSDoc syntax for optional params (https://jsdoc.app/tags-param.html#optional-parameters-and-default-values). They could replace the "An optional, which is required only..." comments although I didn't remove those.

The fixes adding [] were cluttering up the feed and there's no variation between them so I thought I'd consolidate them into a single commit.

[mcmire]

Sorry for the delay in reviewing. As you can see I left a lot of comments. Try not to be overwhelmed 😅 I think as a whole this implementation makes sense. A lot of the comments are minor.

[mcmire]

I have another suggestion for how we can make the code match the intended usage.

[mcmire]

I have one more suggestion around removing the brackets for the optional arguments, but this otherwise looks good to me.

[mcmire]

Looks good to me!