[mcintyre1994]

Does this mean that their standard lib won’t have types, in the same way that Node’s doesn’t? I’m not entirely sure how it works but VSCode seems to have types for the Node standard library somehow and it’s really helpful. I assume that’s Microsoft’s work so does this basically mean that unless Microsoft do the same thing for Deno it’ll be a worse editing experience compared to Node in VSCode?

Or would the Typescript internals not have been available in that way anyway? It just seems hard to compete on ease of use with Node in VSCode without whatever magic is making the editor so smart - which I assume is something to do with Typescript.

[davnicwil]

No - you don't have to write the code in Typescript to get types - you can manually write type definitions for Javascript code.

In this case it would be even easier since it's already in Typescript and would presumably be a straight port, so all of those type definitions can be automatically generated from the existing code and will just work.

[mcintyre1994]

I was going by this quote:

> ry So - to make a long story short - we're removing the types from internal code and making it pure JS this reduces complexity and helps us ship a faster product. I acknowledge it's unfortunate to lose the type information, but it's really masking larger problems. It's not going to happen immediately tho. We have a bit more work to figure out how exactly it should be done. It's not going to be one big 9000 line file either. But it might not be ES modules. depending on if we can make that work or not.

The “lose the type information” there suggested to me that they’re not planning to ship them at all.

[davnicwil]

I think that's in reference to losing the type information for their own development of that code. I'm almost certain they don't mean they will stop shipping type definitions for the public APIs.