Write compiled output to stdout

It doesn't seem possible to compile and output to stdout. There was some discussion on CodePlex before the migration to github: https://typescript.codeplex.com/workitem/600

Would a node package of the compiler with an API that allows you to pass strings and get strings back do the job?

That'd definitely be useful, but I'd much rather have an option to output to stdout in the cli.

so what happens if you have multiple outputs? how do you indicate file begin and end? and where do errors go? or should it just be a JSON.stringify output?

I think it'd be reasonable to only support --out functionality when printing to stdout, so it would print the concatenation of all outputs. Errors should be written to stderr.

It'd also be nice if it could take input through stdin, so tsc could be used in a series of commands using unix pipes.

If you're on a Unix system, you can look into mkfifo as a temporary workaround. I _think_ the following might work.

mkfifo -m 600 my_fifo
tsc file1.ts file2.ts --out my_fifo
YOUR_COMMAND_HERE < my_fifo
# or...
cat my_fifo | YOUR_COMMAND_HERE

but I can admittedly see the utility in having standard output as a target.

Open questions:

What should we call the flag?
What happens to external module emit? We currently emit those to their own file even under --out. It might be desirable to be compiling a single external module under this flag, so we wouldn't want to error, but we may also end up compiling more than one external module (and thus emitting more than one file).

Another question: how do you differentiate between output and message output? I guess we could use standard error as well.

Jackson Owens (@jbowens)

What should we call the flag?

Following Jackson Owens (@jbowens)'s suggestion to invariably apply --out behavior, there doesn't have to be a new flag: the Unix (POSIX) convention of using - to represent stdin or stdout (as in this case), could be applied: tsc --out - ....

While there's a hypothetical backward-compatibility concern -- currently, tsc literally creates a file named -, if you do that -- I don't think anyone would miss it.

As for the "Unix-centricness": I wouldn't expect Windows users to object, either.

I wanted this functionality for compiling little inline snippets of TypeScript within my templates which I could inject back into <script> tags. I wouldn't use it for anything that generated multi-file output.

have you considered typestring?

Michael Klement (@mklement0)

I agree with Michael Klement (@mklement0)'s proposal. This would be very helpful.

Ryan Cavanaugh (@RyanCavanaugh) It seems like you should treat stdout the same as if any filename was passed to the out argument. That will cover the majority of use cases anyway.

The rationale for this is wanting to pipe the output to something else, for example a minifier or gzip or ng-annotate or whatever. I think it is likely that people will generally be using this against single files, and using downstream tools to concatenate or whatever.

👍

--outFile - on Windows please (neither - nor CON work with 1.8.9).

This issue hasn't had any activity for quite some time. I think that Windows should be supported better, as *NIX can only output to stdout at this point (by specifying --out /dev/stdout).

It seems like the best solution to this, which has been proposed in a few locations (1, 2), is to allow a special value - to --out and --outFile which instructs tsc to, instead of writing to a file, writes to stdout.

Example usage:

tsc src/compiler/binder.ts --out -
tsc src/compiler/binder.ts --outFile -

If a compiler error occurs, the errors will be appended after the emitted output.

I've worked on a very simple implementation for this issue which is essentially just the following in compiler/sys/writeFile

// If `-` is provided as the fileName, output to stdout
if (fileName === '-') {
  process.stdout.write(data, "utf8");
  return;
}

I'm wondering how to author tests for a change like this, and what kind of documentation changes need to happen, and where those go. Thanks.

This would definitely be the expected behaviour from a Unix perspective.

Using --outfile=/dev/stdout works now, but if there is an error on compilation, the error is printed in-place of/alongside the compiled output. This, again, is not standard practice and can cause issues when scripting. To work around this, I use the following.

(tsc -m system ./path/to/file.ts --outfile /dev/stderr 3>&2 2>&1 1>&3-) | someOtherCommand

Because the errors are printed on stdout, I'm telling tsc to print code on stderr, and then switching the file descriptors on it, resulting in errors on stderr, and code on stdout.

