Refactor changelog parsing and generation#10847
Merged
Conversation
dcc953b to
50df31f
Compare
Collaborator
Builds ready [50df31f]
Page Load Metrics (656 ± 50 ms)
|
50df31f to
554d153
Compare
Collaborator
Builds ready [554d153]
Page Load Metrics (601 ± 69 ms)
|
The `auto-changelog.js` script has been refactoring into various different modules. This was done in preparation for migrating this to a separate repository, where it can be used in our libraries as well. Functionally this should act _mostly_ the same way, but there have been some changes. It was difficult to make this a pure refactor because of the strategy used to validate the changelog and ensure each addition remained valid. Instead of being updated in-place, the changelog is now parsed upfront and stored as a "Changelog" instance, which is a new class that was written to allow only valid changes. The new changelog is then stringified and completely overwrites the old one. The parsing had to be much more strict, as any unanticipated content would otherwise be erased unintentionally. This script now also normalizes the formatting of the changelog (though the individual change descriptions are still unformatted). The changelog stringification now accommodates non-linear releases as well. For example, you can now release v1.0.1 *after* v2.0.0, and it will be listed in chronological order while also correctly constructing the `compare` URLs for each release.
554d153 to
459b991
Compare
Collaborator
Builds ready [459b991]
Page Load Metrics (582 ± 39 ms)
|
brad-decker
approved these changes
Apr 8, 2021
Contributor
brad-decker
left a comment
There was a problem hiding this comment.
Output looks good for both baseline and --rc flag, code looks much cleaner and broken into fairly easy-to-digest pieces. LGTM 👍🏻 Especially like the amount of comments / docblocks to explain what each piece does.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
auto-changelog.jsscript has been refactoring into various different modules. This was done in preparation for migrating this to a separate repository, where it can be used in our libraries as well.Functionally this should act mostly the same way, but there have been some changes. It was difficult to make this a pure refactor because of the strategy used to validate the changelog and ensure each addition remained valid. Instead of being updated in-place, the changelog is now parsed upfront and stored as a "Changelog" instance, which is a new class that was written to allow only valid changes. The new changelog is then stringified and completely overwrites the old one.
The parsing had to be much more strict, as any unanticipated content would otherwise be erased unintentionally. This script now also normalizes the formatting of the changelog (though the individual change descriptions are still unformatted).
The changelog stringification now accommodates non-linear releases as well. For example, you can now release v1.0.1 after v2.0.0, and it will be listed in chronological order while also correctly constructing the
compareURLs for each release.Relates to #10752
Manual testing steps:
To update the changelog with unreleased changes:
yarn update-changelogTo update the changelog for a release candidate:
yarn update-changelog --rc