Workspaces documentation is not very clear on how a project "discovers" its sibling projects

[dmint789]

I followed the documentation for Deno workspaces here, but found that it's not very clear on how a Deno project "sees" its sibling projects to be able to import them. From my understanding, if I run a project A in a workspace that also has project B, which A imports, Deno will first look in the parent directory of the project A directory, see if there is a root deno.json file there with a workspace property, then check the projects that workspace contains, and then, seeing that there is project B specified in the workspace array, will check if project B has a deno.json file, and then will import it successfully. This means that if we are to create a Docker container for project A, we must also copy project B and the root deno.json file to it. However, these are all just my assumptions, and it would be good if all of this was clearer from the documentation.

[marvinhagemeister]

All your assumptions are correct. A workspace is defined by the root deno.json having a workspace property.

[dmint789]

@marvinhagemeister do you think the documentation could be made a bit clearer to reflect this?

[dmint789]

@marvinhagemeister I also have another question: is it best to keep all projects in a single Deno workspace in the same Docker container? I'm now thinking that might be best, given how interconnected things become and that the alternative requires copying the shared project(s) and the root deno.json into each container separately.

[rossholdway]

I'd also like some clarification on how best to use workspaces if we want each member of the workspace to be it's own container without having to include the entire monorepo in the image? Currently Deno errors out with "Could not find config file for workspace member".

[thisisjofrank]

I've updated both the workspace documentation and the docker documentation. Let me know if I can help any further

[dmint789]

@thisisjofrank this is great, thank you!