is it possible to use an array for workspaceLayout.appsDir?

[ramjawade]

is it possible to use an array for appsDir?

i'd love to do something like

"workspaceLayout": {
  "appsDir": ["core-use-case1/clients/**", "core-use-case2/clients/**"], 
  "libsDir": "utils"
}

PS: This would also mean that a a way specify the prefix core-use-case*/clients when adding new apps would be needed

Originally posted by @Bulletninja in #2182 (comment)

@Bulletninja Suggestion is good.

With this, we can manage

1. Multiple clients,
2. or differentiate our libs and application based on some categories.

like :

• apps -> for front-end apps.
• libs -> for front-end libs.
• micro-apps -> for backend micro-app.
• micro-libs -> for backend micro-libs.

[Jordan-Hall]

I don't see the need for this. You can have a grouping folder to separate them up.

[ramjawade]

Yes, @Jordan-Hall, we can group folders, but I want to group at the root level.
Because as are working on a very big project which includes 100+ libs,
we have already categorized our libs in the following type

• core
• feature-module
• templates
• themes
• etc

If I import one feature-module library then the import will be
import { feature } from 'workspace/feature-module/feature/'
and if we have grouped feature then the import will be wrost like,
import { feature } from 'workspace/feature-module/grouped-feature/feature'

I feel is not good to deep import with 4 or 5 levels, we can reduce one level by creating a group at the root.
If we deep import any library then the intelligence of the editor will not work correctly.

[Jordan-Hall]

So im working on a project thats huge too. You don't need to have huge import paths. We still shorten it down and not treat the path level the same as the import path using --importPath.

[vsavkin]

appsDir and libsDir are used by core plugins (and third party plugins) to know where to create apps and libs. But they are not used for anything passed that. Instead we use the rootDir property and the info in the root tsconfig.base.json.

They are also used in some aux fashion to make sure you don't have any files not belonging to a lib etc, but that's not essential.

This means that you could generate a new lib and just manually move to any other place and then update workspace.json and tsconfig.base.json. Everything will work fine after that. The libraries don't have to be located in libsDir. This is Option 1.

Option 2 is to point both appsDir and libsDir to the same dir, say: projects and you can have any layout there.

When it comes to an extra level of nesting adding an extra segment in the import: The root tsconfig.base.json defines how libs are resolved. So you can have a lib located at libs/group1/group3/mylib and be imported as import 'mylib'. So the imports and where the libs are located don't have to match.

So you have a few options.

The reason I'm not keen on having them as array is that it will force users to choose which one. So they will have to provide --libsDir=libs2 --direction=nested, which I think might be confusing.

[ramjawade]

@vsavkin and @Jordan-Hall Thanks for your guidance. Yes, we can use --importPath.

Might be my approach creates confusion for the developer.

Suppose we are building a todo application then we will have the following libs,

1. libs/todo - angular lib
2. micro-libs/todo - node lib. (folders defined with my approach)

While importing we will skip the first level and start with the second level with organizations.

Like import {TodoModule} from 'my-org/todo'. Then here this todoModule belongs to what? libs or micro-libs
This will create confusion to resolve that we have to use --importPath like '@my-org/micro-libs-todo' for the second library.

So, In both cases, we have to use --importPath.

A defined approach is good we can create different folders and use --importPath.

[NateMay]

I have a root-level directory of microservices (firebase functions) that are conceptually distinct from an app or a lib. I'd like to be able to allow my apps to import the API interfaces from the root-level microservices directory rather than maintaining them in a disassociated lib. This is more of a module boundaries issue, but a libsDir array could potentially help me with my use case.

Is there a way I can do this and avoid the module boundaries error?

P.S. I understand that I'm importing the microservices dependencies into my app but I prefer that over the disorganization/complexity of maintaining the API interfaces elsewhere.

[jase88]

If you're dealing with a relative small monorepo (2 apps), it would be nice to place them both at root level. Like a standalone repo but with 2 apps 😉

Defining an array of apps could solve that.