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` -->
<!-- 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 -->
When using version plans as a versioning strategy with `nx release`,
there is no way to enforce that version plan files are created when
changing files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a new `nx release plan:check` subcommand, intended to be run in
CI (and/or potentially a git hook) which will return with exit code 1 if
touched projects are not represented in at least one version plan file
on disk.
What constitutes a touched file is shared with our `affected` logic in
other commands, with the additionally capability to be able to ignore
file patterns from consideration. This would be useful for not requiring
version plans when only documentation or spec files change, for example.
## 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` -->
<!-- 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 -->
This repo uses Nx `19.4.0-rc.1`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `19.5.0-beta.5`
## 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 -->
## 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 #
<!-- 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 -->
Lifecycle scripts related to publishing change the output of `npm
publish`, which mixes JSON with non-JSON content despite the `--json`
flag being set. Currently, we will error when attempting to parse the
whole thing as JSON.
The lifecycle scripts contents themselves are not shown to the user.
Additionally, during dry-run we have no choice but to print the version
that currently exists on disk, which can be confusing.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We extract and parse the JSON from the `npm publish` output, even when
it is mixed with other output. We also show the lifecycle script outputs
to the user, where applicable.
During dry-run, we replace the version in the publish output with a
placeholder to avoid confusion around what would be published.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/22925
<!-- 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
