Snowpack: Request for CDN and snowpack: JavaScript code should contain a TypeScript triple-slash directive in addition to x-typescript-types

[KSXGitHub]

Reasons

1. While I don't know who made up x-typescript-types, I am sure that triple-slash directive is TypeScript standard.
2. Author of vscode-deno (Deno Language Server) seems to struggle with supporting both triple-slash directive and x-typescript-types (this claim is yet to be confirmed).

Proposal

If requested JavaScript file has a correspoding TypeScript definition, add <references types="/-/types.d.ts" /> to the very top of the JavaScript file.

[FredKSchott]

My understanding is that the two are conceptually different.

• <references types="/-/types.d.ts" /> says "hey, load these type declarations as well".
• x-typescript-types says "hey, these type declaration are actually MY type declarations"

In the past, these things have been better discussed on the Deno issue tracker. We're just an implementation of the spec/behavior that they've defined. /cc @kitsonk if he has any thoughts to add

[kitsonk]

Triple-slash directive in JavaScript are not recognised by the TypeScript compiler. This is why we used them in Deno. The documentation in Deno is pretty clear on how the different forms work with Deno: https://deno.land/std/manual.md#using-external-type-definitions. X-TypeScript-Types and the triple slash reference directive are effectively the same to Deno. The former does not require modifying the source, and is actually preferred.

[FredKSchott]

Ah, so I was mistaken then! Thanks for the extra info @kitsonk.

@KSXGitHub feel free to connect me with the vscode-deno maintainer(s) (or @-mention me into any convos) if they're having trouble with anything related to importing from Pika CDN. Happy to help.

[kitsonk]

I suspect the issue that @axetroy is having is related to denoland/deno#4000 which has a fix merged into master today. This impacted the triple slash directive as well.

[KSXGitHub]

X-TypeScript-Types and the triple slash reference directive are effectively the same to Deno.

Since they are the same, would it cause any trouble if a JavaScript module has both X-TypeScript-Types and <reference types="..." /> pointing to the same URL?

I suspect the issue that axetroy is having is related to denoland/deno#4000 which has a fix merged into master today. This impacted the triple slash directive as well.

Unlikely, I have workaround for this (create a deps.ts and run deno fetch deps.ts). Deno fetches type definition, uses that for typechecking, but the IDE does not.

[FredKSchott]

I'd suggest giving that latest PR fix a chance to bake a bit (looks like it was only merged to master a couple of hours ago).

[KSXGitHub]

@FredKSchott BTW, if I don't want to you cdn.pika.dev directly, instead, I want to use snowpack to generate my own Deno modules locally, how it's going to serve TypeScript definition? After all, local files don't have HTTP headers.

[KSXGitHub]

Another thing, I just noticed in https://github.com/pikapkg/snowpack/issues/264#issuecomment-609889287 that you wrote references (plural) instead of reference, this is a mistake that I also make.

[FredKSchott]

Okay, so I dug into things a bit, and now I'm confused again. The TS docs describe the functionality that I'd originally described: /// <reference types="..." /> describes a type declaration file as a dependency, not as the declarations that match the file itself. See: https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html

@kitsonk am I missing something, or are Deno and TS treating this triple-slash differently?

[kitsonk]

am I missing something, or are Deno and TS treating this triple-slash differently?

As I said before. Triple slash directives are not valid in JavaScript to the TypeScript compiler. Because of the developer familiarity though, we adopted them in Deno. I felt that it would lead to confusion, but Ry liked the ergonomics of it. The compiler simply ignores them in other runtimes (maybe tries to load them if you have "checkJs" enabled). But again, it is, in my opinion, the way to do it when you can't do X-TypeScript-Types. If we really think it leads to confusion though, we should adopt some other semantics, so people don't get confused.

[FredKSchott]

Gotcha, thanks for clarifying. I don't have any hard opinions here either way, just want to make sure I understood. Either way, I would suggest documenting this departure from TypeScript's documented behavior specifically, since I'd guess that plenty more people will read the TS docs and not realize that this is something that Deno handles differently.

[kitsonk]

For TypeScript files it handles it as normal (as in normal Deno module resolution). Though 99.9% of the time it isn't a useful behaviour in Deno. Clearly overloading it does cause confusion. Now that we have a proof point, I think we should change it before 1.0, which I will raise in Deno.