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
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
Create a small nx repo
Add a release configuration at the root as mentioned in "current behavior"
Add a project that is not Javascript
Run nx release version ... and observe the projects that are filtered in nx/src/command-line/release/config/config.ts
🙏 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
The text was updated successfully, but these errors were encountered:
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):
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
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
Current Behavior
Defining
projectRelationship
asindependent
for all the projects, but not defining release groups:leads to a
__default__
releaseGroup that does not contain projects without apackage.json
. This releaseGroup is then passed tomy-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
andprojects
myrelease-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 mentionspackage.json
, which is JS/TS specific.GitHub Repo
No response
Steps to Reproduce
release
configuration at the root as mentioned in "current behavior"nx release version ...
and observe the projects that are filtered innx/src/command-line/release/config/config.ts
Nx Report
Failure Logs
No response
Package Manager Version
pnpm 8.10.0
Operating System
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
The text was updated successfully, but these errors were encountered: