Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deno support #1426

Open
MichalLytek opened this issue Feb 28, 2023 · 7 comments
Open

Deno support #1426

MichalLytek opened this issue Feb 28, 2023 · 7 comments
Assignees
Labels
Enhancement 🆕 New feature or request
Milestone

Comments

@MichalLytek
Copy link
Owner

It might be worth considering, as now Deno should have better interoperability with npm.
https://deno.com/blog/v1.31

Maybe examples are enough, maybe we need to abstract some things and release proper package on deno land 👀

@MichalLytek MichalLytek added the Enhancement 🆕 New feature or request label Feb 28, 2023
@MichalLytek MichalLytek added this to the 2.x versions milestone Feb 28, 2023
@MichalLytek MichalLytek self-assigned this Feb 28, 2023
@hazelnutcloud
Copy link

would definitely love having deno support!

@carlocorradini
Copy link
Contributor

As far as I can see, an example should be enough.
Can anyone with Deno experience build a simple example?

@ClaudiuCeia
Copy link

@carlocorradini it feels like the biggest issue might be with the reflection usage and tsconfig options. I'll try to put a demo together and see how it goes.

@ClaudiuCeia
Copy link

Ok, looks like it's almost there just by using the npm specifier for imports. For the unpatient:

// main.ts
import "npm:reflect-metadata";
import { graphql } from "npm:graphql@16.8.1";  
import { buildSchema, /* ... */ } from "npm:type-graphql@2.0.0-beta.3";

// everything works out of the box like in the examples

And compiler options in deno.json:

{
  "compilerOptions": {
    "strictPropertyInitialization": false,
    "emitDecoratorMetadata": true
  },
}

Note that decorators come by default with Deno. Also, I'm personally not a big fan of strictPropertyInitialization. It's only there to allow defining various object types, like:

@InputType()
class NewRecipeInput {
  @Field()
  title: string;
}

Without the option, TS would (rightfully) complain that title is optional, since it has no initializer. An alternative to disabling this check in the full codebase would be to assert only for places where these are defined, ie:

@InputType()
class NewRecipeInput {
  @Field()
  title!: string; // added the ! operator
}

I haven't tested older versions, but I think someone taking on Deno as a runtime would probably prefer jumping on the type-graphql 2.0 train. I had a bit of trouble here using the latest beta version. The release documents graphql 16.7.1 as a peer dependency but it actually only works with 16.8.1 from what I can see.


I have a GraphQL project with Deno where I'd like to use type-graphql. Depending on availability I could try to contribute to docs and come back to this thread if I hit any roadblocks for the more complex functionality.

@esalazarv
Copy link

Ok, looks like it's almost there just by using the npm specifier for imports. For the unpatient:

// main.ts
import "npm:reflect-metadata";
import { graphql } from "npm:graphql@16.8.1";  
import { buildSchema, /* ... */ } from "npm:type-graphql@2.0.0-beta.3";

// everything works out of the box like in the examples

And compiler options in deno.json:

{
  "compilerOptions": {
    "strictPropertyInitialization": false,
    "emitDecoratorMetadata": true
  },
}

Note that decorators come by default with Deno. Also, I'm personally not a big fan of strictPropertyInitialization. It's only there to allow defining various object types, like:

@InputType()
class NewRecipeInput {
  @Field()
  title: string;
}

Without the option, TS would (rightfully) complain that title is optional, since it has no initializer. An alternative to disabling this check in the full codebase would be to assert only for places where these are defined, ie:

@InputType()
class NewRecipeInput {
  @Field()
  title!: string; // added the ! operator
}

I haven't tested older versions, but I think someone taking on Deno as a runtime would probably prefer jumping on the type-graphql 2.0 train. I had a bit of trouble here using the latest beta version. The release documents graphql 16.7.1 as a peer dependency but it actually only works with 16.8.1 from what I can see.

I have a GraphQL project with Deno where I'd like to use type-graphql. Depending on availability I could try to contribute to docs and come back to this thread if I hit any roadblocks for the more complex functionality.

Hi @ClaudiuCeia, thanks for the example, however seems it is not working properly, I'm trying to use @Args and @Arg decorators in supabase edge functions without get it works. I guess it is related to the new way to handle decorators in Typescript 5 but I'm not sure.

I get this error

error: Uncaught (in promise) Error: Unable to infer GraphQL type from TypeScript reflection system. You need to provide explicit type for parameter #0 of 'programs' of 'ProgramsResolver' class.
    at findType (file:///Users/eduardo/Library/Caches/deno/npm/registry.npmjs.org/type-graphql/2.0.0-beta.3/build/esm/helpers/findType.js:22:15)
    at getParamInfo (file:///Users/eduardo/Library/Caches/deno/npm/registry.npmjs.org/type-graphql/2.0.0-beta.3/build/esm/helpers/params.js:7:38)
    at file:///Users/eduardo/Library/Caches/deno/npm/registry.npmjs.org/type-graphql/2.0.0-beta.3/build/esm/decorators/Args.js:9:16
    at file:///Users/eduardo/Code/jules/rebates/supabase/functions/graphql/resolvers/programs.resolver.ts:9:5
    at DecorateProperty (file:///Users/eduardo/Library/Caches/deno/npm/registry.npmjs.org/reflect-metadata/0.2.1/Reflect.js:561:33)
    at Reflect.decorate (file:///Users/eduardo/Library/Caches/deno/npm/registry.npmjs.org/reflect-metadata/0.2.1/Reflect.js:136:24)
    at _ts_decorate (file:///Users/eduardo/Code/jules/rebates/supabase/functions/graphql/resolvers/programs.resolver.ts:3:90)
    at file:///Users/eduardo/Code/jules/rebates/supabase/functions/graphql/resolvers/programs.resolver.ts:17:1

using this deno version

❯ deno --version
deno 1.39.1 (release, x86_64-apple-darwin)
v8 12.0.267.8
typescript 5.3.3

Seems for now is not usable

@ClaudiuCeia
Copy link

ClaudiuCeia commented Dec 28, 2023

@esalazarv the actual code snippet would help. I'm thinking you're running into a limitation of TS reflection rather than Deno runtime, which is documented in the docs:

For simple types (like string or boolean) this is all that's needed but due to a limitation in TypeScript's reflection, we need to provide info about generic types (like Array or Promise). So to declare the Rate[] type, we have to use the explicit [ ] syntax for array types - @field(type => [Rate]). For nested arrays, we just use the explicit [ ] notation to determine the depth of the array, e.g. @field(type => [[Int]]) would tell the compiler we expect an integer array of depth 2.

Either way, you should be able to fix it by specifying the return type in the decorator, ie:

@Arg("name", () => String)  

@esalazarv
Copy link

@esalazarv the actual code snippet would help. I'm thinking you're running into a limitation of TS reflection rather than Deno runtime, which is documented in the docs:

For simple types (like string or boolean) this is all that's needed but due to a limitation in TypeScript's reflection, we need to provide info about generic types (like Array or Promise). So to declare the Rate[] type, we have to use the explicit [ ] syntax for array types - @field(type => [Rate]). For nested arrays, we just use the explicit [ ] notation to determine the depth of the array, e.g. @field(type => [[Int]]) would tell the compiler we expect an integer array of depth 2.

Either way, you should be able to fix it by specifying the return type in the decorator, ie:

@Arg("name", () => String)  

@ClaudiuCeia Thanks for your help, I just tested and it works like a charm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement 🆕 New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants
@MichalLytek @esalazarv @carlocorradini @ClaudiuCeia @hazelnutcloud and others