3 ms·

> I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up if VS Code already support

• d4mi3n 4y ago
  The ability to infer types from NPM packages. If you have existing codebases with non-trivial apps, reworking all your dependencies makes the prospect of picking up Deno a non-starter. My understanding is prior to this release the Deno LSP didn’t have visibility into types from packages originating from NPM. Compatibility issues likely still exist, but I suspect the scope of work for an MVP substitution of Node for Deno is in the realm of possibility now when it wasn’t before.
• brundolf 4y ago
  Deno has its own language server, unfortunately. This is necessary because of a few key aspects of Deno code that are incompatible with the regular TypeScript support, and it means Deno's editor integration is often a step behind mainline TypeScript
• justinmchase 4y ago
  It did still partially work but there was some friction with resolving types from ESM modules. For example in typescript+node if you're importing another module with esm you'd still have to import javascript like so: ``` import { Example } from "./example.js" // the actual file is example.ts ``` While in Deno you actually import the typescript file ``` import { Example } from "./example.ts" ``` That difference alone was enough to trip up the built-in typescript language tool and add friction. Another thing is that Deno has a built in formatter / linter, you don't use a 3rd party tool like eslint, so having the ide just know how to do the linting and formatting is nice, the default typescript language plugin can't do that. Also, Deno formats other file types including json, yaml and markdown.