Don't fail on ts compile when running a script ?

[yhuang0]

If I want to run my script via "deno run foo.js" and foo.js depends on a ts library that emits perfectly working js code but has a compiler error, deno shouldn't fail prematurely during the compile step and instead run my script with the emitted js file.

Typescript always emits code by default and you have to override that behavior with noEmitOnError. Shouldn't deno allow you to keep running your scripts?

[ry]

—no-type-check ?

[kitsonk]

@ry I would advise against that... there is // @ts-ignore (which I know works) and // @ts-nocheck (which I am not sure about) pragmas which we should be able to adjust the cases.

Throwing out the whole type checking is like saying to the V8 runtime to ignore syntax errors... 😢

[yhuang0]

@ry That would fix my current use case, but I would also suggest an option to remove checks entirely (if the tsc emits valid js, that's what is run.) I can imagine using third party libs that don't pass the compiler 100% (maybe deno's typescript is a different version, idk). If I'm scripting I don't want my entire script to break because of a compiler error.

@kitsonk A V8 runtime with no errors... it would start assuming what you meant. Would that be bad? idk :)

[ry]

Is there a corresponding tsc option? I'd rather not invent names --nocheck ?

@kitsonk You might want this for starting up quickly.

[rsp]

@ry there are // @ts-nocheck comments (microsoft/TypeScript#33383) that should be supported in 3.7 but there is no corresponding tsc option yet.

As for the option name, people are asking for --transpileOnly (microsoft/TypeScript#29651) and there is a typescript-transpile-only project which claims to be "a quick, 1 hour hack to write a tsc alternative that compiles your code just like tsc but skips typechecking" so this transpileOnly seems to be a popular name now, hard to tell if it's going to be the same when (if) it lands. To match the // @ts-nocheck the --nocheck or --noCheck would seem more consistent.

[kitsonk]

I agree, there is the concept of transpile only. There is a slightly loose version of the compiler that is the no default lib check.

I guess if there ends up being a transpile only on the compiler, we would want to support it, but we would want to support it through tsconfig if it becomes a compiler feature.

[kitsonk]

Wesley (TypeScript core team) pointed out that we can use ts.transpile() to do a transpile only. While I still personally think it is a big 👣 🔫, it should be fairly easy to support. The issue @rsp mentions is effectively integrating that into tsc, so it isn't supported in the Compiler Options, but would be easy to do for us, but then would make a Deno flag of --transpile-only the best way to add the functionality.

[ry]

ts.transpile might be useful for the REPL too /cc @kevinkassimo

[kitsonk]

yeah, still a bit more complicated, because you only want to run the changes between the last transpile (REPL command) and the current, but it could be a step in the right direction.

[rsp]

There is also a TypeScript preset for Babel that I believe just erases the types without compiling (as opposed to tsc compiling and ignoring errors, as I understand it) which may be a much faster approach in getting JS out of known good TS (one possible use case) or even getting a try-at-your-own-risk JS out of known bad TS (for development, debugging, testing, quick hacks).

Babel won't perform type-checking on TypeScript code; it will only be transforming your code, and it will compile regardless of whether type errors are present.

From https://devblogs.microsoft.com/typescript/typescript-and-babel-7/

There are actually two Babel preset and plugin, one is using the other:

• https://babeljs.io/docs/en/babel-preset-typescript
• https://babeljs.io/docs/en/babel-plugin-transform-typescript

They don’t have the ability to do any type checking so I guess they should have a potential to be much faster and simpler. Maybe a type-erasing fast path based on type erasing babel-style instead od using internal tsc would be a possible optimization for the future dor things like std modules etc.?

[bartlomieju]

@rsp this is interesting, I had another idea as well. TS can emit declaration files alongside JS, which we could cache as well along with compiled output and sourcemap.

Then when you compile a script and you find a dependency that has declarations file in cache you substitute source file with declaration file (just like we do using // @deno-types pragma).

[rsp]

@ry @kitsonk is it possible to optimize the repl in a way that vscode is working? It uses tsserver (which is tsc working in a different mode optimized for interactive work) and it can recompile on every keystroke, of course recompiling only what’s needed because of time constrains.

Anders Hejlsberg explains it in this part of his video on modern compilers very well. Maybe a repl can use a similar approach?

[rsp]

@bartlomieju Interesting. Some time ago I was also thinking about services like deno.land/x serving (or redirecting to) a .js/.d.ts combo in addition to .ts source of files that are compiled and cached on the server (github, cdn, whatever).

Let’s say that a cli switch like —prebuilt or something adds a special header or query param in http requests and if that header/param is recognized by the server it returns a compiled version of js plus type definitions.

If the header/param is not recognized then you get a normal ts file and nothing changes, but if it is supported then it could speed up loading libraries even more than erasing types or compiler optimization.

Update: I mean it with addition to what you are describing here, not instead of.

[solson]

This should be closed due to #6456. For example:

$ cat foo.ts
export function f(x: string): number { return x; }

$ cat bar.js
import { f } from "./foo.ts";
console.log(f("test"));

$ deno run bar.js
Check file:///home/scott/tmp/bar.js
error: TS2322 [ERROR]: Type 'string' is not assignable to type 'number'.
export function f(x: string): number { return x; }
                                       ~~~~~~~~~
    at file:///home/scott/tmp/foo.ts:1:40

$ deno run --no-check bar.js
test

[moodmosaic]

Can this flag be used when embedding deno?

[kitsonk]

deno_core has no ability to type check TypeScript. If you are referring to deno compile, it accepts the flag as the subcommand, and irrespective of it being enabled or not, will no longer type check code on the resulting binary.

[moodmosaic]

Thank you, @kitsonk. I guess all I need then is to pull the latest from upstream in hirosystems/clarinet#282 since it appears as they're using an older version of deno currently.