Deno: add section for beginners on how to configure dev env.

[manyuanrong]

I recommend adding a section on configuring the Deno IDE development environment to the document.

Because now some people have begun to try Deno, which is worth our pleasure.
But Deno's current development experience is not good, which is limited by some problems in the ides and TypeScript working environment.

such as:

• Vscode automatically introduces modules in the same path without starting with ". /".
• The introduction path cannot end with ". ts", which conflicts with Deno. This prevents the use of the editor's automatic tracing feature.

So it's frustrating for Deno's experimenters, making it easier for more people to get started, and finding more bugs when using Deno.

[TomasHubelbauer]

I just asked a Stack Overflow question which I think would have been answered by such a guide and I'd certainly welcome a little more hand-holding when it comes to configuring VS Code to be a comfortable Deno IDE. I am pretty psyched about Deno in any case, but I also think that a good IDE experience is key in keeping many people interested in helping the project grow.

[kitsonk]

I would have no problem with my article (https://medium.com/@kitsonk/develop-with-deno-and-visual-studio-code-225ce7c5b1ba) being adapted to something more formal on the deno.land website. When configured properly, it is a very easy environment. There were some changes in the 0.3.0 that impact the configuration (the cached has moved).

It is arguable though, that it is and needs to be a community driven situation. Just to give a comparative, Node.js guides do not include any guide on how to setup an IDE: https://nodejs.org/en/docs/guides/. All of that information is provided by the wider community.

[galkowskit]

The issue I have with the above solution is that, while it works great, it adds node_modules, package.json, tsconfig, etc. Things I'd like to avoid while using Deno. If I have to have those - I'm a step away from just using Node.js. I think it would be perfect to be able to setup a development environment without having Node.js installed at all.

Is there currently any way of achieving that and not getting tons of TypeScript errors?

I know it's pretty idealistic and unrealistic at this stage but maybe some push towards better upstream support in VSCode or WebStorm? They could import the types for build-in Deno stuff like they do for built-in Node stuff.

[nayeemrmn]

We have https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno now. People find it like any language extension on their own (besides confusion with @justjavac's one). I think this can be closed.

[justjavac]

We have https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno now. People find it like any language extension on their own (besides confusion with @justjavac's one). I think this can be closed.

I haven't updated this vscode extension for a long time. Now I have time to completely rewrite this vscode extension before Deno 1.0 is released.

[jsejcksn]

I'd like to know how to setup typescript-eslint as my linter and formatter with deno (without using the extension) and not get any linting/ts errors.

[justjavac]

I'd like to know how to setup typescript-eslint as my linter and formatter with deno (without using the extension) and not get any linting/ts errors.

an eslint plugin may be helpful, I will write it

[justjavac]

@jsejcksn If your value is the following error:

An import path cannot end with a '.ts' extension. Consider importing './a' instead.ts(2691)

The eslint plugin can't help, because this is a typescript error. I wrote a typescript-deno-plugin to solve this problem.

[jsejcksn]

@justjavac How can we make sure that the Deno declaration files and globals being used by a plugin are exactly the same as what would be generated by the currently installed version of Deno using deno types? This seems important.

[justjavac]

@jsejcksn If DENO_DIR environment variable is defined, the plugin will use $DENO_DIR/lib.deno.d.ts, otherwise $HOME/.deno/lib.deno.d.ts. If none exist, fall back to lib.deno.d.ts built in the plugin(the latest version).

manually run:

echo $DENO_DIR
# if output nothing, then
deno types > $HOME/.deno/lib.deno.d.ts
# if output somthing, then
deno types > $DENO_DIR/lib.deno.d.ts

[jsejcksn]

@justjavac Here is another case to think about:

Having multiple instances of the plugin running at the same time with scripts using different versions of Deno

For example, working on two different projects (one using Deno 0.42.0 and one using 1.0.0) and having each project open in a separate VS Code window.

[justjavac]

@jsejcksn This can be solved by adding a configuration to the plugin (the previous version just deleted this configuration item :joy:)

{
  "compilerOptions": {
    "plugins": [
      {
        "name": "typescript-deno-plugin",
        "dtsPath": "/path/to/deno/lib.deno.d.ts"
      }
    ]
  }
}

---

I am also considering the multi-version support for vscode extension. At present, the deno language server uses the extension's bundled typescript version. This ts version may be different from deno. In the future, it will be rewritten so that the deno language server can use the correct ts version.

I am also thinking about whether to rewrite LSP's server side with Deno itself.

The vscode extension has been moved to denoland/vscode_deno, if you have any better ideas, you can go there to discuss, welcome.

[lucacasonato]

@manyuanrong Can this be closed? There is a section about editor integrations in the manual now: https://deno.land/manual/getting_started/setup_your_environment#editors-and-ides