Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 of 4 tasks
mpsanchis opened this issue May 16, 2024 · 6 comments
Closed
1 of 4 tasks

Comments

@mpsanchis
Copy link
Contributor

mpsanchis commented May 16, 2024

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
Copy link
Collaborator

JamesHenry commented Jun 10, 2024

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 JamesHenry closed this as not planned Won't fix, can't repro, duplicate, stale Jun 10, 2024
@JamesHenry
Copy link
Collaborator

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants