Roadmap 2

[lucacasonato]

Now that most burning fires have been put out #121 can be closed and it is time for a new roadmap. The goals for the next few weeks and months should be stabilizing the extension, improving compatibility with mixed Node + Deno projects, and making the extension more easy to use. Here are some ideas in rough order of priority (top is most important):

• editor.defaultFormatter should not be hijacked by deno fmt
• Implement "deno.include" setting to enable the extension on files matching this path. not possible until deno lsp
• Implement "deno.exclude" setting to disable the extension on files matching this path. not possible until deno lsp
• Various improvements to language server. (improve Deno Language Server #187)
• Add Deno debugging configuration.
• Re-add Enable Deno and Disable Deno commands to quickly switch "deno.enable" in .vscode/settings.json. ([regression] deno enable/disable command palette entries removed #170)
  • This was instead covered by Init command.
• Support re-exports from files like deps.ts for autocomplete.
• Support configuration in workspace and user settings, not just project settings.

And various high priority bugs that need to be fixed:

• Syntax highlighting is somewhat broken (Patching 2.0.10 -> 2.0.13 breaks colorization #150)
• @deno-types does not work on first load (@deno-types does not work on first load #97)

---

The future goal is still to integrate LSP into the deno binary.

[brandonkal]

Nice. Also
#124
#113
are still bugs.
-1 on a toggle command. There are many existing generic settings toggle solutions so no need to reimplement the wheel there.

I'd also love a deno.enable auto where a file is recognized as Deno if it contains the string "Deno" (either as namespace usage or in a comment).

[CGQAQ]

@lucacasonato Please create an issue for each item in the checklist, so I can reference in pr, or give me permission somehow to allow me to change to the description of this issue

[callionica]

If console.log isn't writing to the VS Code debugger output pane, it's hard to see the VS Code integration as working, so it'd be great to get the fix to Deno #4502

denoland/deno#4502

Maybe this is covered by the debugging item?

[nayeemrmn]

@callionica That's independent of VSCode integration, since the same issue will occur with Chrome devtools for instance.

[callionica]

@nayeemrmn Yeah, I recognise that it's under a different repo. I hope this roadmap is being used to show the path to completing specific customer scenarios and fulfilling user expectations. That's a good way to prioritise where to put your resources.

My point is that a basic user expectation of being able to write Deno code in VS Code is that you can step debug with output going to the integrated debugger window. Currently that user expectation is not being met. And it's such a core part of the experience that meeting that expectation should be prioritised and resourced along with these other features.

Sometimes roadmaps will show dependencies on other teams/feature areas. For me, that's a necessary part of prioritisation and communication.

[CGQAQ]

@lucacasonato First one should be checked due to #193 closed, in fact, fmt is not been hijacked at all.
See this: microsoft/vscode#106376

[jeiea]

denoland/deno#8400
It seems deno lsp is implemented. Is there any blocker still left?

[lucacasonato]

@jeiea Yes, the LSP is still not at feature parity with current extension. Only once that is the case will we switch.

[lucacasonato]

We now use deno lsp in version 3.x of the extension. The roadmap issue for lsp is denoland/deno#8643. Closing this issue.