workspace.json is not normalized, introduce a key to specify project.json and normalize workspace.json

Description

As per the documentation here: https://nx.dev/l/n/core-concepts/configuration#projectjson A project can be defined inside the workpace.json in two ways, fully explicitly or by giving a string to the project.json location:

{

  "version": 2,
  "projects": {

// Option 1

    "myapp": {
      "root": "apps/myapp/",
      "sourceRoot": "apps/myapp/src",
      "projectType": "application",
      "targets": {
...
     }

// Option 2

    "myapp-with-project-json": "apps/myapp-with-project-json"

  }
}

This leads to a workspace.json file that can have values of type “string” or an object/struct. This breaks other tools trying to parse the file, and it is particularly problematic in monorepos where you might want to leverage these files with multiple languages.

For example:

$ jq -r '.projects[].root' workspace.json 
apps/myapp-with-project-json
jq: error (at workspace.json:4531): Cannot index string with string "root"

jq doesn’t fail when the key is missing, only because the schema is not consistent.

To fix this problem, introduce a way to tell NX about the project.json:

    "myapp-with-project-json": {
      "projectJson": "apps/myapp-with-project-json",
    }

And mark option 2 above as deprecated or discouraged. Eventually remove it. Projects that need the normalized workspace.json will move to the new syntax.

Motivation

Allow tools with strict schemas to make use of workspace.json

Suggested Implementation

Introduce the “projectJson” key.

Alternate Implementations

Reuse the “root” key, though this requires extra logic to figure out if everything is in there or not. We might always want to check if there are project.json overrides at the project root location or something like that.

[AgentEnder]

The current format can certainly be validated w/ json schema, as nx-console provides such a schema to vscode. Let me see if I can grab that example.

[AgentEnder]

I really would like to re-emphasize using a light node wrapper if you want to read the workspace in another programming language. Its a bit more work than just reading the file, but should lessen the possibilities of your custom tools breaking during an Nx upgrade. If you’re using Nx, you already are running node and such so its not too much of an ask imho.

Its ultimately not my decision if we want to pursue changes like this, so I’ll talk it over with the team.

I’m going to close this out for now, and keep it in mind to reopen if we go down this path.