Add Support for Nested Deno Workspaces with Domain/Subdomain

[nirnay-raval-st10]

💡 Feature Request: Nested Deno Workspaces

Description Add support for nested workspace configuration in Deno projects to better organize code by domains and subdomains, similar to how pnpm/yarn workspaces work for Node.js.

Current Situation

• Currently, Deno projects are typically structured as single workspaces
• No built-in support for organizing multiple related packages in a monorepo structure
• Challenging to maintain domain-driven design with current workspace limitations

Proposed Solution Support nested workspace configuration through:

1. Extended deno.json workspace configuration:

   
   {
   "workspace": {
   "domains": {
     "core": "./domains/core",
     "auth": "./domains/auth",
     "api": {
       "public": "./domains/api/public",
       "internal": "./domains/api/internal"
     }
   }
   }
   }

basically i want to have domain and subdomain workspace differently in same repository.

[dsherret]

Can you explain the benefit over just using different name prefixes? Also, where is the pnpm/yarn documentation on this?

[nirnay-raval-st10]

Can you explain the benefit over just using different name prefixes? Also, where is the pnpm/yarn documentation on this?

Let me explain the benefits of using workspace structure over name prefixes:

Benefits of Workspaces vs Name Prefixes

1. Isolation and Organization

   
   // Workspace Structure
   workspace/
   ├── slices/
   │   ├── extractFeeds/      // Complete isolated module
   │   ├── fetchFeeds/        // Complete isolated module
   │   └── generateIssues/    // Complete isolated module

// vs Name Prefix Structure src/ ├── extractFeeds.ts ├── fetchFeeds.ts └── generateIssues.ts

2. **Benefits**
- **Dependency Management**: Each slice can have its own dependencies
- **Cleaner Testing**: Tests live alongside the code they test
- **Better Code Organization**: Related files stay together
- **Easier Maintenance**: Changes to one slice don't affect others
- **Independent Versioning**: Each slice can be versioned separately
- **Better CI/CD**: Can build/test individual slices

3. **Your Current Setup**
```json
{
  "workspace": {
    "members": [
      "./slices/extractFeeds",
      "./slices/fetchFeeds",
      "./slices/generateIssues",
      "./slices/services",
      "./slices/types",
      "./slices/shared",
      "./slices/generateUpdatesFeeds"
    ]
  }
}

Documentation References

This is actually a Deno-specific workspace implementation, different from pnpm/yarn:

• Deno Workspaces: https://deno.land/manual@v1.34.3/tools/workspaces
• pnpm Workspaces: https://pnpm.io/workspaces
• Yarn Workspaces: https://classic.yarnpkg.com/lang/en/docs/workspaces/

The key difference is that Deno workspaces are more lightweight and focused on module organization rather than package management like pnpm/yarn.

For use case, Deno workspaces provide better module isolation and organization without the complexity of full package management systems.

[dsherret]

Is this chatgpt output? Why is it linking to https://deno.land/manual@v1.34.3/tools/workspaces

Can you please explain in your own words a concrete example and use case? The yarn and pnpm documentation looks similar to Deno for what I can see, but I must be missing something.

[nirnay-raval-st10]

Is this chatgpt output? Why is it linking to https://deno.land/manual@v1.34.3/tools/workspaces

Can you please explain in your own words a concrete example and use case? The yarn and pnpm documentation looks similar to Deno for what I can see, but I must be missing something.

the problem is

• i want to handle a project in which i want to handle a sub domain as a individual deno workspace

[nirnay-raval-st10]

nested-deno-workspace/
├── deno.json
├── packages/
│   ├── math/
│   │   ├── deno.json
│   │   ├── src/
│   │   │   ├── add.ts
│   │   │   ├── subtract.ts
│   │   │   ├── multiply.ts
│   │   │   └── divide.ts
│   │   └── tests/
│   │       └── math_test.ts
│   └── utils/
│       ├── deno.json
│       ├── src/
│       │   └── logger.ts
│       └── tests/
│           └── logger_test.ts
└── main.ts

like in this example

• packages is the main domain
• math is sub domain
• utils is sub domain

now i want to make a math as a individual deno workspace and also utils as a individual deno workspace and they are member of package deno workspace too.

[dsherret]

Can you show an example of pnpm or yarn doing this? I don't see an example in the linked documentation of them having this functionality. I still don't understand what this solves or why it's desired/what the benefit is.

[dsherret]

I think I just realized my confusion. Are you asking for workspace support in general? It's already supported in Deno: https://docs.deno.com/runtime/fundamentals/workspaces/

I got confused because I thought you were asking for a change to how workspaces worked.

[nirnay-raval-st10]

let me rephrase my issue/request:-

Support for Multi-Level Workspace Organization in Deno

Current Behavior:

• Workspaces can only be configured at the root level
• Packages must be directly under the root workspace
• No support for workspace nesting or sub-workspaces

Desired Behavior:

• Support for workspace nesting
• Allow workspaces to contain other workspaces
• Enable hierarchical workspace organization
• Maintain separate configuration for each workspace level

Example Structure:

root-workspace/
├── workspace-1/
│   ├── package-1/
│   └── package-2/
└── workspace-2/
    ├── package-3/
    └── package-4/