Update TypeScript to 2.0

[zloirock]

https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/

[chicoxyzzy]

Should we add TS 2.0 as a new row in a table or updating current row is enough?

[ljharb]

I think a new row is better - people won't update immediately, and the historical data is useful.

[dead-claudia]

I also think a new row would be better, for the same reasons. It would also fit in line with much of the rest, where the compilers are more of the exception, not the rule, in lacking versions (TypeScript is the only one that has really changed in its support across versions).

I will note that TypeScript does now offer ES2015 through ES2017 as compilation targets, with some features not transpilable down to earlier standards (e.g. async functions were only recently opened up to ES5 and ES6 targets), so I don't know if that would qualify as transpiler support or not.

[chicoxyzzy]

cc @DanielRosenwasser who may be interested =)

[DanielRosenwasser]

Well I'll point out that the data already reflects 2.0 (trailing commas in arg lists seems green right now).

To put my two cents in here, I don't entirely see why you'd want a new column. The reason browsers have multiple versions is to let developers know when it makes sense to start using certain features because they don't know which browsers their clients might be running. Is this as much a concern with a compiler which your team fixes on a certain version?

That said, it's really whatever you all think is most appropriate. You'd eventually have to do the same thing with Babel and other compilers too though.

[ljharb]

@DanielRosenwasser the table is also used as a reference for people who may not be using the newest one.

[dead-claudia]

It's also useful as a historical reference. Seeing the progression with browsers, even to ES5, is rather interesting IMHO.

[devoto13]

From the implementation point of view it's problematic to have multiple versions of TypeScript (or any library) as a dependency. Does it mean that results from previous versions should be somehow "archived" when adding a new version of compiler?

[dead-claudia]

@devoto13 Are browser results cached already?

[devoto13]

@isiahmeadows Yes, they are. But the difference is that browser results are always entered manually, while transpilers results are computed automatically. Not saying that it's undoable, just that it will introduce more complexity.

[martinsuchan]

TypeScript 2.1 with support for Async Functions and Object Rest & Spread was just released:
https://blogs.msdn.microsoft.com/typescript/2016/12/07/announcing-typescript-2-1/

[ova2]

I would suggest to track 3 last versions of TypeScript. I think it's enough. So, we have now 1.8, 2.0, 2.1. The same for browsers - the compat-table doesn't have all possible browser versions (the table would be huge in this case).

[ljharb]

It ideally should have them all, just hidden by default.

[martinsuchan]

For the start there should be at least the latest version 2.1. The current one in the table is ridiculously old and only throws bad light on TypeScript.

[styfle]

Was this fixed? The TypeScript column shows some green esnext features.

[fiznool]

Pretty sure the compat tables now show the details for TS 2.8, which is only one version behind the current (2.9).

[trotyl]

@fiznool TypeScript added support for Generators at version 2.3, but it's still 0/27 on the table, is it reasonable?

[dead-claudia]

@trotyl They appear to be using the default compiler options, and each rebuild is using the latest TypeScript.

Note that if you're using --target es3 or --target es5 (I think the latter is the default), you have to use --downlevelIteration to transpile ES6+ generators to ES5. There's a few similar flags IIRC, but that's the big one, and it exists because transpiling iterators into es5-compatible state machines is ridiculous in size and speed both.

There's also the caveat IIRC (this might be fixed in recent compiler versions) that constructors don't check new.target, and that meta property itself isn't fully supported anyways (it's impossible to transpile to ES5).

[trotyl]

@isiahmeadows The measurement should be fair between transpilers, since Babel is considered supports generator with tons of boilerplates in result, then so should TypeScript be, isn't it?

[zloirock]

It should be added with a note about support with a flag. Feel free to add a PR.

[dead-claudia]

@trotyl Babel supports it by default, and has less of an issue with boilerplate than TypeScript does (they were hesitant to even allow helpers initially in their desugaring, until async/await came along). They have philosophical differences, hence why Babel supports it without question, while TypeScript doesn't. TypeScript didn't even support for ... of initially for anything but arrays in --target es5, although I think that's since changed.

[trotyl]

Babel supports it by default

There're concepts of plugin and preset in Babel, but not in TypeScript. More accurately it's provided by some plugin in official preset.

has less of an issue with boilerplate than TypeScript does

For code:

function *foo() {
  yield 1
  yield 2
  return 3
}

for (const item of foo()) {
  console.log(item)
}

Result in Babel:

var _marked = /*#__PURE__*/regeneratorRuntime.mark(foo);

