Unable to configure correctly a workspace with Deno and Typescript compiler

[llgcode]

Hi,
I have a client with typescript files transpiled with Typescript compiler. And a server that uses Deno as a runtime.
But it's not working, see the screenshot below. I've created a repository that reproduce the issue llgcode/deno-client-server-ts-template.

I've set deno.enable: true in server/.vscode/settings.json as defined by your documentation workspaceFolders.md.

I've seen these closed issues #448 and #297 that seems to be a duplicate of mine.

Regards.

[kitsonk]

Can you please provide the output of View | Output and then the Deno Language Server drop down and then also the first section of output from Deno: Language Server Status from the command pallette.

[llgcode]

Output view:

Starting Deno language server...
version: 1.16.3 (release, x86_64-pc-windows-msvc)
executable: C:\Users\xxx.deno\bin\deno.EXE
Connected to "Visual Studio Code" 1.62.3
language server initialized
Server ready.

Deno Language Server Status
Workspace Settings

{
  "enable": false,
  "cache": null,
  "config": null,
  "importMap": null,
  "codeLens": {
    "implementations": false,
    "references": false,
    "referencesAllFunctions": false,
    "test": true
  },
  "internalDebug": false,
  "lint": false,
  "suggest": {
    "completeFunctionCalls": false,
    "names": true,
    "paths": true,
    "autoImports": true,
    "imports": {
      "autoDiscover": true,
      "hosts": {
        "https://deno.land": false
      }
    }
  },
  "unstable": false
}

You can also quickly clone the project, it's a simple template project with no dependency in it.
Thanks

[kitsonk]

The project is not enabled for deno, as indicated by the configuration. This is likely because your workspace root is one level up from where the configuration is stored, and VSCode is not finding it.

What happens when you go to Settings and change the Workspace tab and choose to enable Deno there (or use Deno: Initialize Workspace Configuration from the command palette)?

[llgcode]

When enabling globally, typescript client file have issues because they seems to be checked by deno extension.

note that I'm just using this doc as a reference:
https://deno.land/manual@main/vscode_deno#workspace-folders

[kitsonk]

I didn't suggest enabling globally, suggested enabling it for the workspace.

You haven't setup a multi-root workspace, as per the vscode documentstion: https://code.visualstudio.com/docs/editor/multi-root-workspaces. You have setup a sub folder of a workspace with some config, which is not how multi workspaces work.

[llgcode]

Hi @kitsonk, this is already a multi workspace see workspace.code-workspace and I open it using this file. Have you got a sample that work?

[kitsonk]

I just tried with this project locally: https://github.com/kitsonk/multi-root and everything works as expected, the /server/ code is checked by Deno and the client code is checked with the buil-in language support.

[nhrones]

Not working on VSCode on Windows.
I downloaded your example, opened workspace.code-workspace in vscode

This does not work for me.
server.test.ts errors with ...

An import path cannot end with a '.ts' extension. Consider importing 'https://deno.land/std/testing/asserts' instead.ts(2691)

The setting.json has an error ...

Unknown Configuration Setting

It seems you can only set Deno extension to work on the Workspace, not a folder in the workspace!
This takes care of the errors above, but now the client is a Deno folder!

// client.index.js
Unable to load a local module: "file:///C:/Users/nhron/Desktop/temp-work/multi-root/client/common".
  Please check the file path.deno(no-local)

[kitsonk]

@dsherret could you check the example project on windows?

[llgcode]

on my side:

[nhrones]

To enable multi-root, how should the Deno extension be configured?

a. Enabled Globally
b. Disabled Globally
c. Enabled Workspace
d. Disabled Workspace

With the extension set to enabled Workspace, Deno is enabled for the entire multi-root workspace, even with:
server.vscode.setting.json = "deno.enable": true
client.vscode.setting.json = "deno.enable": false

If you set "deno.enable": true in the workspace.code-workspace file, Deno is enabled in both client and server folders?

With any of these configuration options, Deno is either enabled in both server and client, or neither server nor client.
What could I be doing wrong?

[nhrones]

