-
Notifications
You must be signed in to change notification settings - Fork 26
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: ES Module #411
feat: ES Module #411
Conversation
Update the Node.js versions in the test workflow to include 20.8.1, 20, and 21. This ensures compatibility with different versions of Node.js during testing. Also, replace the deprecated "npm ci" command with "npm clean-install" to install dependencies. Additionally, add a step to run "npm audit signatures" to check for any security issues in the dependencies. Finally, include a step to scan the lockfile for security issues using "lockfile-lint".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great! thanks so much for taking this step!
just a few minor details that i spotted that i think could use tweaks, but excited to get this merged :)
Co-authored-by: Matt Travi <[email protected]>
…d `semantic-release`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
this seems ready to release as beta since i see that is the current target branch. how do we want to merge into the beta branch? i'm totally ok with using a normal merge if the current commits already capture the changes we want to communicate, especially the breaking changes. if the commits are not already in a state to tell that story, do we want to adjust the history of this branch before merging, or do we prefer squashing? if we squash, we will want to be careful to capture all of the breaking changes in the body of the squash commit |
I'll subscribe to modifying the commit message in a Squash to capture the 2 Breaking Changes for the merge. That way we are prime to just do a Merge Commit from This allows us treat changes merged to |
sorry if i've been holding this back from being merged, but i think i'd prefer you take care of the squashing, @babblebey, since you are more familiar with the commits you made and can make sure that the correct breaking changes are noted in the body of the squash commit. are you comfortable taking care of that step? |
This PR converts the plugin to ESM only.
Related to semantic-release/semantic-release#2133
BREAKING CHANGE:
@semantic-release/exec
is now a native ES Module. It has named exports for each plugin hook (verifyConditions, analyzeCommits, verifyRelease, generateNotes, prepare, publish, addChannel, success, fail)BREAKING CHANGE: the minimum required version of semantic-release to use
@semantic-release/exec
is now v24.1.0; thewarn
logger method/function is now available to use in pluginOther Changes Made
xo
withprettier
with default configuration; following newly established conventionnyc
withc8
for code coveragelodash
withlodash-es
for properesm
supportRelated Issues/PR
Closes #283
Closes #406
Closes #407
Screencast
screencast-github_com-2024_10_17-20_48_14.mp4