Gradle
We are using the plugin gradle-nx-plugin
This plugin allows us to run gradle tasks from the nx workspace and adds projects to the nx graph command to visualize the dependencies between projects.
It automatically provides gradle tasks for each project in the workspace.
nx run smispi:test is equivalent to ./gradlew :libs:smispi:test and recognized by default.
TIP
We can override the task in the {projectRoot}/project.json file like this:
{
"name": "smispi",
"$schema": "../../node_modules/nx/schemas/project-schema.json",
"root": "libs/smispi",
"projectType": "library",
"targets": {
"test": {
"executor": "nx:run-commands",
"options": {
"command": "./gradlew :libs:smispi:anotherTask"
}
}
}
}WARNING
Possible bug or wrong implementation?
A fix task is provided for all subprojects running spotlessApply. This is not available directly when running nx run smispi:fix.
The tasks created in the root build.gradle (applied from tasks.settings.gradle) are not recognized directly.
This means the fix task must be provided in the project.json file of each project meant to use it like this:
{
"name": "smispi",
"$schema": "../../node_modules/nx/schemas/project-schema.json",
"root": "libs/smispi",
"projectType": "library",
"targets": {
"fix": {
"executor": "nx:run-commands",
"options": {
"command": "./gradlew :libs:smispi:fix"
}
},
}
}Shared libraries
All dependencies and their versions are kept in a single toml file under {root}/gradle/libs.version.toml.
This is a default feature.
It allows us to create bundles of dependencies, "packaging" them to be used for subprojects.
Shared configs
All configs are applied from the root build.gradle file.
The main purposes are to avoid repetition, keep the configuration in one place for control, keep subprojects configs lean.
Tasks name conventions
All tasks should be standardized across all subprojects to follow nx (preferrable default task names) idiomatic conventions.
This is to allow running common tasks across all the projects in the repo like nx run-many -t lint.
For example, every project could expose those commands:
lintfixtestbuildservedeploycleanpublishreleasedocse2ecoveragevuln
Those tasks could be customized to fit the project needs.