About this runner: TypeScript
TypeScript is easiest to reason about when the experiment is small. Put the code in the code panel, add input only if the snippet reads input, and run it once before you start editing around the problem.
Runs TypeScript through Piston from main.ts, so the snippet is type-checked/transpiled in the runner before execution. We chose that setup so the page can answer quick syntax and behavior questions without pretending to be your whole development machine.
Types disappear at runtime, which means a green type check does not validate incoming JSON or user input by itself. Tiny repros are honest. They either show the issue, or they tell you the issue lives somewhere else.
Good uses
The page is most useful before a change becomes expensive. Try the syntax here, learn the error message, then carry the cleaned-up idea back to your project.
Use this for type puzzles and small narrowing examples. Use a project when module resolution matters. That opinion is not subtle, but it saves time: online runners are for confidence, not final authority.
If a result surprises you, write down the exact input and the exact output before editing again. Tiny records like that make bug reports better, and they also keep your own memory from smoothing over the inconvenient detail that caused the failure.
The run path
The runner does only a few things. The work area holds the source, the input controls hold the data, and the output panel shows what the runner captured.
- Syntax errors usually come back before your program starts.
- Runtime errors are more interesting: they mean the code got far enough to execute, so the next question is about data, environment, or a TypeScript rule rather than typing.
- Timeouts are a signal too. Reduce the loop or the input and run again.
The best follow-up is usually boring: rename a variable, change one input value, or remove one branch. If the behavior changes, you found the sensitive part of the TypeScript example; if it does not, you can cross that idea off the list.
A worked check
The saved example below is intentionally left unchanged. Run it once as written, then make a small edit and run it again; that gives you a known-good baseline before you test your own idea.
interface Product {
name: string;
price: number;
}
const products: Product[] = [
{ name: "Notebook", price: 12.99 },
{ name: "Pen", price: 1.49 },
{ name: "Eraser", price: 0.79 }
];
const total = products.reduce((sum, p) => sum + p.price, 0);
const names = products.map(p => p.name.toUpperCase());
console.log("Products:", names.join(", "));
console.log("Total:", total.toFixed(2));The next preserved block belongs to the same example. Keep it nearby when you are comparing input, output, or the shape of the result. Small examples expose mistakes quickly.
Products: NOTEBOOK, PEN, ERASER
Total: 15.27After the sample works, try one edge case that exercises the page's limits. Types disappear at runtime, which means a green type check does not validate incoming JSON or user input by itself. That single change often teaches more than pasting a large program and trying to guess which part failed.
Known gaps
The runner is not a production environment. It will not carry durable state between serious sessions, and it should not be asked to handle tsconfig edge cases, npm packages, decorators, bundler behavior, and framework builds. Good. Boundaries make bugs easier to see.
The sweet spot is interfaces, generics, narrowing, union types, and small JavaScript interop examples. If your example needs a package manager, a database full of private rows, a web server listening on a port, or special build flags, move it to a local workspace before you draw conclusions.
A small runner should feel disposable. Try the idea, keep the useful lesson, and leave the accidental environment behind when the next step needs real project context.
FAQ
This FAQ is intentionally mixed: short answers for quick checks, longer notes where TypeScript has environment traps. Scan it once before assuming the runner and your local setup behave the same.
Which language is TypeScript written in?
The TypeScript compiler is written in TypeScript. That is common for mature languages that can compile themselves, often called self-hosting. As a user, the main tool you meet is tsc, which checks TypeScript types and emits JavaScript according to your tsconfig settings. For example, tsc main.ts type-checks and emits JavaScript when your local config allows it. TypeScript types disappear at runtime, so a typed variable does not validate random JSON by itself.
What is the best compiler for TypeScript?
For most projects, the standard TypeScript compiler, tsc, is the reference tool for type checking. Build tools such as esbuild, SWC, Vite, and Babel can transform TypeScript quickly, but many do not do full type checking by themselves. Use tsc when correctness of types matters. TypeScript types disappear at runtime, so a typed variable does not validate random JSON by itself.
Is there a compiler for TypeScript?
Yes. The TypeScript compiler is usually called tsc. It checks types and can output JavaScript. For example, tsc main.ts can produce main.js, depending on your settings. In real projects, tsconfig.json controls the target version, module format, strictness, and output directory. For example, tsc main.ts type-checks and emits JavaScript when your local config allows it. TypeScript types disappear at runtime, so a typed variable does not validate random JSON by itself.
Is TypeScript interpreted or compiled?
TypeScript is compiled, or more precisely transpiled, to JavaScript before it runs. Browsers and Node.js do not execute TypeScript types directly. After compilation, the JavaScript runs normally. That also means TypeScript cannot protect you from bad runtime data unless you validate it. TypeScript types disappear at runtime, so a typed variable does not validate random JSON by itself. For example, tsc main.ts type-checks and emits JavaScript when your local config allows it.
What is the TypeScript compiler?
Yes. The TypeScript compiler is usually called tsc. It checks types and can output JavaScript. For example, tsc main.ts can produce main.js, depending on your settings. In real projects, tsconfig.json controls the target version, module format, strictness, and output directory. For example, tsc main.ts type-checks and emits JavaScript when your local config allows it. TypeScript types disappear at runtime, so a typed variable does not validate random JSON by itself.
Version?
This page runs TypeScript through Piston using main.ts; the wildcard version means the runner supplies its available typescript runtime. I would treat that as good enough for syntax checks, but not as a promise about your production version. If a feature depends on a release, run the same snippet locally and check the official release notes. Version mismatches usually show up as syntax errors, missing APIs, or slightly different standard-library behavior.
Can I use packages with TypeScript?
Assume package installs are not available here unless the page already loads a library for the demo. That keeps the run predictable and quick. If your example needs a package manager, create a local project and add the dependency there, then use this page only for the small language part. For online testing, replace the dependency call with a tiny mock value and test your own logic around it.
Show me stdin.
Use the STDIN box for the text your program would normally read from the terminal. Put one input value per line. For example, enter Alice on the first line and 42 on the second, then read two values in your code. If parsing fails, test one line first before adding more cases. This is especially helpful for coding-challenge style problems where input shape causes most mistakes.
Docs worth opening
Reference pages are better than folklore when an error message gets specific. Start with official docs, then use tutorials for context once the rule is clear.