function foo() {
  return regeneratorRuntime.wrap(function foo$(_context) {
    while (1) {
      switch (_context.prev = _context.next) {
        case 0:
          _context.next = 2;
          return 1;

        case 2:
          _context.next = 4;
          return 2;

        case 4:
          return _context.abrupt("return", 3);

        case 5:
        case "end":
          return _context.stop();
      }
    }
  }, _marked, this);
}

var _iteratorNormalCompletion = true;
var _didIteratorError = false;
var _iteratorError = undefined;

try {
  for (var _iterator = foo()[Symbol.iterator](), _step; !(_iteratorNormalCompletion = (_step = _iterator.next()).done); _iteratorNormalCompletion = true) {
    var item = _step.value;

    console.log(item);
  }
} catch (err) {
  _didIteratorError = true;
  _iteratorError = err;
} finally {
  try {
    if (!_iteratorNormalCompletion && _iterator.return) {
      _iterator.return();
    }
  } finally {
    if (_didIteratorError) {
      throw _iteratorError;
    }
  }
}

Result in TypeScript:

function foo() {
    return __generator(this, function (_a) {
        switch (_a.label) {
            case 0: return [4 /*yield*/, 1];
            case 1:
                _a.sent();
                return [4 /*yield*/, 2];
            case 2:
                _a.sent();
                return [2 /*return*/, 3];
        }
    });
}
try {
    for (var _a = __values(foo()), _b = _a.next(); !_b.done; _b = _a.next()) {
        var item = _b.value;
        console.log(item);
    }
}
catch (e_1_1) { e_1 = { error: e_1_1 }; }
finally {
    try {
        if (_b && !_b.done && (_c = _a["return"])) _c.call(_a);
    }
    finally { if (e_1) throw e_1.error; }
}
var e_1, _c;

I'd say there's not much difference except TypeScript doesn't using regenerator but its on tslib.

[dead-claudia]

I mean "default" in terms of what you normally initially get set up with. Very few use Babel without `babel-preset-env` or `babel-preset-es2015` if they're targeting ES5 or earlier. The official guide sets you up to use the first, so that's "default" enough. TypeScript sets you up with no config by default, only encouraging you to set `--strict` and `--target`, the latter as appropriate to your project. Neither are actually enabling generators, so that doesn't really count as "default" enough. I'm thinking of the "default" workflow here, if that helps.

…

On Wed, Jun 13, 2018, 05:01 Trotyl Yu ***@***.***> wrote: Babel supports it by default There're concepts of plugin and preset in Babel, but not in TypeScript. More accurately it's provided by some plugin in official preset. has less of an issue with boilerplate than TypeScript does For code: function *foo() { yield 1 yield 2 return 3 } for (const item of foo()) { console.log(item) } Result in Babel: var _marked = /*#__PURE__*/regeneratorRuntime.mark(foo); function foo() { return regeneratorRuntime.wrap(function foo$(_context) { while (1) { switch (_context.prev = _context.next) { case 0: _context.next = 2; return 1; case 2: _context.next = 4; return 2; case 4: return _context.abrupt("return", 3); case 5: case "end": return _context.stop(); } } }, _marked, this); } var _iteratorNormalCompletion = true;var _didIteratorError = false;var _iteratorError = undefined; try { for (var _iterator = foo()[Symbol.iterator](), _step; !(_iteratorNormalCompletion = (_step = _iterator.next()).done); _iteratorNormalCompletion = true) { var item = _step.value; console.log(item); } } catch (err) { _didIteratorError = true; _iteratorError = err; } finally { try { if (!_iteratorNormalCompletion && _iterator.return) { _iterator.return(); } } finally { if (_didIteratorError) { throw _iteratorError; } } } Result in TypeScript: function foo() { return __generator(this, function (_a) { switch (_a.label) { case 0: return [4 /*yield*/, 1]; case 1: _a.sent(); return [4 /*yield*/, 2]; case 2: _a.sent(); return [2 /*return*/, 3]; } }); }try { for (var _a = __values(foo()), _b = _a.next(); !_b.done; _b = _a.next()) { var item = _b.value; console.log(item); } }catch (e_1_1) { e_1 = { error: e_1_1 }; }finally { try { if (_b && !_b.done && (_c = _a["return"])) _c.call(_a); } finally { if (e_1) throw e_1.error; } }var e_1, _c; I'd say there's not much difference except TypeScript doesn't using regenerator <https://www.npmjs.com/package/regenerator-runtime> but its on tslib <https://www.npmjs.com/package/tslib>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#919 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AERrBCPYXsrfpsjWon4u7FVGGs7WLo3Eks5t8NTTgaJpZM4KEHfI> .