Ability to include or exclude files to be enabled by a filter in the configuration

[dsherret]

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

Disabling Deno for certain files currently requires setting up multiple vscode workspaces. This can be a bit extreme to setup for certain projects especially considering it takes multiple config files. It would be useful to be able to specify in the config to include or exclude certain files.

cc @kitsonk - we're going to want to get this one in or a similar solution next week (see deploy channel for more details). I believe this is just an extension side change we could make?

[kitsonk]

No, it is quite a bit more complicated than that. We should have a chat. Because there is the enablement/disablement with the built in language server, as well as the enablement/disablement in the lsp.

This was extensively discussed in #314, which we closed with workspace folders, but then there was a lot of other discussion about it.

The protocol allows "per resource" enablement/disablement, it is just the vscode doesn't actually support per resource configuration/globbing/etc. If we overlay something on top of it, there are challenges about how we ensure correct editor behaviour.

We should discuss further next week "face-to-face" because it isn't straightforward.

[dsherret]

@kitsonk what if we had a “deno.cwd” setting so people could do ”deno.cwd”: “./backend”? (Would that be easier?) Or more complicated and if possible have the ability for the vscode plugin to understand folder scoped configuration rather than workspace scoped config?

cc @lucacasonato

[kitsonk]

I would say we could experiment with "deno.enable" taking a true, false, or a string path, which would use the workspace root as a base. Keeping it as a simple target plus its subdirectories should help. I can work on it this week and see if I run into any issues.

[dsherret]

Oh, that’s a good idea! Thanks!

[kitsonk]

Hmmm... that is pretty clunky actually, because it disables the ability to edit it using the GUI.

I think deno.enablePathOnly would be better, where basically if it is set, the value of deno.enable will be ignored. Still would use the workspace root as the base.

[kitsonk]

Ok, I changed my mind again... deno.enablePathsOnly which takes a string[]. The implementation in vscode_deno is about the same, and having only one path feels like it could immediately result in needing to add the support anyways. The UI to edit it is clean, as they provide a UI for string[]. I have it working on the vscode_deno side, need to implement it in the Deno language server.

[maxime1992]

Hello, does this feature supports a glob pattern?

My use case is the following:

| ci <-- has only deno scripts
| apps <-- has only "regular" TS at the exception of 1 file per app that is a deno script

So basically I've done this: "deno.enablePaths": ["./ci", "**/*ci.deno.ts"]

While it works for the ci folder, it doesn't work for all the ci.deno.ts files that are in each apps folders.

[kitsonk]

No, glob paths dramatically increase the complexity of how to manage the language server. Only path base segmentation is supported for now (any likely in the future).