3 ms·

I've been using TypeScript for a while, and one thing I keep wondering about is which polyfills are baked into the compiler. I don't know how I've been able to

I've been using TypeScript for a while, and one thing I keep wondering about is which polyfills are baked into the compiler. I don't know how I've been able to get this far without understanding it. Turns out there are none. You have two compiler flags: Target and Lib. Lib determines the syntax and objects/apis you can use: ES2015, 2016, '17, etc, and Target determines which platform it will run on. But as far as I can tell, setting target does nothing to materially change the output code. It doesn't polyfill. Rather it just causes additional configurations to feed into the Lib compiler argument. How to Polyfill with Typescript: https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#polyfill-for-old-javascript-engines https://basarat.gitbooks.io/typescript/content/docs/types/li... More on Target: https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#compiler-target-effect-on-libdts https://basarat.gitbooks.io/typescript/content/docs/types/li...

recursive 8y ago
Typescript does have built-in polyfills. See for yourself. 1. Goto http://www.typescriptlang.org/play/ http://www.typescriptlang.org/play/ 2. Enter the code `function* gen() { yield "foo"; }` 3. Behold the mighty state machine in the compiled output.
- Arnavion 8y ago
  Specifically, TS has polyfills for language features (eg iterators), not library features (eg `Array.prototype[Symbol.iterator]`).
  - johnny_reilly 8y ago
    Exactly what Arnavion said. So if you want to write es-latest with TypeScript but support es5 simply set your target to be es5, import core-js for API polyfills and set lib to your desired es version.
- deleted 8y ago
  [deleted]
nothrabannosir 8y ago
It does have polyfills, but precisely to avoid relying on those I tend to stick to using the same in and out language. Babel is a better translator, and typescript is good at doing types. Add sorcery.js to chain the source maps and you’re cooking with gas.
- sbjs 8y ago
  In what way have you found Babel to be a better translator?
  - nothrabannosir 8y ago
    Support of features, maturity, etc. “Do one thing and do it well” applies. Have a look at the Babel website. There are tons of plugins and features: generators, symbols, async generators , object spread (long before TS had it), ......... Then there is automatic tracking of what is supported by your runtime , e.g. you can say “use polyfills for anything not supported by the current version of node”. .babelrc is a complex beast, because polyfilling is complex. Let Babel solve that, and focus your TS energy on typechecking.
    - sbjs 8y ago
      You're actually arguing against your own point. "Do one thing and do it well" is a great philosophy, and TypeScript actually does that more than Babel does. Babel does translation and polyfill, TypeScript only does translation. Type checking is only done during the translation phase for both tools (using Flow for Babel). So I would say TypeScript is cleaner and simpler in that regard.
- sebazzz 8y ago
  It sounds only to me that you create an much more complex and harder to debug build pipeline with little added benefit. Please explain what Babel makes a better translator.

recursive 8y ago

Typescript does have built-in polyfills. See for yourself. 1. Goto http://www.typescriptlang.org/play/ http://www.typescriptlang.org/play/ 2. Enter the code `function* gen() { yield "foo"; }` 3. Behold the mighty state machine in the compiled output.

Arnavion 8y ago
Specifically, TS has polyfills for language features (eg iterators), not library features (eg `Array.prototype[Symbol.iterator]`).
- johnny_reilly 8y ago
  Exactly what Arnavion said. So if you want to write es-latest with TypeScript but support es5 simply set your target to be es5, import core-js for API polyfills and set lib to your desired es version.
deleted 8y ago
[deleted]

nothrabannosir 8y ago

It does have polyfills, but precisely to avoid relying on those I tend to stick to using the same in and out language. Babel is a better translator, and typescript is good at doing types. Add sorcery.js to chain the source maps and you’re cooking with gas.

sbjs 8y ago
In what way have you found Babel to be a better translator?
- nothrabannosir 8y ago
  Support of features, maturity, etc. “Do one thing and do it well” applies. Have a look at the Babel website. There are tons of plugins and features: generators, symbols, async generators , object spread (long before TS had it), ......... Then there is automatic tracking of what is supported by your runtime , e.g. you can say “use polyfills for anything not supported by the current version of node”. .babelrc is a complex beast, because polyfilling is complex. Let Babel solve that, and focus your TS energy on typechecking.
  - sbjs 8y ago
    You're actually arguing against your own point. "Do one thing and do it well" is a great philosophy, and TypeScript actually does that more than Babel does. Babel does translation and polyfill, TypeScript only does translation. Type checking is only done during the translation phase for both tools (using Flow for Babel). So I would say TypeScript is cleaner and simpler in that regard.
sebazzz 8y ago
It sounds only to me that you create an much more complex and harder to debug build pipeline with little added benefit. Please explain what Babel makes a better translator.