kitsonk

Yeah, I would be interested to understand what challenges you had with oak too.

std library is still considered "unstable" and the sub modules contained in there tend to have their own lifecycle as well. There has been effort to try to mature std to get to a stable version, which means cleaning up lots of things that would detract from long term maintainability.

VSCode is the only integration that the Deno core team maintains and develops. A rough poll indicates that about 80% of Deno users use vscode.

JetBrains/WebStorm now utilises the Deno language server directly (the same one that the VSCode integration uses) but they control how features are expressed in their client and when they deliver them, something the core team can't directly control.

So for various reasons, VSCode ends up being the focus.

The author of Just-JS is working on Deno as well.

I would argue it isn't very custom. Using fully qualified URLs predates Node.js and CommonJS. It was also one of the big debates when we all were doing AMD. Node.js has realised that _mistake_ of eliding extensions and is headed that direction as well.

We have been adding a Node.js compatibility mode, but I am not sure that qualifies as "_very_ custom module resolution".

Both the triple-slash reference and @deno-types were solutions to problems to not have opaque type resolution with TypeScript. They do not impact the runtime resolution, only the type check resolution. Instead of opaquely searching for these by reading the `package.json` and probing the file system like `tsc`, Deno is explicit.

I would be glad to work with you to explore how we can figure out how to resolve your implementor concerns. The door has been open for a long time, and I have mentioned it in passing to Daniel a couple times. Let me know if you would like to talk.