Does typegraphql require ts-node?

[shawnjones253]

Is there anything in typegraphql that relies on type information or can it run via transpiled javascript?

[carlocorradini]

No, It doesn't.
ts-node it's only used during building (development dependency).
The keys here are decorators and reflect-metadata.

[Blankeos]

Wondering this as well. I can't seem to run it with tsx. I'm also using typegraphql-prisma btw.

I'm trying to make a custom-server setup with Express + TypeGraphql + Vite. But TypeGraphQL + ESM + Vite + ESBuild feels like oil and water right now.

Running with ts-node works, but won't work when I have type: "module" in package.json.

Running with tsx keeps getting this error on startup: MichalLytek/typegraphql-prisma#369

[carlocorradini]

type-graphql version?
Did you set all flags in ts-node?
Node.js version?

[Blankeos]

Hi @carlocorradini I got it to work now lol. I'm still running it on ts-node though. So currently there's still no type: "module" in the package.json.

type-graphql is 2.0.0-rc.2

My main gripes currently are:

1. type: "module"

2. tsconfig

  "compilerOptions": {
      "module": "CommonJS",
      "moduleResolution": "Node"
   }

• If I change moduleResolution or module to anything else. It seems ts-node won't work anymore.
• If I use "type": "module" in package.json, ts-node` won't work either.
• Also, I really don't know the reason but using import { gql } @apollo/client is a bit annoying as it causes this - because apparently @apollo/client is still in CommonJS and when I import from vite, it's ESM?
  • Although one workaround worked the best for me (something about Vite's "ssr no external" config.
• Lastly, because I'm on commonjs, it seems like import.meta.env.VITE_* environment variables give ts errors (but it compiles/builds fine, which is interesting). I found a super good fix for this: https://www.npmjs.com/package/vite-plugin-env-compatible (process.env.*) works even in CJS so no ts errors whatsoever.

[carlocorradini]

Note that tsconfig should be updated to something similar (ESM):

 "compilerOptions": {
      "module": "esnext",
      "moduleResolution": "nodenext"
   }

Always use type: "module" in package.json.
ts-node should be configured for an ESM compatible environment, see https://github.com/TypeStrong/ts-node?tab=readme-ov-file#esm and https://github.com/TypeStrong/ts-node?tab=readme-ov-file#commonjs-vs-native-ecmascript-modules
Moreover I know that ts-node has some issues with newer versions of Node.js (See TypeStrong/ts-node#1997)

[Blankeos]

Yup, thanks for that. This is the exact setup I went with I think and I'm running on Node v20.14.0. I kept getting the error:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]; Unknown file extension".ts" for /Users/me/Desktop/.../my-script.ts

I will just take note of this once this issue gets fixed (by Node).

[Blankeos]

The best thing that worked that got rid of that error (according to the above issue as well):

node --loader ts-node/esm server.ts # server.ts is the file

But another issue came up:

But we have path aliases so this error came up: Error: Cannot find package '@/utils' imported from ...

# ✅ What we did previously to resolve aliases like `@/utils/**`
ts-node -r tsconfig-paths/register server.ts 

# ❌ Using node --loader with that register flag does not work though:
node --loader ts-node/esm -r tsconfig-paths/register server.ts