You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Though the "getting started" page of the nx release docs mention configuring projects for release, there is no mention of how (if at all) the utility is supposed to interact with repos using a Single Version Policy.
If there is a way to configure nx release to auto-increment the version of the package.json in the workspace root, that would be great information to have -- if not, it would be useful to have that lack of functionality and/or intent called out in the docs, to prevent users using this pattern from trying to implement a solution that will not work for their use cases.
The text was updated successfully, but these errors were encountered:
Hi @gregorholzmann, I would recommend not having a version in your root package.json and simply using "private": true. This makes it crystal clear that there is no publishable/consumable project at the root of the workspace. Having a version at the root would at best imply that your packages are all versioned together, but it would never be a source of truth for it, so it's not an approach that we will document or build into nx release natively
With that said, if you want to implement this for yourself it would be very straightforward. One of the powerful things about nx release is its first-class programmatic API.
Documentation issue
Is there a specific documentation page you are reporting?
https://nx.dev/recipes/nx-release/get-started-with-nx-release
Additional context or description
Though the "getting started" page of the
nx release
docs mention configuring projects for release, there is no mention of how (if at all) the utility is supposed to interact with repos using a Single Version Policy.If there is a way to configure
nx release
to auto-increment the version of thepackage.json
in the workspace root, that would be great information to have -- if not, it would be useful to have that lack of functionality and/or intent called out in the docs, to prevent users using this pattern from trying to implement a solution that will not work for their use cases.The text was updated successfully, but these errors were encountered: