Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(conventional-changelog-presets): supported new preset format #526

Merged
merged 8 commits into from
Sep 18, 2023
Merged

Conversation

travi
Copy link
Member

@travi travi commented Sep 1, 2023

BREAKING CHANGE: the new preset format is a breaking change when compared to the previous preset format. updating to support the new format means that the old preset format is no longer supported. update your preset to the latest version to maintain compatibility

BREAKING CHANGE: the new preset format is a breaking change when compared to the previous preset format. updating to support the new format means that the old preset format is no longer supported. update your preset to the latest version to maintain compatibility
@travi
Copy link
Member Author

travi commented Sep 1, 2023

4 unit tests are failing when comparing the transform function in writerOpts, but this should be otherwise functional

Comment on lines -35 to -40
loadedConfig = await (typeof loadedConfig === "function"
? isPlainObject(presetConfig)
? loadedConfig(presetConfig)
: promisify(loadedConfig)()
: loadedConfig);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since this took me a bit to understand, capturing the reason this is being removed. with the previous preset format, most presets returned an object, but the conventionalcommits preset returned a function that accepted config.

the change that resulted in the breaking changes across the conventional-changelog presets was an effort to unify the interface across those presets. therefore, we can instead pass the config above and remove the handling of the different potential return shapes. nice work @dangreen!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i figured this out after cutting the first beta of the commit-analyzer plugin, so will make this change there too soon

} else if (config) {
loadedConfig = importFrom.silent(__dirname, config) || importFrom(cwd, config);
loadedConfig = await (importFrom.silent(__dirname, config) || importFrom(cwd, config))();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should also accept the config, but we dont currently have a test for that case, so want to add those together

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the interest of getting the beta promoted, i'm ok with completing this detail after this is merged

} else {
loadedConfig = conventionalChangelogAngular;
loadedConfig = await conventionalChangelogAngular();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the angular config currently does not accept config, so i think it is ok to avoid passing the config here

@travi
Copy link
Member Author

travi commented Sep 1, 2023

similar to the pr for the commit-analyzer, this updates the conventional-changelog presets and adjusts loading to handle the new format.

conventional-changelog-writer has not yet been updated since it appears to not handle reverts the same way. if that is an expected change, i have not investigated far enough to understand what adjustment we need to make.

…ional-changelog expectations

based on conventional-changelog/conventional-changelog#1121 (comment). however, assuming the previous order actually aligned with how core provides the list, this will need to be coordinated with reversing that list somewhere
…opped v19 support

BREAKING CHANGE: the minimum required node version is now v18.17, v19 support has been dropped, and the minimum required in the v20 range is v20.6.1
@travi travi marked this pull request as ready for review September 17, 2023 04:36
@travi travi requested a review from a team September 17, 2023 04:36
@travi travi merged commit 2a2756e into master Sep 18, 2023
6 checks passed
@travi travi deleted the beta branch September 18, 2023 12:35
@github-actions
Copy link

🎉 This PR is included in version 12.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants