Project Crystal, Inferred Tasks, config duplication

[kekel87]

Hello,

I'm reaching out to start this discussion because I'm a bit lost with NX 18 and Project Crystal/Inferred Tasks.

We might have misunderstood something, but as a result, we're trying to consolidate redundant options for each project at the root level using plugins.

In each app/lib, we're forced to repeat eslint and jest configs to specify options (mainly cache):

apps/my-app/project.json

{
  ...
  "targets": {
    ...
    "lint": {
      "executor": "@nx/eslint:lint",
      "options": {
        "lintFilePatterns": ["{projectRoot}/**/*.{ts,html,json}"],
        "cache": true,
        "cacheLocation": ".cache/eslint",
        "cacheStrategy": "content"
      }
    },
    "test": {
      "executor": "@nx/jest:jest",
      "outputs": ["{workspaceRoot}/coverage/{projectRoot}"],
      "options": {
        "jestConfig": "apps/my-app/jest.config.ts",
        "cacheDirectory": "../../.cache/jest/my-app",
        "passWithNoTests": false
      },
      "configurations": {
        "ci": {
          "coverageReporters": ["text-summary"],
          "maxWorkers": 2
        }
      }
    },
    ...
  }
}

Now, with NX 18, I'm trying to do this:

nx.json

  "targetDefaults": {
    ...
    "test": {
      "inputs": [
        "default",
        "^production",
        "{workspaceRoot}/jest-global-mocks.angular.ts",
        "{workspaceRoot}/jest-setup.angular.ts",
        "{workspaceRoot}/jest.config.angular.ts",
        "{workspaceRoot}/jest.preset.js",
        { "externalDependencies": ["jest"] }
      ],
      "outputs": ["{workspaceRoot}/coverage/{projectRoot}"],
      "options": {
        "lintFilePatterns": ["{projectRoot}/**/*.{ts,html,json}"],
        "cache": true,
        "cacheLocation": ".cache/eslint",
        "cacheStrategy": "content"
      },
      "configurations": {
        "ci": {
          "ci": true,
          "codeCoverage": true
        }
      }
    },
    "lint": {
      "inputs": [
        "default",
        "{workspaceRoot}/.eslintignore",
        "{workspaceRoot}/.eslintrc.angular.json",
        "{workspaceRoot}/.eslintrc.cypress.json",
        "{workspaceRoot}/.eslintrc.json",
        "{workspaceRoot}/.prettierignore",
        "{workspaceRoot}/.prettierrc",
        { "externalDependencies": ["eslint"] }
      ],
      "cache": true,
      "options": {
        "lintFilePatterns": ["{projectRoot}/**/*.{ts,html,json}"],
        "cache": true,
        "cacheLocation": "{workspaceRoot}/.cache/eslint",
        "cacheStrategy": "content"
      }
    },
  },
  "plugins": [
    {
      "plugin": "@nx/eslint/plugin",
      "options": {
        "targetName": "lint"
      }
    },
    {
      "plugin": "@nx/jest/plugin",
      "options": {
        "targetName": "test"
      }
    },
    {
      "plugin": "@nx/cypress/plugin",
      "options": {
        "targetName": "e2e",
        "componentTestingTargetName": "component-test"
      }
    }
  ],

What's odd and confusing is that the nx show project my-app --web command displays the options correctly, but it doesn't work.

I've searched for answers in the issues/discussions, but it's really unclear:

• Issue 9745
• Issue 21449
• Issue 21587

I think it's a documentation problem, but I don't quite understand the purpose of Inferred Tasks as a result.

To further improve, we're trying to consolidate as much redundant information as possible.
For example, we're attempting to group configuration files by technology to align all our projects and have only one place to modify, but this isn't well-supported during NX migrations, and we struggle to adjust the namedInputs to manage the cache.

Here's our overall organization (of course, we have more libs and projects):

📦 mono-repo/
┃
┣ 📄 .eslintrc.json                // Contains basic and typescript rules
┣ 📄 .eslintrc.angular.json        // Contains specific angular rules extending .eslintrc.json
┣ 📄 .eslintrc.cypress.json        // Contains specific cypress rules extending .eslintrc.json
┃
┣ 📄 jest.preset.js
┣ 📄 jest.config.angular.ts        // Global jest angular config (with `preset: '../../jest.preset.js',`)
┣ 📄 jest-global-mocks.angular.ts  // Global jest angular mock
┣ 📄 jest-setup.angular.ts         // Global jest-setup to avoid having it in each project
┃
┣ 📄 tsconfig.base.json            // Global typescript config
┣ 📄 tsconfig.angular.json         // Global angular config, extends tsconfig.base.json
┣ 📄 tsconfig.cypress.json         // Global cypress config, extends tsconfig.base.json
┃
┣ 📚 libs
┃
┣ 📦 apps
┃ ┣ 📂 my-app
┃ ┃ ┣ 📄 eslintrc.json             // Just extends .eslintrc.angular.json and specifies some rules like angular prefix or import/resolver
┃ ┃ ┣ 📄 tsconfig.json             // Just extends tsconfig.angular.json
┃ ┃ ┣ 📄 jest.config.angular.ts    // Jest spread jest.config.angular.ts and specifies displayName, coverageThreshold
┃ ┃ ┗ 📄 ...
┃ ┣ 📂 my-app-e2e
┃ ┃ ┣ 📄 eslintrc.json             // Just extends .eslintrc.cypress.json and specifies some rules like import/resolver
┃ ┃ ┣ 📄 tsconfig.json             // Just extends tsconfig.cypress.json
┃ ┃ ┗ 📄 ...
┃ ┗ 📂 other-app
┗ ...

