Nx Release support for projects without package.json files

[ctrlmaniac]

Current Behavior

nx release fails when package.json is missing in projects

Expected Behavior

nx release to run even without a package.json or to use the package.json inside the dist folder

GitHub Repo

No response

Steps to Reproduce

1. nx g @nx/node:app api
2. nx release --dry-run

Nx Report

Node   : 20.11.1
OS     : linux-x64
npm    : 10.2.4

nx (global)        : 18.0.8
nx                 : 18.0.7
@nx/js             : 18.0.7
@nx/jest           : 18.0.7
@nx/linter         : 18.0.7
@nx/eslint         : 18.0.7
@nx/workspace      : 18.0.7
@nx/devkit         : 18.0.7
@nx/eslint-plugin  : 18.0.7
@nx/express        : 18.0.7
@nx/node           : 18.0.7
@nx/plugin         : 18.0.7
@nx/react          : 18.0.7
@nrwl/tao          : 18.0.7
@nx/vite           : 18.0.7
@nx/web            : 18.0.7
@nx/webpack        : 18.0.7
typescript         : 5.3.3

Failure Logs

NX   The project "api" does not have a package.json available at apps/api/package.json.

To fix this you will either need to add a package.json file at that location, or configure "release" within your nx.json to exclude "api" from the current release group, or amend the packageRoot configuration to point to where the package.json should be.

Package Manager Version

No response

Operating System

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

Additional Information

No response

[FrozenPandaz]

Could you please provide a reproduction of this issue so we can see more about what you are trying to do?

If you want to publish your node api to NPM, then you'll need a package.json.

But it seems more like you want to deploy your Node API to be hosted somewhere.

[ctrlmaniac]

Yes indeed! I need to deploy my application. It needs to be hosted on a VPS. I've found it to be a little tricky! Firstly I can't release it because it's not a js library, secondly I needed to manually create a package.json file inside the src, then the build target will pick it and add the dependencies manually. In this way the application can be deployed

[mpsanchis]

Hi @FrozenPandaz

I ran into the same issue when using Nx in a polyglot repo. I posted in discord but had no answers.

Let me copy here the core of the question:

1. The @nx/js:release-version generator travels the Nx tree and expects package.jsons to be in certain places. This is not always true for polyglot repos, and it crashes in mine. I don’t get why it would need to read a package.json when I am using conventional commits (and therefore the version resolver is “git-tag”). I see that there are fallback options reading to disk, but this is not always the case, and limits the options.

2. The generator doesn’t only calculate a version, but it also attempts to modify the package.json. I checked the code and it doesn’t seem to provide an option to skip this. Neither does its schema.

Regarding 2: have you thought of decoupling the following?
a. Version calculation: when using conventional commits, only access to the git tree (and potentially the Nx graph) is needed
b. Actions to take with the version: updating package.json/cargo.toml/pom.xml/etc., pushing package to registry, generating changelog, writing the version to some .env file in disk, etc.

I guess I could write a generator myself and pass it in the nx.json in release.version.generator, but this means not taking advantage of your whole codebase. I was hoping to migrate from @jscutlery/semver to your native Nx solution, but I see no option right now.

Is there I way I can use your code without rewriting all the version calculation myself?

Thank you!

[fahslaj]

Hi @ctrlmaniac and @mpsanchis, the release version generator is currently designed to manage versions of npm packages, which require a package.json file. You're right in that in the context of deploying applications, much less should be required. Applications don't need to use the semver pattern for versioning, don't need a package.json file, and many version generator options wouldn't be relevant. I believe the best way to support this type of application deployment would be through a different version generator implementation.

While it's currently possible to replace the version generator, we recognize that it's difficult because of the sheer amount of functionality in the existing @nx/js:release-version implementation. We've got plans to extract utility functions and export them from Nx directly to make writing your own version generators easier, but we're just not quite there yet.

We appreciate your input. I'm going to convert this to a feature so that it can be prioritized accordingly.

[mpsanchis]

Hi @fahslaj
I'm going to try to extract out all your version calculation logic into a new generator that only calculates versions and assumes conventional commits, just to play with it a bit and try to have something working 😄

In case you guys discuss this internally:

extracting utility functions and exporting them from Nx directly to make writing your own version generators easier

is not enough in my opinion.

In a polyglot release group, say with JS and Rust, the JS applications will be versioned with @nx/js:release-version, and the Rust apps will be versioned with @monodon/rust:release-version. They do not exchange information, and version is calculated twice.
In a scenario where I modify only JS apps but I want to release the whole group (i.e., also the rust libs, because they are all sync'd), the Rust version calculator won't see any "relevant commits" and will return the same version as current. This results in JS and Rust apps being out of sync.

If you are open to re-considering the way nx release works, I would either:
(1.) edit the default version calculator so that the core is universal, but the manifest-file-specific functions (for package.json, Cargo.toml, setup.py, pom.xml...) can be passed-in as plugins somehow. I know, this requires modifying the API quite a bit...
(2.) provide a way for generators to share information about a version being calculated, if they belong to the same release group

Maybe I'm the only one considering polyglot release groups... In any case, I hope these ideas were useful to start a conversation in Nx. 🚀