Add support for workspace level targets

[edbzn]

• I'd be willing to implement this feature (contributing guide)

Description

Hi there, I'm working on @jscutlery/semver an Nx plugin for versioning your workspace. The plugin works with two modes inspired by Lerna, independent mode and sync mode. The independent mode releases each project independently with a separated tag, changelog, etc... Nx is working well for this use case but the problem comes from the second mode, the sync one.

The sync mode releases the whole workspace (multiple projects and root changelog file) with one single command like so:

nx run workspace:version

To be able to do that we introduced an installation generator that tweaks the workspace definition by creating a virtual project named "workspace" with "root" property equal to ".", this hack allows us to run the executor on the workspace level instead of the project level (since executors are usually defined in the project.json and scoped to a particular project).

Here is a repository that uses that hack, you can see a root project.json.

Motivation

Since Nx 13 this virtual "workspace" project hack based on the "root" property equal to "." is not working anymore, that's why I would like to discuss the possibility of supporting workspace-level executors natively in Nx. This could be useful for any tool that needs to run something globally on the workspace. In the same way, we already have workspace generators that can update multiple projects at once.

Suggested Implementation

Before going into the implementation I would like to discuss the viability of this workspace level executor idea. Is there any alternative solution for this? Maybe using NPM scripts and plain Node.js scripts, but we loose the consistency that Nx brings.

[hpierre74]

Hello Nx Team 👋
I'm the maintainer of the example repo linked in the issue, you can see in this PR BedrockStreaming/forms#75 the workarounds made to make the virtual workspace project hack working in Nx 13.

Unfortunately I had to:

• remove the workspace-lint command (which I'm not comfy with, you may imagine)
• exclude the workspace project from the affected commands, which is ok in my context

From my knowledge, apart from this lint issue, there is no problem using this "virtual root project", but maybe it could conflict with some Nx internals i'm not aware of.

The output of the workspace-lint command (v13.9.5):

$ nx workspace-lint && nx lint

 >  NX   The workspace.json file is out of sync

   - Cannot find project 'workspace' in '.'

We tried to change . to different values but never got it to work

[AgentEnder]

Hey @edbzn! I'm commenting back here with some of our thoughts after discussing this internally and giving the go-ahead if anyone would like to start working on impl (none of us have picked up that torch just yet).

We agree, and this is a feature that's been talked about a few times before. Generally, our stance in the past has been "use npm scripts in the root package.json," but there are some things that doing it in that way doesn't quite capture. Using npm scripts, you miss out on:

• Caching
• Consistent CLI syntax
• TargetDependencies

Implementing this feature wouldn't be trivial, and it would need to update several places. After implementation, we imagine that it would work something like this:

• nx lint -W or nx lint --workspace calls the lint target on the workspace
• nx lint would still call the lint target on either the default project or the project that the CWD is currently inside.
  • This may change eventually, but updating this behavior would be a breaking change and is something we are already investigating for other avenues
• TargetDependencyConfig[projects] should be updated to 'self' | 'dependencies' | 'workspace'
  • Workspace targets should be able to be specified in nx.json[targetDependencies] as well as the dependsOn block
• Workspace targets are defined in nx.json, in a new key called targets that would be structured in the same way as project.json[targets]
  • Eventually, we should be able to run nx {some-npm-script} -W. We inherit project-level npm script targets, so we should also inherit workspace-level npm script targets. However, this work could be a follow-up and is not needed for the initial impl.
• Running workspace targets should hit the task runner, with minimal change to APIs there. We'd like this to be non-breaking if possible. Hitting the task runner should make things like caching and nx cloud work.

If anyone plans on picking this up, let me know, and I can assign the issue to you (or if you have permissions, assign it yourself). I'll try to be responsive and help out as needed.

[edbzn]

Closing this as root-level scripts landed in Nx 15.3.

Good job guys!

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.