We also tried to consolidate cypress.config.ts without success so far.

We would really like configuration files to be inferred as well, to be able to inject projectRoot workspaceRoot into them.
The idea would be to even avoid having configuration files, but still be able to use them for particular cases.
Initially, this is what I thought when I saw the arrival of Project Crystal/Inferred Tasks.

I'm not sure if others have understood the same thing as us and are trying to do the same, but I would be happy to discuss it.

[jogelin]

I really like the approach of centralizing all configurations, not just the Nx configurations (I covered that subject here The Super Power of Conventions with Nx).

Two things come to mind reading your post:

The first thing is that I know the generation of a new workspace uses the executor name instead of the target name to apply defaults. Did you try this instead?:

"targetDefaults": {
    "@angular-devkit/build-angular:application": {
      "cache": true,
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"]
    },
    "@nx/js:tsc": {
      "cache": true,
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"]
    }
  },

The second thing is that if you are using Nx 18, why don't you consider creating your own plugins instead of targetDefaults?

Like Nx is doing, you can create a plugin per stack and:

• Generate Nx Project Configuration
• Group related tool Configurations

I also cover that subject in my articles
💎 Discovering Nx Project Crystal’s Magic
✌️ Nx Plugin v2: Dynamic Project Configurations

[kekel87]

Wow, thanks for these insights.
It was certain that we weren't the only ones doing this.

I'm not sure about the executors. Whenever I do a version upgrade, I always generate a new project next to it to see the differences not handled by automatic migrations. And I haven't seen that.

Here's a brand new nx.json:

nx.json

{
  "$schema": "./node_modules/nx/schemas/nx-schema.json",
  "namedInputs": {
    "default": ["{projectRoot}/**/*", "sharedGlobals"],
    "production": [
      "default",
      "!{projectRoot}/.eslintrc.json",
      "!{projectRoot}/eslint.config.js",
      "!{projectRoot}/**/?(*.)+(spec|test).[jt]s?(x)?(.snap)",
      "!{projectRoot}/tsconfig.spec.json",
      "!{projectRoot}/jest.config.[jt]s",
      "!{projectRoot}/src/test-setup.[jt]s",
      "!{projectRoot}/test-setup.[jt]s",
      "!{projectRoot}/cypress/**/*",
      "!{projectRoot}/**/*.cy.[jt]s?(x)",
      "!{projectRoot}/cypress.config.[jt]s"
    ],
    "sharedGlobals": []
  },
  "targetDefaults": {
    "@angular-devkit/build-angular:application": {
      "cache": true,
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"]
    }
  },
  "plugins": [
    {
      "plugin": "@nx/eslint/plugin",
      "options": {
        "targetName": "lint"
      }
    },
    {
      "plugin": "@nx/jest/plugin",
      "options": {
        "targetName": "test"
      }
    },
    {
      "plugin": "@nx/cypress/plugin",
      "options": {
        "targetName": "e2e",
        "componentTestingTargetName": "component-test"
      }
    }
  ],
  "generators": {
    "@nx/angular:application": {
      "e2eTestRunner": "cypress",
      "linter": "eslint",
      "style": "scss",
      "unitTestRunner": "jest"
    }
  }
}

My diff project generation command

npx create-nx-workspace@latest \
  --name nx-diff \
  --appName angular \
  --preset angular-monorepo \
  --routing true \
  --skipGit \
  --style scss \
  --workspaceType integrated \
  --standaloneApi false \
  --nxCloud skip \
  --bundler esbuild \
  --ssr false \
  --e2eTestRunner cypress

As for the second point, I haven't looked into creating custom plugins yet, and honestly, I thought it would work out of the box, hence my remark about the documentation.
I'm not a fan of doing custom work; it needs maintenance and can create conflicts.
That's partly why we chose NX. 😉

[jogelin]

I always generate a new project next to it to see the differences not handled by automatic migrations

Same same! 😉

Here's a brand new nx.json:

When I check your newly generated nx.json, I see the executor name "@angular-devkit/build-angular:application": { instead of build right?

As for the second point, I haven't looked into creating custom plugins yet, and I thought it would work out of the box, hence my remark about the documentation.
I'm not a fan of doing custom work; it needs maintenance and can create conflicts.

I understand that! I'll not try to convince you how easy it is. Just try! Could be just a file:

IMO it is easier to maintain rather than playing with migrations and complex generators. As you said, you are still creating a project on the side and comparing it so finally you know what changed. Just apply it on your plugin ;)

It would be a good idea if Nx exposes its plugins and we just need to extend it 🤔

[jogelin]

I added another discussion related to Project Crystal here: #22099