[Feature Request] Typescript compile API

[Fenzland]

One of the best features of Deno is allowing us to write JavaScript that both run at (modern) browsers and server side without building or other works. But if we write in TypeScript, that's useless for Browsers. (That's why I'd like to write codes in JS rather then TS.)

If Deno provide an API that accepts TS codes, compile them with inside compiler, and returns JS codes. We can build a web server to respond JS modules compiled from TS. Then the TS codes are cross-platform too.

Here is a suggestion:

Deno.compile( code:string, options?:CompileOption  ):Promise<string>
Deno.compileFile( filename:string, options?:CompileOption  ):Promise<string>
Deno.compileSync( code:string, options?:CompileOption  ):string
Deno.compileFileSync( filename:string, options?:CompileOption  ):string

[kitsonk]

Hmm interesting... it certainly is feasible and I can seem the potential value in it.

I do think we would need to think about it a bit more, as it is seldom a single chunk of code that needs to be transpiled. While the TypeScript compiler supports a single file transpile mode, currently the compiler APIs internally are more the project based transpilation.

We would also have to deal with things like source maps and declarations, versus just JavaScript being emitted back, as well as diagnostics being returned. So fairly complex. So it might be better to align the runtime Deno version to the couple ops we have into the compiler as it stands... It would be different from what is proposed here.

One of the other things Ry and I have chatted about is getting more direct access to the AST from TypeScript to potentially make manipulation easier (or faster if we did some in Rust), so that should be part of the consideration.

I think also #1739 would be somewhat related (or we need to identify how these would interralte.

[ry]

Yes, we absolutely should expose Deno's compilation infrastructure to users.

Maybe before tackling this, we should make sure Deno users can use TypeScript itself - see denoland/std#428

[kitsonk]

I think in the conversations that were partly related to #3321 that we should tackle this.

Doing denoland/std#428 seems somewhat tangental to this. We can't expose the built in TypeScript and the types of workloads that people are talking about here, means that a clean, more accessible compiler API would be easier to consume.

I would propose the following:

Deno.transpileOnly(sources: string[], options?: Deno.CompilerOptions): Promise<string[]>;

Deno.compile(rootName: string, sources?: Record<string, string>, options?: Deno.CompilerOptions): Promise<[Deno.TSErrors | undefined, Record<string, string>]>;

Deno.bundle(rootName: string, sources?: Record<string, string>, options?: Deno.BundleOptions): Promise<[Deno.TSErrors | undefined, string]>;

Deno.CompilerOptions would essentially be a re-export of the compiler options. We may want to cut it down to only support the things we support in the compiler.

Using Deno.transpileOnly it will simply take the sources and run them through just a transpile. So if the user doesn't really care about type checking and just needs the emit.

Using Deno.compile is when the user wants to have things type checked. The Promise would resolve with a [Deno.TSErrors | undefined, Record<string, string>] which is a tuple where the first element contains an array of normalised TSErrors that conform to the Deno error format, and the second contains a record where the key is the file name and the value is the emitted code. The Promise would reject on non-TSErrors.

With Deno.compile, when sources is omitted, it will resolve rootName as a module specifier supplied on the command line. When sources are supplied, instead of resolving modules externally, they will all be resolved within sources where the key is the file name and the value the content.

With Deno.bundle, it would work in a similar way, except that the Promise would resolve with a single content string, which would be a self contained bundle. The options supported on the bundle would be a subset of the compiler options supported for the other two.

[Pandawan]

Would this also include the Deno runtime? As in, assuming you’re outputting Deno-specific (uses Deno namespace/module) JS code, will you also get a JS version of Deno?

If so, doesn’t that defeat the point of Deno using TypeScript? Also, should we be worried about bundle size?

If not, what’s the point of exporting it as a JS file? (The browser won’t be able to use it anyway, if it has Deno-specific code). And if you’re not using Deno-specific code, why not use the TypeScript compiler directly?

[kitsonk]

And if you’re not using Deno-specific code, why not use the TypeScript compiler directly?

For some workloads, users want access to the TypeScript compiler that is built into Deno. Using tsc would require that Node.js be installed and a duplication of the full TypeScript package installed using npm or yarn.

Take using Deno as an HTTP server of some sort, and you want to serve to your clients JavaScript based on TypeScript you have hosted on locally. You could run the TypeScript language services under Deno, or we could provide access to the built in TypeScript compiler. It is a narrow use case, but it is still a very valid use case.