Ts-node: [Feature Request] Compile-only option?

[kkimdev]

I think it will be helpful to have a compile-only option for ts-node. For example, it can be used in Travis-CI script to test if it compiles successfully.

[blakeembrey]

So tsc?

[blakeembrey]

This feature won't ever exist as part of ts-node, it's incompatible with the general concept of adding to the node require loader. If you want to compile code, that's really the domain of the TypeScript compiler itself.

[kumar303]

So tsc?

How do you simulate all of the options passed to tsc? It's actually quite difficult to keep this in sync with the real ts-node. I agree that a compile-only option would be very helpful.

My team recently grappled with a subtle bug where the call to urllib.format() is invalid but only when run from ts-node. I tried running tsc with everything I see in the default options then accounting for config fixes and then applying the same -O object passed to ts-node and I still cannot reproduce the compilation error with tsc. Even if I were successful at simulating the ts-node config, it could go stale in new versions of ts-node. Simulating ts-node seems like the wrong way to go about it.

[blakeembrey]

What was the error you had? I’m open to learning more about your use-case. What’s the issue, however, with just using ts-node in this case?

[kumar303]

What was the error you had?

src/api/index.tsx:94:24 - error TS2345: Argument of type '{ query: { [x: string]: string | number | boolean | void | null; }; }' is not assignable to parameter of type 'string | UrlObject'.
  Type '{ query: { [x: string]: string | number | boolean | void | null; }; }' is not assignable to type 'UrlObject'.
    Types of property 'query' are incompatible.
      Type '{ [x: string]: string | number | boolean | void | null; }' is not assignable to type 'string | ParsedUrlQueryInput | null | undefined'.
        Type '{ [x: string]: string | number | boolean | void | null; }' is not assignable to type 'string'.

94   return urllib.format({ query: resolvedQuery });

When we changed the type to use undefined instead of void the error went away 🤷‍♀

Example:

{ [x: string]: string | number | boolean | undefined | null; }

What’s the issue, however, with just using ts-node in this case?

The only file we run in ts-node is scripts/server.tsx (it starts a server) and this was causing the compilation error in production.

Yes, we did solve it by executing this file with ts-node in CI but the same CI task has to then kill the server after it starts. We could add some extra code and execute scripts/server.tsx with --do-not-actually-start-a-server but why?

Running ts-node --compile-only scripts/server.tsx is exactly what we need here.

I still don't understand why I can't reproduce the compilation error with tsc but even if I could, simulating ts-node with tsc seems like a fragile solution.

[blakeembrey]

Sounds reasonable :+1: I'd be happy to support a PR to land a switch between --transpile-only or --check to ts-node.

[blakeembrey]

There's a related issue for this feature BTW: https://github.com/TypeStrong/ts-node/issues/741 (not compiling output, but doing the compilation check like tsc). Most likely ts-node will never 100% replicate tsc, but at least type checking it should be easy enough.