[Bug] Target Default dependsOn Not Work for nx-release-publish

[Char2sGu]

Current Behavior

Every package in my project needs to be built to produce the assets for publishing. Therefore, it is a required step to build the package before each nx-release-publish execution.

However, I find that specifying the default dependsOn of the nx-release-publish target does not take effect:

nx.json

"nx-release-publish": {
  "dependsOn": ["build"],
  "options": {
    "packageRoot": "{projectRoot}/dist"
  }
}

By "does not take effect", I mean:

1. The build target is not executed either when executing the nx-release-publish target directly or when executing through nx release.
2. When inspecting the project configuration via Nx Console, the Depends On tab for nx-release-publish has only ^nx-release-publish

Expected Behavior

dependsOn should take effect on nx-release-publish.

GitHub Repo

https://github.com/Char2sGu/reproduction-nx-release-publish-dependsOn

Steps to Reproduce

This repository is a fork of the official NPM Workspace Sample Project: https://github.com/nrwl/tuskydesign.git

1. Try nx release, and you'll find the build target not executed despite of being specified in targetDefaults
2. Inspect the project configurations through Nx Console, and you'll find the default dependsOn is not respected.

Nx Report

Node   : 18.19.0
OS     : linux-x64
npm    : 10.2.3

nx (global)    : 18.1.1
nx             : 18.1.1
@nx/js         : 18.2.3
@nx/workspace  : 18.2.3
@nx/devkit     : 18.2.3
@nrwl/tao      : 18.1.1
typescript     : 4.9.5
---------------------------------------
The following packages should match the installed version of nx
  - @nx/js@18.2.3
  - @nrwl/js@18.2.3
  - @nx/workspace@18.2.3
  - @nrwl/workspace@18.2.3
  - @nx/devkit@18.2.3
  - @nrwl/devkit@18.2.3

To fix this, run `nx migrate nx@18.2.3`

Failure Logs

No response

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[JamesHenry]

Hi @Char2sGu, the intended way to run some logic before a release is to leverage the release.version.preVersionCommand config:

e.g. you might want something like the following in your nx.json:

If you were to run a target only before the publishing step, then it would potentially overwrite what had already been done in the versioning and/or changelog generation steps which would could cause issues.

By having this be a full command (instead of just a target name for example), it also allows you maximum flexibility to modify things however you need to in a specific way for releases.

We'll get a dedicated guide up on the website for preVersionCommand but hope that helps for now

[Char2sGu]

Sounds good. Thanks!

[praxxis]

@JamesHenry based on this issue and #21855 I don't understand where the paved road is for releasing projects with a build step. Using preVersionCommand to run the build is going to build the files before the package.json is bumped with the new version, which now means it's out of sync. Using dependsOn for nx-release-publish would logically run the build after the version bump, so the built output would be in sync with what has been committed go git, but that doesn't work.

Is there a different way to achieve this workflow that I'm not seeing? Maybe running nx release version and nx release publish as two separate commands?

[Char2sGu]

I didn't try preVersionCommand. Yeah then problem is still not solved...

[JamesHenry]

@praxxis We usually use the changelog step to commit the files, not the version step, so don't encounter issues like you are saying with being "out of sync", is this an option for you as well?

One really important point though - Nx intentionally has a programmatic API as a first class use case:

https://nx.dev/features/manage-releases#using-the-programmatic-api-for-nx-release

You can compose together the logic of nx release however you wish by leveraging it. You can run your build or whatever other tasks you want before or after any of the steps of nx release.

[dielsalder]

I don't think this problem has been solved. I want to achieve the workflow that @praxxis mentions:

1. Version and update package number
2. Generate changelog
3. Commit changelog and new package.json
4. Build
5. Publish the build

The build must happen after the commit because otherwise the package number will be out of date. Is writing a custom release script really the only way to do this?

[praxxis]

We did indeed end up writing a custom script to accomplish our workflow, based heavily on the one in
#21855 (comment)

edit: just wanted to say @JamesHenry the programmatic API was really easy to work with and I appreciate having it available from the start while everyone shakes our their use cases for nx release <3

[dielsalder]

Thanks @praxxis, that's super helpful! nx release has been a great tool and this is probably the only big challenge I've run into.

Bit of a dumb question but I can't figure out how to install the nx/release package referenced in your script -- do the docs need to be updated?

[praxxis]

I'm not the original author but you should be able to use those imports with a recent version of Nx, we're running 17.3

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.