Projects without a package.json get excluded from "__default__" release group

[mpsanchis]

Current Behavior

Defining projectRelationship as independent for all the projects, but not defining release groups:

  "release": {
    "projectsRelationship": "independent",
    "version": {
      "generator": "@mpsanchis/my-plugin:release-version"
    }
  },

leads to a __default__ releaseGroup that does not contain projects without a package.json. This releaseGroup is then passed to my-plugin that doesn't see some projects.

Expected Behavior

Core Nx release functionalities should be language-agnostic. I understand that you added JS-specific information in @nx/js:release-version, but as discussed in #23389 I should at least be able to implement my own language-agnostic version calculator.

I expect that the releaseGroup and projects my release-version generator receives did not go through a whole lot of logic. This line in particular is very harmful, since it goes against Nx's philosophy. The core NX cli mentions package.json, which is JS/TS specific.

GitHub Repo

No response

Steps to Reproduce

1. Create a small nx repo
2. Add a release configuration at the root as mentioned in "current behavior"
3. Add a project that is not Javascript
4. Run nx release version ... and observe the projects that are filtered in nx/src/command-line/release/config/config.ts

Nx Report

Node   : 18.18.2
OS     : darwin-arm64
pnpm   : 8.10.0

nx                 : 18.3.3
@nx/js             : 18.3.3
@nx/jest           : 18.3.3
@nx/linter         : 18.3.3
@nx/eslint         : 18.3.3
@nx/workspace      : 18.3.3
@nx/devkit         : 18.3.3
@nx/eslint-plugin  : 18.3.3
@nx/playwright     : 18.3.3
@nx/plugin         : 18.3.3
@nx/react          : 18.3.3
@nrwl/tao          : 18.3.3
@nx/vite           : 18.3.3
@nx/web            : 18.3.3
typescript         : 5.4.2
---------------------------------------
Registered Plugins:
@jnxplus/nx-maven
...
---------------------------------------
Community plugins:
@jnxplus/nx-maven      : 0.42.1
@monodon/rust          : 1.4.0
@ngx/deploy-npm        : 7.1.0
@nx-go/nx-go           : 3.0.0
@nx-tools/nx-container : 5.2.0
---------------------------------------
Local workspace plugins:
         ...

Failure Logs

No response

Package Manager Version

pnpm 8.10.0

Operating System

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

Additional Information

🙏 please consider non-js projects when implementing core Nx functionalities. I am very happy with Nx overall, but sometimes I bump into these issues and they make it difficult to expand my monorepos

[JamesHenry]

Hi @mpsanchis, we support zero config for JS packages with nx release because it is such a popular use case. For non-JS packages a tiny amount of config is required, and only a single piece is missing from your current example.

As you can see in the file, this default public projects codepath will only kick in if you skip specifying what projects you care about (as you have done here).

You should only need the following to get exactly what you want for non-JS packages (and it is better to be more explicit about this anyway):

 "release": {
+   "projects": ["*"],
    "projectsRelationship": "independent",
    "version": {
      "generator": "@mpsanchis/my-plugin:release-version"
    }
  },

Of course feel free to pass one or more alternative project matching patterns into there instead of * if you don't want to match all projects. You can match by name, glob, directory, tag etc

Hope that helps!

[JamesHenry]

Out of interest, what non-JS ecosystem are you using Nx with? Is you work open source?

I'm excited that you are implementing a custom generator for this, now that it is maturing, we will be extracting a good amount of our native generator into utilities that can be reused by community ones because a lot of the logic is agnostic to a particular ecosystem.

Please feel free to open new issues if you run into problems

[robsonos]

Hi,

I am also interested in this. In my case I would like to use nx release in a C++ lib monorepo. Do I need to create my onw generator?

Cheers

[mpsanchis]

Hi @JamesHenry

Unfortunately, the main repo I contribute to is not open source. I'd need to go through a lot of regulations to see what I could do about that 😞 .
However, what I can tell you is that after using Nx for a year and a half, we have integrated Typescript, Java (Maven) and Go. We also have almost 20 in-house Nx plugins, with generators, executors, migrators, and since some weeks we're crystallizing them. The plan is to include Python and .Net projects in the future.
I think I could be able to convince my management to let us present if there was some event (nx conference, or some collaborator talks) where we could show our use case. It might be interesting for everybody. Let me know what you think about it!

This polyglot use case is the reason why I have been so annoying with these issues (and now my first PR 🎉 ). After adding crystal, a next important simplification step is to get rid of @jscutlery/semver, since we had a complex setup to make it work with release groups. We even started a draft (see RFC) with the jscutlery people, but we ended up working on other things. Also with this topic: let me know if we could collaborate somehow on the versioning topic. I could show you guys a general "requirements list" that we're collecting for the versioning target.

If you guys have time, I'd be up for a videocall to discuss the aforementioned points.

[mpsanchis]

Since I'm here, @robsonos I can tell you already: the short answer is yes. Take a look at the conversation we had in #23389, and also at the source code of @nx/js:release-version (which is the default version calculator). That is why they had to "repeat" code in the rust plugin, so that they could version the rust code. For now the alternatives are @jscutlery/semver (which has a ton of flags, but works well in most cases), or re-writing your version calculator.

[JamesHenry]

@mpsanchis Yes it would be useful to cover your polyglot repo in more detail please, do you use twitter/X? If so you could please DM me on there https://x.com/MrJamesHenry

[robsonos]

Hi @mpsanchis. Thanks for your reply. @jscutlery/semver would require me to have a package.json. I use Nx in a few othe JS projects and would love to have the relase/versioning part of it in my non-JS monorepo project. I believe my best course of action at the moment is to create a GH action for Nx that can install plugins as it goes, and then create a non-JS release/versioning plugin (or use what you suggested) on it.

[mpsanchis]

Hi @robsonos
I didn't remember @jscutlery/semver bumped the package.json. I forked it some time ago, because the maintainers did not want to include some features I needed. However, have you tried to use it anyways? It seems that the bumping function won't crash if the package.json is not there (see code here and here).
Wish you luck with your projects 😄

[mpsanchis]

Hi @JamesHenry
I didn't have X, but I took the chance to create an account 😄 I'm @mpsanchis there as well. Could you follow back so that I can message?
Thanks!

[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.