Support `deno.config` in a multi-root workspace

[kitsonk]

Deno 1.10.3 is available which supports the workspace folders/per resource configuration

Can you please reopen this issue? It doesn't support deno.config in the workspace folder settings overrides yet, which would be super useful for developing a deno client/server app in the same multi-root workspace!

_Originally posted by @johnspurlock in https://github.com/denoland/vscode_deno/issues/314#issuecomment-903988294_

[kitsonk]

Supporting deno.config per multi-root workspace is complicated and non trivial.

What compiler options do you need to vary per workspace root?

[johnspurlock]

The libs - e.g. dom in one, web worker in another, without leaking out to the other workspace roots. I feel like this might be a common scenario. Loving Deno in vscode so far, this would make it ideal!

[albnnc]

I completely agree on the fact that fully functional multi-root workspaces (deno.config and deno.importMap atleast) support is a huge need for comfortable work. As far as I can see, many people (and me too) like monorepos, however it's impossible to work on packages with different tsconfigs (e.g. different libs) or importMaps (different deps) in the same VSCode project for now.

I also quite don't like this question while I completely understand its origins:

What compiler options do you need to vary per workspace root?

On one hand the developers of deno want (I suppose) to support needed features only. On the other hand, something like the monorepo way treats its packages as a completely independent, full-fledged and sometimes even self-sustained things or sub-projects. Thus, I don't think there has to be a question if a separate package (VSCode workspace) should be configurable in terms of any deno options or not.

One thing that I didn't catch up (some info is rather contradictory) is that wether the current limitations are defined by this VSCode extension or by deno language server.

[swandir]

Could the language server implementation instead maintain a module graph, split it into sub-projects and typecheck the sub-projects separately? Similar to how tsserver works with composite projects.

[alichry]

This seems like an old issue but it is a deal-breaker regardless of technical constraints. I am currently on a monorepo and defining deno.config in root/service1/.vscode/settings.json did not have any effect for VS Code/Deno to pick up root/service1/deno.json. Is there a workaround?

[download13]

I could express this as an upvote (and I have), but also want to write out my use case of a monorepo including an app with both a server and client component, which requires the ability to run a deno project from a directory other than the root.

While excited to try out deno, I had to abandon the attempt when I discovered that a deno project in vscode cannot co-exist with any other structures.

Given the increasing popularity of monorepos I cannot imagine that deno is going to gain traction among developers if every deno project has to be interacted with isolated from any closely-related projects.

[nayeemrmn]

Closing in favour of #787.

[sirikon]

Does the other issue include support for, specifically, VSCode’s multi root workspaces, and not only multiple Deno projects under the same language server?

[nayeemrmn]

Do you mean workspaces with multiple 'workspace folders'? Those share a language server, so yes.

[danilo-valente]

I couple months ago I stumbled across the same limitation but found no solution, so I decided to create my own Deno monorepo manager. Instead of having a separate pair of deno.config and import_map.json for each module it leverages import map's scopes feature to provide module-level dependency mapping and local module linking.

Compy - Minimalist (yet helpful) monorepo manager for Deno

https://deno.land/x/compy

Disclaimer: Compy is still in early stage and some features might be redesigned in future versions. Automated testing and proper documentation is also in progress.

That said, it does provides good tooling for creating a project and its modules, adding dependencies and mapping them through import maps, running Deno's CLI commands within a module's context and linking modules between themselves. In fact, I'm currently using it in production.

Some commands include:

• compy init <project> to create a new project/workspace
• compy mod <module> to create a new module within the project
• compy add std to add the latest std version to all modules
• compy add oak v12.6.1 -m <module> to add oak@v12.6.1 to an specific module
• compy <cache|start|dev|run|test|fmt|lint> <module> to run a command within a module's context
• and more

Here's a simple (outdated) demo:

@johnspurlock @albnnc @swandir @alichry @download13 you might find this helpful as well.

[dionjwa]

Agree with these comments. I really want to use deno, and I am, but it's really painful in multi-folder workspaces, and I just cannot seem to get it working. This level of complexity needs to be easily supported at the deno level, and be made as easy as possible, since VSCode workspaces are already often very complex to properly configure. Given the complexity, I appreciate that this functionality will take a while to get right, but looking forward to it. My experience with deno.deploy is so good, I am ok with this current development pain.

[bartlomieju]

@nayeemrmn is actively working on bringing support for multiple configuration files to the extension.