Suppress workspace only warnings if parent workspace has overlap

[KyleJune]

One usecase for having a workspace is so that you can override a package locally with a git submodule. When I do so, I get a bunch of warnings about the submodule/workspace having the unstable field in its configuration. For example, while working on a bug fix for deno-esbuild-plugin, I get warnings about the unstable field only being able to be specified in the root deno.json file. This warning is only really helpful if the workspaces root deno.json is missing the required field. Is this warning really needed if my root workspace has all the unstable APIs enabled that the submodule needs? For example, the root has unstable set to ["kv", "raw-imports"], and the child's deno.json has it set to ["raw-imports"]. I don't think a warning is needed in that case. But if the root unstable configuration was missing "raw-imports", then it would make sense to warn that it needs to be enabled in the root configuration.

Warning "unstable" field can only be specified in the workspace root deno.json file.
    at file:///home/kyle/Projects/udibo/juniper/libs/deno-esbuild-plugin/deno.json

Another use case where I encounter the same issue is when I have separate folders in my workspace for examples/templates. I want my templates to have the full deno.json configuration that users would have without it logging a bunch of warnings while I'm using it in the context of my workspace.

[dsherret]

For example, while working on a bug fix for deno-esbuild-plugin

Note that in this case, you should prefer using the "links" feature (https://docs.deno.com/runtime/fundamentals/configuration/#overriding-packages) instead of making it a workspace member.

[dsherret]

I'm not sure it's worth the extra complexity here to do this comparison. Workspace members just shouldn't have non-workspace properties.

Another use case where I encounter the same issue is when I have separate folders in my workspace for examples/templates.

This use case seems more valid though, but perhaps the unstable flags could just be commented out in the example.

[KyleJune]

For example, while working on a bug fix for deno-esbuild-plugin

Note that in this case, you should prefer using the "links" feature (https://docs.deno.com/runtime/fundamentals/configuration/#overriding-packages) instead of making it a workspace member.

I didn't know about this and just tried it out. When I try running tests from that folder I get an error saying that the config file must be a member of the workspace. All I did was move "./libs/deno-esbuild-plugin" from my workspace array to the links array in my workspace's Deno config file.

kyle@DESKTOP-V86D3M0:~/Projects/udibo/juniper/libs/deno-esbuild-plugin$ deno test -A
error: Config file must be a member of the workspace.
  Config: file:///home/kyle/Projects/udibo/juniper/libs/deno-esbuild-plugin/deno.json
  Workspace: file:///home/kyle/Projects/udibo/juniper/

If I try putting "./libs/deno-esbuild-plugin" in both my links array and workspace array, I get the following error.

kyle@DESKTOP-V86D3M0:~/Projects/udibo/juniper/libs/deno-esbuild-plugin$ deno test -A
error: Failed loading link './libs/deno-esbuild-plugin' in config 'file:///home/kyle/Projects/udibo/juniper/'.

Caused by:
    Workspace member cannot be specified as a link.

So it looks like if I am using a workspace, I have to add the lib as a workspace member rather than a link, otherwise I can't run tests for it.