Hope this helps someone!

Declining this one - outFile compilations (which is the only place this makes sense) are definitely getting increasingly rare and it's straightforward enough to use ts.transpileModule if you need this in a scripting context of some sort.

This becomes a necessity again. I am currently experimenting with deno. As you know deno and typescript go hand in hand. Node modules on the other hand not really. So ts.transpileModule is not an option at the moment. This issue stops some creative workflow rn.
Why would the result code not be piped to stdout if no --outFile is declared?

Printing to stdout is a basic function for most command line tools. I'm not quite sure why there's such resistance to implement this. It's nice to have DevOps scripts written in TypeScript, but having to set up their own build directories for a CI pipeline is cumbersome and unnecessary because generated JS files are transient and are only needed to complete whatever they are intended to do. On Linux this works:

tsc --module none --outFile /dev/stdout some-script.ts | node

, but it is not portable. Yes, ts.transpileModule works, but I have to copy this same script from a project to a project and maintain any changes to this file across projects.

Mind boggling.

对tsc.js手动应用src/tsc.patch和控制台直接输出编译后源码的补丁 microsoft/TypeScript#1226 (co…

Andre (@gh-andre)

Given a ts file:

var foo = {
    "id": 13,
    "name": "horst",
    "cars": [{
            "brand": "VW",
            "maxSpeed": 120,
            "isWastingGazoline": true
        }]
};

one can get the generated JavaScript to stdout as Andre (@gh-andre) pointed out:

tsc --module none --outFile /dev/stdout sample.json.ts
var foo = {
    "id": 13,
    "name": "horst",
    "cars": [{
            "brand": "VW",
            "maxSpeed": 120,
            "isWastingGazoline": true
        }]
}

Unfortunately, it doesn't work for getting the declarations onto stdout:

tsc --emitDeclarationOnly --declaration --module none --outFile /dev/stdout sample.json.ts                                                                                                                                                                                error TS5033: Could not write file '/dev/stdout.d.ts': EACCES: permission denied, open '/dev/stdout.d.ts'.


Found 1 error.

I am interested in getting the typescript declaration from a json file

declare const foo: {
    id: number;
    name: string;
    cars: {
        brand: string;
        maxSpeed: number;
        isWastingGazoline: boolean;
    }[];
};

Andre (@gh-andre)

Andre (@gh-andre)

tsc --module none --outFile /dev/stdout some-script.ts | node

This doesn't work if script.ts contains ES Modules import/export syntax

npx tsc --target esnext --outFile /dev/stdout --module none --moduleResolution node script.ts | node --input-type module

Soberia

Soberia I struggled with this and other things TypeScript for a bit and then moved my DevOps scripts to JavaScript. Far from ideal, but I cut down DevOps scripts enough to justify some duplication between the main TypeScript app and DevOps scripts. Will probably need to revisit it this year, as both codebases grow, but so far it's simpler to manage for my use cases.

Navigation Menu

Repository navigation

Write compiled output to stdout #1226

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Write compiled output to stdout #1226

Description

Activity

mhegazy commented on Nov 20, 2014

jbowens commented on Nov 20, 2014

mhegazy commented on Nov 20, 2014

jbowens commented on Nov 20, 2014

DanielRosenwasser commented on Nov 21, 2014

RyanCavanaugh commented on Dec 1, 2014

DanielRosenwasser commented on Dec 1, 2014

mklement0 commented on Dec 8, 2014

mnpenner commented on Mar 7, 2015

mhegazy commented on Mar 8, 2015

nicksloan commented on Mar 21, 2015

24 remaining items

josh-endries commented on Mar 20, 2016

pitaj commented on Nov 27, 2017

sebastien commented on Nov 27, 2017

sploders101 commented on Aug 20, 2019

RyanCavanaugh commented on Aug 21, 2019

timreichen commented on Mar 24, 2020

gh-andre commented on Apr 5, 2021

k0pernikus commented on Jan 11, 2022

Soberia commented on May 19, 2022

gh-andre commented on May 19, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions