[Feature Request] Support multiple types of projects in the same repository

[guidsdo]

Is your feature request related to a problem? Please describe.

It frustrates me that I can't open one vscode instance for all the projects in my repository. Example of what this repository contains:

client/
  - src/
  - tsconfig.json (containing lib: ["DOM"])
  - import_map.json (containing import aliases like: "shared: ./shared/src/index.ts" and "react: https://cdn. ...")
middleware/
  - src/
  - import_map.json (containing only: "shared: ./shared/src/index.ts")
server/
  - src/
  - import_map.json (containing only: "shared: ./shared/src/index.ts")
shared/
  - src/
- dprint.json
- scripts.json

Currently, this setup isn't supported by vscode and the deno plugin. Why? This is because the plugin only allows me to target one tsconfig in total. This tsconfig then applies for all the projects, which doesn't make sense because only the client projects needs different typings (like DOM etc).

Using workspaces don't fix this because the important Deno settings are applied for all projects and not per workspace.

To have both linting and tsc warnings/errors in Node.js, I've written a tool called mtsc in the past to support this but only out of pure necessity.

Describe the solution you'd like

Supporting these so-called monorepos (or multiple workspaces) is something which is already hard for vscode for Node.js projects, but I would really love it if there could be support for it through the Deno plugin. :-)

One or more of these features that would be really nice:

• Specify projects and their settings:

projects: [{ 
  "location": "./client", 
  "settings": { 
    "config": "./client/tsconfig.json"
  }
]

• Autodetect if there is a tsconfig.json that this should be a separate project
• Allow for a script.json like file that specifies what projects there are and what settings should be set (unsafe, config, linting, etc)
• ... I don't know, I'm open for better ideas. 😁

[kitsonk]

Duplicate of #314

We don't want to put in a whole configuration infrastructure that effectively breaks with the built in capabilities of vscode (or other editors). There is quite a bit of conversation at the end of #314 about why it is problematic.

Using workspaces don't fix this because the important Deno settings are applied for all projects and not per workspace.

The plan is to move more to be configured per workspace. Which ones are "missing" for you?

[guidsdo]

Thank you for your quick response! Well, I couldn't get a tsconfig.json and import_map.json working per workspace. Do you have an example of this working or don't I understand your answer?

[guidsdo]

Ah we do understand eachother correctly. I'm missing the following settings for a workspace:

• tsconfig.json (wjhich is called deno.config)
• import_map.json (which is called deno.importMap)
• unstable ("deno.unstable")

If you want more input, please let me know

[johnspurlock]

@guidsdo have you tried multi-root workspaces? This is vscode's way of isolating different project settings (per-root) within a single vscode workspace.

The deno plugin actually supports overriding some project config at the individual root level, but unfortunately deno.config is not one of the settings you can override.

Allowing separate deno.config per project root would solve this problem nicely, but I wonder if it's a limitation of the language server?

[guidsdo]

@johnspurlock yes I've tried that and the whole point of this request is to support multiple deno.configs, be it per workspace or combined.

I can't imagine it being a limitation of the language server, since you can actually setup a language client per workspace. Currently I'm trying to set this up in a demo plugin with the little time I have available currently.

[kitsonk]

I can't imagine it being a limitation of the language server, since you can actually setup a language client per workspace.

In multi-root workspaces, there is only one language server and one client. Basically they are "per window". So it is a limitation of the language server.