Package scopes other than project name?

[about-code]

Currently it seems nrwl/nx takes an opinionated approach to monorepos which isn't yet as flexible as nor compatible to Lerna monorepo structure. E.g. all libraries in a workspace inherit the package scope from the workspace/project name which works for company policies like always use a project scope for libraries. Lets pretend two other reasonable scenarios/policies:

1. use a common scope for all packages/libs across different workspaces/repos (e.g. a company-scope)
2. use a company scope for packages whenever possible but use a project- or departmental scope for packages not intended to be reused by others outside the scope

Can these policies be met with nrwl/nx workspaces? For example is there a means/plans to read a default package scope from a config file in a users $HOME (would help to meet 1.) or to allow defining scopes on library generation (would help to meet both)? I couldn't see a package.json or proper folder structure being generated for libs so I assume the second is not possible as of today (ng generate lib @foo/mylib didn't work 😢 ).

Note: I'd be satisfied with an answer and leave it open to the maintainers or community whether to handle the issue as a question or feature request.

Thank you.

[vsavkin]

The scope can be set separately here:
(https://github.com/nrwl/nx/blob/master/packages/schematics/src/application/schema.json#L17), but it is one for the whole monorepo.

Having different scopes for different libraries is a reasonable use case. So at some point we will probably implement it.

[nvdnkpr]

Hello @vsavkin
Are there any plans of adapting Nx to something like lerna ?
The reason why I ask this is because I'm currently evaluating different approaches for a big enterprise application that

1. will be (most likely) organized in a monorepo
2. will be build (locally and CI) incrementally with bazel and webpack (I just read Torgeir's article on medium about bazel)
3. will have the need to support semantic-release

So the first two points are decisions made on the feasibility, but for the last point, semantic-release, I am still evaluating the way (not the if).
I know that there is https://github.com/atlassian/lerna-semantic-release but the question is where it differs to your approach so that one can adapt it to your monorepo-style too

So what I want to suggest ist perhaps that you document in a few words, sentences or paragraphes which differences from your monorepo approach to the one built with lerna.

[vsavkin]

For default Nx projects:

We aren't considering using lerna within the workspace, only to connect the workspace to other projects, similar to how you would use "yarn workspaces" (https://blog.nrwl.io/dev-workflow-using-git-submodules-and-yarn-workspaces-14fd06c07964).

For your project:
You can add lerna. Nothing in the nx workspace prevents you from using it.

[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.