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(esm): convert to esm (#2569) #2607
Conversation
for #2543 BREAKING CHANGE: semantic-release is now ESM-only. since it is used through its own executable, the impact on consuming projects should be minimal BREAKING CHANGE: references to plugin files in configs need to include the file extension because of executing in an ESM context
which deduped env-ci to the esm-only version, allowing test double to stub properly
Reminder that this is a release branch, so we should not squash when merging into the mainline |
looks like the commit for the node version minimum lost the BREAKING CHANGE token, so we'll want to make sure we note that in the release notes when we promote to stable |
since we get lots of questions about unsupported project structures or workflows, i think it could be worth considering documenting these as unsupported more clearly and maybe call them out as "breaking changes". these wouldnt actually change what is supported, but would give something more clear to point to for those types of requests. unsupported:
supported:
encourage:
is this going too far to include as part of this release? |
…HUB_ACTIONS` variable from the test env
…n the ci environment
…flicts in the ci environment" This reverts commit 71f45f9.
we decided to consider this and the potential raising of the minimum git requirement after promoting the changes from this PR, so those could be considered for a future breaking change rather than the current one |
If possible it would be nice for users to be able to run this on maintenance + LTS versions (Node 14, 16 and 18). Adoption of latest LTS generally takes a while and CI systems also lag behind in docs/images, e.g.:
|
appreciate the feedback, @hongaar. however, reducing the supported node versions helps the maintenance team significantly and is in line with our node support policy. most CI services enable releasing with a different version of node than is used for the rest of the pipeline, which we outline here. if the options outlined there are not possible, our recommendation is to simply continue using the previous version since it has been stable for some time. |
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.
Let's gooooo
After discussion, we've decided to wait until after the holidays to promote this to stable/latest so we don't surprise consumers with the breaking changes during the holidays. |
🎉 This PR is included in version 20.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
for #2543
remaining tasks:
two tests remain:
*
one intest/index.test.js
related to plugin name using a string*
one intest/integration.test.js
that might be just related to a change in output from aggregate-error, which was upgradedenv-ci
to latest: promote the beta release to latest env-ci#248overrides
definition inpackage.json
- [ ] consider if any plugins that are direct dependencies can/should also be converted to esm (not a requirement, but an option if it makes sense to do while we are waiting to verify enough real usage)- [ ] should we raise the minimum required version of git? (search issues for features that might be motivating for this)