On Windows, the following multi-root configuration is now working for me:
In VScode, the Deno extension is set to enabled globally

// workspace.code-workspace file
{
	"folders": [
		{
			"path": "server"
		},
		{
			"path": "client"
		}
    ],
    "settings": {
        "deno.enable": true,
    }
}

// server.vscode.settings.config
{
"deno.enable": true
}

// client.vscode.settings.config
{
"deno.enable": false
}

Also, changes to any of the 3 config files required a restart of VSCode for the results to take effect!

[mathe42]

I have the same problem and @nhrones doesn't fix it for me as the typescript service for the not Deno part is not enabled. I get syntaxhihlighting but nothing more.

As this semes to be a windows only bug so I think this could be a path problem as windows uses often \ and not / as path seperator...

[luisnoresv]

On mac os i put the workspace on the root folder after i install the app and then i reload vsCode
I use this simple configuration

{ "folders": [ { "path": "." } ], "settings": {"deno.enable" : true} }

[snarfblam]

I have the same problem and @nhrones doesn't fix it for me as the typescript service for the not Deno part is not enabled. I get syntaxhihlighting but nothing more.

As this semes to be a windows only bug so I think this could be a path problem as windows uses often \ and not / as path seperator...

Same here. I can only get one of two things to happen. Either Deno is enabled globally and works for Deno roots but there is no language server available for non-Deno roots, or Deno is not enabled globally and Deno roots are checked by the normal Typescript language server. There seems to be no way of fixing one without breaking the other.

Is there a definitive guide to setting up a multiroot workspace with Deno?

[mathe42]

I never got it working I use multiple vscode instances

[ragrag]

any updates or workarounds for this one? seems to still be a problem.
using windows with deno.enablePaths will make the paths defined work normally for Deno but other paths will not be working as expected with the built in TypeScript language server

[evelant]

Other issue I filed got closed so I'll add details here. I'm not using a multi-root workspace, I'm only using enablePaths with this configuration:

   "deno.enable": true,
    "deno.unstable": false,
    "deno.enablePaths": [
        "./supabase/functions/",
    ],
    "deno.config": "./supabase/functions/deno.jsonc",

It seems as though this bug has resurfaced: #668

With this configuration the Deno language server appears to ignore enablePaths and auto-loads the package.json from the parent directory ( Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json")

When I attempt to edit Deno code it appears as though the TS LSP and the Deno LSP are "fighting" each other -- errors are highlighted, disappear, invalid errors are highlighted, disappear, errors are highlighted again, and so on. Sometimes it settles down after a time but as soon as one character is changed in the file it happens again.

Deno LSP output:

Starting Deno language server...
  version: 1.33.2 (release, aarch64-apple-darwin)
  executable: /Users/imagio/.cargo/bin/deno
Connected to "Visual Studio Code" 1.80.0
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
Enabling import suggestions for: https://deno.land
Server ready.
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
Warning: "options" configuration is deprecated. Please use "flat" options instead.
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
Enabling import suggestions for: https://deno.land
Setting Deno configuration from: "./supabase/functions/deno.jsonc"
  Resolved configuration file: "file:///Users/imagio/dev/myproj/supabase/functions/deno.jsonc"
  Auto-resolved package.json: "file:///Users/imagio/dev/myproj/package.json"
Setting import map from configuration file: "./import_map.json"
  Resolved import map: "file:///Users/imagio/dev/myproj/supabase/functions/import_map.json"
client asked to cancel request 136, but no such pending request exists, ignoring
client asked to cancel request 135, but no such pending request exists, ignoring
client asked to cancel request 138, but no such pending request exists, ignoring
successfully cancelled request with ID: 141
successfully cancelled request with ID: 142
successfully cancelled request with ID: 143
successfully cancelled request with ID: 144
successfully cancelled request with ID: 145
successfully cancelled request with ID: 139
client asked to cancel request 140, but no such pending request exists, ignoring

I'm guessing the client asked to cancel request 136, but no such pending request exists, ignoring might be indicative of the problem.

[nayeemrmn]

We have deno.enablePaths, deno.disablePaths, #488 open for auto-detection. Closing in favour of that one.