BREAKING CHANGE
In Nx v19, implementing a custom changelog renderer would involve a lot
of work on the user side. They would need to create an additional
function making every property available in its declaration and then
call the underlying default one and customize the final string (or
reimplement the whole thing).
E.g.
```js
const changelogRenderer = async ({
projectGraph,
commits,
releaseVersion,
project,
entryWhenNoChanges,
changelogRenderOptions,
repoSlug,
conventionalCommitsConfig,
changes,
}) => {
const defaultChangelog = await defaultChangelogRenderer({
projectGraph,
commits,
releaseVersion,
project,
entryWhenNoChanges,
changelogRenderOptions,
repoSlug,
conventionalCommitsConfig,
changes,
});
// ...Do custom stuff and return final string...
};
module.exports = changelogRenderer;
```
In Nx v20, changelog renderer are classes. The DefaultChangelogRenderer
can therefore easily and granularly be extended and customized, and the
config does not need to be redeclared on the user side at all. We will
improve things even further in this area, but this breaking change is an
important stepping stone.
E.g. for manipulating the final string equivalent to the previous
example:
```js
module.exports = class CustomChangelogRenderer extends (
DefaultChangelogRenderer
) {
async render() {
const defaultChangelogEntry = await super.render();
// ...Do custom stuff and return final string...
}
};
```
E.g. for customizing just how titles get rendered:
```js
class CustomChangelogRenderer extends DefaultChangelogRenderer {
renderVersionTitle(): string {
return 'Custom Version Title';
}
}
```
BREAKING CHANGE
In Nx v19, `release.version.generatorOptions.updateDependents` is
"never" by default, meaning dependents are not automatically patched
when their dependencies change (applicable to independent projects).
In Nx v20, `release.version.generatorOptions.updateDependents` is "auto"
by default, meaning dependents are automatically patched when their
dependencies change (applicable to independent projects).
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
<!-- This is the behavior we have today -->
Snapshot tests are failing.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Snapshot tests are fixed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
<!-- This is the behavior we have today -->
When releasing projects independently, if a dependent project is
untouched directly by the changes, it will not have its version updated
and there is no way to opt into this behavior.
Additionally, circular dependencies between packages are not supported.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When releasing projects independently, if a dependent project is
untouched directly by the changes, **BY DEFAULT** it will not have its
version updated, **BUT** you can opt into it always being updated via a
generator option (`release.version.generatorOptions.updateDependents =
auto` and you can control what kind of semver bump should be applied to
the otherwise unchanged dependent project. Transitive local dependents
(`A -> B -> C`) will also be updated in this scenario.
Additionally, when opted into, such version only changes will appear in
the changelog under a new `Updated Dependencies` section.
Circular dependencies between packages are now supported for versioning,
changelog generation and publishing.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22268
