add instructions on how to make deno lsp happy with deno deploy types

[ry]

cc @danopia

[kt3k]

I found the following code type checks well with lsp and deno cache:

/// <reference path="https://deno.land/x/deploy@0.2.0/types/deploy.ns.d.ts" />
/// <reference path="https://deno.land/x/deploy@0.2.0/types/deploy.fetchevent.d.ts" />
/// <reference path="https://deno.land/x/deploy@0.2.0/types/deploy.window.d.ts" />

addEventListener("fetch", (e) => {
  e.respondWith( new Response("Hello world"));
});

(Note: deploy.{ns,fetchevent,window}.d.ts is the type definitions of Deploy environment)

But I don't know if it's an ideal way to type Deploy scripts. (I even don't understand why this works. https://deno.land/x/deploy@0.2.0/types/deploy.window.d.ts contains definitions which conflicts with deno's internal dom lib. But deno stops using internal dom lib when it finds reference path entry)

[ChristianSiegert]

The solution by @kt3k does not work for me in VSCode … but a slight variation does:

Save deployctl types in your project:

$ deployctl types > deploy.d.ts

Reference these types:

/// <reference path="./deploy.d.ts" />

addEventListener("fetch", (event: FetchEvent) => {
  event.respondWith(new Response("Hello world"));
});

To check or run the code:

$ deployctl check --libs="" main.ts
$ deployctl run --libs="" main.ts

Also make sure the Deno extension (denoland.vscode-deno) is enabled for your workspace in VSCode so things like import.meta are recognized.

Edit: You may have to restart your editor for the changes to be picked up.

[forgo]

I'm assuming these workarounds will become stale at some point with upgrades to deployctl or deno. Is this something that can be built-in? Maybe this is a question better suited to the VS Code Deno plugin.

Ultimately does this come back to lib.dom.d.ts not being properly typed (e.g. - FetchEvent accommodated in addEventListener)? I saw this Microsoft/TypeScript issue related to Service worker typings and I'm guessing these problems are at least tangentially related.

[forgo]

I wanted to provide a little more context on why these kinds of workarounds feel less than ideal:

I did manage to deploy a simple JSX Hello World app via GitHub integration with the Deno Deploy Dashboard while using this workaround.

Now I'm simply trying to develop that same working app locally such as:

deployctl run --libs=ns,fetchevent ./forgo.tsx

The workaround mentioned here to help VS Code understand what FetchEvent is, among other things seems to be causing issues running locally.

I can start the app, but then as soon as I try to hit localhost:8080, I get a bunch of errors in the console along the lines of, but not limited to:

TS2300 [ERROR]: Duplicate identifier 'FetchEvent'.
declare class FetchEvent extends Event {
              ~~~~~~~~~~
    at file:///~/Documents/GitHub/forgo/deploy.d.ts:1921:15

    'FetchEvent' was also declared here.
    declare class FetchEvent extends Event {
                  ~~~~~~~~~~
        at file:///~/Library/Caches/deno/https/deno.land/7467bc7663880b5339f36ee0ad6dcbcd349c2b9c396a48b4061679c3becd13b2.ts:8:15

All the conflicts are between ~/Library/Caches/deno/https/deno.land/... and the type file deploy.d.ts I created using the workaround mentioned here.

I don't really need my IDE to know what a FetchEvent type is (as much as I hate squiggly red lines in my code), so I deleted that, and the /// <reference path="./deploy.d.ts" /> and the deploy.d.ts workaround file.

After doing that, I seem to be able to render "Hello World" again locally.

I guess I mostly wanted to convey that these little workarounds to smaller issues can actually have cascading effects leading to more friction.

I'm hoping there's a better way to address this down the road.

[ChristianSiegert]

@forgo After creating deployctl types and referencing them in your program, did you also run your program according to my instructions? Specify an empty lib list when you reference deploy.d.ts:

$ deployctl run --libs="" ./forgo.tsx

[jsejcksn]

I think denoland/deno#10999 will help with addressing this.

[jsejcksn]

I think denoland/deno#10999 will help with addressing this.

Now that Deno 1.12.0 is released, this works for me in VS Code:

./tsconfig.json:

{
  "compilerOptions": {
    "types": [
      "https://deno.land/x/deploy@0.3.0/types/deploy.ns.d.ts",
      "https://deno.land/x/deploy@0.3.0/types/deploy.window.d.ts",
      "https://deno.land/x/deploy@0.3.0/types/deploy.fetchevent.d.ts"
    ]
  }
}

./.vscode/settings.json:

{
  "deno.enable": true,
  "deno.lint": true,
  "deno.unstable": false,
  "deno.config": "./tsconfig.json"
}

No more triple-slash directives needed in source files.

[lucacasonato]

Thanks for contributing by opening an issue.

This project is being archived because you can now use deno run to run your Deploy scripts locally: https://deno.com/deploy/docs/running-scripts-locally/. As such, I will close this issue.

If you have feedback about Deno Deploy, please open an issue on this repo: https://github.com/denoland/deploy_feedback