Add support to run schematics that are part of custom plugins within an existing workspace.

[niki4810]

Description

We can currently create custom schematics using the nx generate @nrwl/workspace-schematic command and run them locally within an existing workspace (consisting of apps and libs) via nx workspace-schematic <schematic-name>

However, when creating a custom plugin via nx generate @nrwl/nx-plugin:plugin and creating a schematic under libs/<plugin-name>/src/schematics, there is currently no way to run this plugin locally to use/test our schematics (unless we publish)

• Here is a sample project to illustrate the issue: https://github.com/niki4810/myorg
• You can run the schematic in tools: https://github.com/niki4810/myorg/tree/master/tools/schematics/custom-react
• But currently, there is no way to run the same schematic that is part of the plugin: https://github.com/niki4810/myorg/tree/master/libs/custom-react/src/schematics/custom-react

Please refer to this slack thread for more details: https://nrwlcommunity.slack.com/archives/CMFKWPU6Q/p1592940422065400

Motivation

Having the ability to run plugins (with custom schematics) helps in:

• following the same syntax external plugins: nx generate <plugin-name>:<schematic> instead of new command nx workspace-schematic <schematic>
• Have the ability to list the schematics via: nx list <plugin-name>

Suggested Implementaion

• I would expect it to work the same way as any published community plugins work, i.e. nx generate <plugin-name>:<schematic>

Alternate Implementations

• N/A

[webberwang]

Is there a way to yarn link without having to publish?

[pascalbe-dev]

This is actually possible. You can build the plugin locally, so it ends up in your dist folder. Then you can run it directly from that build target location via nx. In your sample repo, it would work like that:

nx build custom-react
nx g ./dist/libs/custom-react:library

Ofc you can also pass options.

[Carniatto]

This is not really the ideal solution, cuz if anyone in the team wants to use it they'd need to build it every time. Or persist the dist folder

[Hotell]

this PR adds similar DX capabilities to workspace-schematic, like nx plugins provide
#3617

[mehrad-rafigh]

This only works if you have one generator that does not depend on another generator inside the plugin 👎🏽

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[hadrien-toma]

I also supposed it was working like for schematics and I finally ended here. I would be very happy to use this really well defined enhancement.

[koliveira15]

This would help our org immensely. We have many workspace-generators that are being converted to plugins so other nx repos within our org can consume. Building the plugin before executing within the same workspace the plugin exists is not a great DX.

[AgentEnder]

This is something we are re-evaluating post Nx 13.0, as we agree that it would help DX tremendously.

As a quick note, there are some workarounds or other things you can do to enhance DX with the current setup.

Workspace Generator -> Generators in a Plugin

If moving a workspace generator into a plugin, you can have the existing workspace-generator import the plugins generator and call it. This way people don't have to switch the commands they are used to using already either.

Executors from a local nx plugin

For executors in a "workspace-plugin", you can make sure projects that use the plugin have an implicit dependency on the plugin project. This ensures that the plugin is built (and in its latest state) before the executor runs. Since nx caches these builds, it shouldn't extend your command run times.

Just adding the dependency like above, is all thats needed for build targets. This is because of the targetDependencies section of nx.json's default contents. If your executor has a generic targetName, you would need to add a dependsOn block to the target, and may want to add a target on the plugin called "build-plugin" or similar, to avoid building non plugin projects before the executor runs.

For example:

If you have a plugin that contains a new serve executor, and a lint executor, you may have a workspace.json with projects such as below:

{
  "projects": {
    "my-plugin": {
      "targets": {
        "build": {
          "executor": "@nrwl/node:package"
        },
        "build-plugin": {
          "executor": "@nrwl/run-commands",
          "options": {
            "command": "nx build my-plugin"
          }
        }
      }
    },
    "my-app": {
      "targets": {
        "serve": {
          "executor": "./dist/packages/my-plugin:serve",
          "dependsOn": [
            {
              "target": "build-plugin",
              "projects": "dependencies"
            }
          ]
        },
        "lint": {
          "executor": "./dist/packages/my-plugin:lint",
          "dependsOn": [
            {
              "target": "build-plugin",
              "projects": "dependencies"
            }
          ]
        }
      }
    }
  }
}

If multiple projects use those custom executors in your workspace, it would make more sense to remove the dependsOn blocks, and use targetDependencies in nx.json. That would look something like:

{
  "targetDependencies": {
    "serve": [
      {
        "target": "build-plugin",
        "projects": "dependencies"
      }
    ],
    "lint": [
      {
        "target": "build-plugin",
        "projects": "dependencies"
      }
    ]
  }
}