[rush-lib] Support access parameter for each project configuration

[pedro-gomes-92]

Summary

Restricts a package to be used according to its access restrictions.

Details

Package maintainers often need enhanced control and insight into their projects. By introducing a new parameter named access for rush projects, developers gain the ability to limit the visibility of their projects. This feature ensures that unauthorised developers do not install the projects when they are not supposed to.

Currently the parameter provides 3 values:

• public (default): project can be accessed by any local package (e.g. core arch libraries).
• protected: project can only be accessed by the same subspace local package (e.g. team libraries)
• private: project cannot be accessed by others (e.g. standard application)

Example

P1 has protected access restrictions and is being used by P2 and P3. P1 and P2 belongs to the same subspace S1, while P3 belongs to the subspace S2. Since P1 is restricted to only be installed by packages from S1, rush install will fail.

// rush.json
{
  ...,
  "projects": [
     {
       "packageName": "P1",
       "projectFolder": "packages/p1",
       "subspaceName": "S1",
       "access": "protected"
     },
     {
       "packageName": "P2",
       "projectFolder": "packages/p2",
       "subspaceName": "S1"
     },
     {
       "packageName": "P3",
       "projectFolder": "packages/p3",
       "subspaceName": "S2"
     },
  ]
}

How it was tested

• Create a repository with subspaces enabled: https://rushjs.io/pages/advanced/subspaces/
• Create 2 subspaces (e.g. default, S1)
• Create 2 projects (e.g. P1 and P2) inside of default subspace and 1 project (e.g. P3) inside of S1
• Add P1 as a local dependency of P2 and P3
• Update rush.json with { "access": "protected" } for P1 configuration (or private)
• Run rush install --subspace S2

The error message will appear and the installation will fail:

ERROR: P3 doesn't have permissions to access P1.
Please remove this dependency or update the rush.json access rights.

Impacted documentation

https://rushjs.io/pages/configs/rush_json

[L-Qun]

@pedro-gomes-92 Thanks for you contribution. We have a lot of policies related to dependency, so a better approach would be to consolidate them into a single file, such as common/config/project-dependency-policies.json.

"allowCrossSubspaceDeps": false,
"requireNpmDependencies": [
  {
    "project":    "tux",
    "exemptions": ["my-app"]
  }
],
"allowedCrossSubspaceDependencies": [
   {
     "project": "my-app",
     "dependency": "my-lib"
   }
],
"decoupledLocalDependencies" ...

These dependency policies files include:

• rush.json (decoupledLocalDependencies)
• lockfile-lint
• (non)browser-approved-packages.json
  

You can also refer to Nx(https://nx.dev/features/enforce-module-boundaries#enforce-module-boundaries), which has similar functionality.

[dmichon-msft]

Some thoughts:
The keyword "private" already has a defined meaning in package manager space, which does not match what you are using it for here. Specifically, it means that the package may not be published to npm: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#private

Rush usually works with TypeScript projects, and in TypeScript the keyword "protected" doesn't mean the same thing you are using it to mean here either ("can be accessed in subclasses" vs. "can be accessed in other packages in the same subspace").

It feels like what you really want here is a project "packages that are allowed to directly consume me" Access Control List. Artificially constraining it to the granularity of "no projects" vs. "current subspace" vs. "all subspaces" really limits the utility of the feature, when some packages may want the list to be a single, specific package, or limit to the packages that contain your integration tests, or whatever.

I'm open to bikeshedding on what form the field defining the ACL should take, whether it is stringified keys (like @rushstack/node-core-library, tag:tool, subspace:.) or whether it is a JSON object with a schema to specify different methods. I somewhat like the former since it can then leverage any overloading of package selection prefixes that we support for --to and the like, but the extensibility there hasn't been written yet.