I think this is only ever useful if wildcards are supported? Or are you talking about npm workspaces? I think npm workspaces support negated patterns.

I was referring to deno's feature actually. I suppose you mean wildcards for specifying members as well? That would be nice but the specific issue I encountered was related to exclusion.

Our repo has a tests/ directory with a number of deno.json based sub-projects that need to be shielded from the top level workspace. The suite itself generates a bunch more test deno.json when running so we can't manually specify the exclusion list at once.

There are workarounds but even slight support for exclusion is needed right now due to the error I mentioned.

Demonstration of the error:

/tmp/stuff via 🦕 v1.45.2
❯ lt                                                                                      at 03:03:07
 .
├──  bar
│   ├──  deno.json
│   └──  stuff.ts
├──  deno.json
└──  foo
    └──  deno.json

/tmp/stuff via 🦕 v1.45.2
❯ bat deno.json                                                                           at 03:03:08
───────┬──────────────────────────────────────────────────────────────────────────────────────────────
       │ File: deno.json
───────┼──────────────────────────────────────────────────────────────────────────────────────────────
   1   │ {
   2   │   "workspace": [
   3   │     "./foo"
   4   │   ]
   5   │ }
───────┴──────────────────────────────────────────────────────────────────────────────────────────────

/tmp/stuff via 🦕 v1.45.2
❯ deno run bar/stuff.ts                                                                   at 03:03:10
error: Config file must be a member of the workspace.
  Config: file:///tmp/stuff/bar/deno.json
  Workspace: file:///tmp/stuff/

Ah ok, so basically you'd like:

Another nice feature might be to supports Cargo's semantics of excluding deno.json files that also declare their own workspace section. Currently, deno will error out with a message stating that the sub-workspace is not a member of the top dude.

...since workspace members aren't included unless explicitly specified at the moment.

The suite itself generates a bunch more test deno.json when running so we can't manually specify the exclusion list at once.

If the test suite is generating files, you might want to have all that execute in temp directories. That will prevent your editor from reacting to all the file changes occurring in your cwd when running tests.

I also agree with this exclude option.
For more complex mixed Node.js and Deno projects, this option can avoid installing unnecessary package.json packages.
However, it seems that some npm packages may not work properly with this option, so I think users should set this option at their own risk.

Another nice feature might be to supports Cargo's semantics of excluding deno.json files that also declare their own workspace section. Currently, deno will error out with a message stating that the sub-workspace is not a member of the top dude.

By the way, I just thought about how to do this today. You can stop the ancestor directory search by adding the following to the child deno.json files:

{
  "workspace": []
}

Overall, given that, I'm not sure there's much use for this feature and it's really only necessary once there's wildcards, but in that case there will be negative patterns like npm.

Nice. Looks like the empty workspace section does indeed prevent inclusion in a parent workspace. I could have sworn I'd tried that but something must have gone wrong. Thanks!