Open osuritz-grammarly opened 4 months ago
We are actually working on a file-based way to version packages.
@fahslaj would you like to give a sneak peek of what you are working on?
Hi @osuritz-grammarly, you're right that we've left the door open to other ways to determine versions! I'm happy to say that we're currently working on a feature that allows you to use Nx Release to accomplish what you've described above - versions & changelogs that are detached from commit history and conventional commits standards. It's currently still in development, but I will follow up with more information once it's available 😄
Sweet! ❤️
Out of curiosity, @fahslaj do you have a rough ETA for this feature? Nothing to hold you to, but more a ballpark so we can determine next steps for us internally, if any.
FYI This seems to be the feature mentioned above: https://github.com/nrwl/nx/pull/23190
This is quite cool, one of the remaining features of changesets is the GitHub action: https://github.com/changesets/action
This opens a pull request containing the results of the version command, and when that PR is merged, it will run the publish command instead of opening/updating the PR.
It would be good to either support adding this feature, or allowing changesets to be integrated somehow (as suggested above).
Description
Nx should support changesets as the source of semantic versioning information used to infer the next version number of a package when invoking
nx release [version]
. While conventional commits ships as an option today, it appears the implementors ofnx release
have purposely kept the door open to alternative ways of determining version numbers. Changesets is a fairly largely use option that depends on files being added to a repo's.changesets
directory to determine the next version number. It is similar, in spirit, to conventional commits but is divorced from the underlying source repository commit message format to do its job.Motivation
Using conventional commits as the source of versioning requires a big change in engineering culture for larger teams and may not be feasible. Using changesets brings another option to the table for teams that are already using changesets today —outside of Nx— as their versioning/changelog management system.
Suggested Implementation
To enable conventional commits, users update
nx.json
with the following section:Configuring the use of changesets would look something like:
When configured as such,
nx release
would invoke the changesets CLI or API calls such asapplyReleasePlan(...)
orgetReleasePlan(...)
Alternate Implementations
🤷