-
-
Notifications
You must be signed in to change notification settings - Fork 511
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
Changes in 13.5.3 break ability for plugins to provide custom changelog prior to version selection #647
Comments
Note: I've worked around the issue in release-it-plugins/lerna-changelog#38, but this basically feels like a race condition scenario to me and I'd love to come up with a better solution. |
Oh no, my apologies. I've always wanted to have better tests for plugins. I totally agree it's brittle right now, and this clearly shows it. I'll think about a more robust test suite wrt plugins here. For now, how about this:
Userland plugins come first, so all plugins will use the changelog from the plugin. I made a release you can install using |
Ya, I like the |
Not sure what happened, yesterday I released v13.5.5 with this change, but my comment here got lost. But here it is, so I'm going to close this issue. Let me know if you encounter any issues. |
Thank you very much @webpro! |
Prior to the changes in 6d6f59b a plugin could
this.setContext({ changelog: 'foo' })
and have that changelog be used for the initial prompting of next version. This does not seem to be possible any longer as of 13.5.3+.6d6f59b refactors the way that the initial changelog is retrieved, from:
release-it/lib/tasks.js
Line 74 in a0a2a5c
And now in 13.5.3+ it is always retrieved from the global context:
release-it/lib/tasks.js
Line 69 in dda4465
As a result this has broken a feature that I added to release-it-lerna-changelog in release-it-plugins/lerna-changelog#12.
Suggestions on a path forward?
The text was updated successfully, but these errors were encountered: