TypeScript를 2.0으로 업데이트

묘사

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

토론 #1

테이블에 TS 2.0을 새 줄로 추가해야 합니까? 아니면 현재 줄을 업데이트하면 충분합니까?

토론 #2

나는 새로운 줄이 더 좋다고 생각한다. 사람들이 즉각 갱신하지 않을 뿐만 아니라 역사 데이터도 매우 유용하다.

토론 #셋

같은 이유로 저도 줄을 바꾸는 것이 더 좋을 것 같습니다.버전이 부족한 상황에서 컴파일러는 규칙이 아니라 예외이기 때문에 다른 버전과 일치할 수 있다. (TypeScript는 버전 간 지원에 있어서 진정으로 변화가 발생하는 유일한 버전).
내가 지적하고자 하는 것은 TypeScript는 현재 ES2015에서 ES2017까지 컴파일 목표로 제공하고 있는데 그 중 일부 기능은 초기 기준에 따라 변환할 수 없다(예를 들어 비동기 함수는 최근에 ES5와 ES6 목표에 개방되었다). 그래서 이것이transpiler 지원 조건에 부합되는지 모르겠다.

토론 #4

cc@Daniel Rosenwasser 누가 흥미를 느낄 수 있습니까=

토론 #5

제가 지적하고자 하는 것은 데이터가 2.0(arg 목록의 끝부분 쉼표가 현재 녹색으로 보입니다)을 반영했다는 것입니다.
나의 2푼의 돈을 여기에 두어라. 나는 네가 왜 새로운 칼럼을 원하는지 완전히 모르겠다.브라우저가 여러 버전이 있는 이유는 개발자가 언제 어떤 기능을 사용하기 시작했는지 알게 하는 것이 의미가 있기 때문이다. 왜냐하면 클라이언트가 어떤 브라우저를 실행하고 있는지 모르기 때문이다.당신의 팀이 어떤 버전에서 복구한 컴파일러에도 같은 문제가 존재합니까?
즉, 이것은 너희들이 생각하기에 가장 적합하다는 것이다.하지만 결국 베벨과 다른 컴파일러에게도 똑같은 일을 해야 한다.

토론 #6

@Daniel Rosenwasser 이 시계는 최신 시계를 사용하지 않는 사람들의 참고로 사용됩니다.

토론 #7

역사 참고로도 유용하다.브라우저의 발전, 심지어 ES5까지 보고 나는 상당히 재미있다고 생각한다.

토론 #8

실현의 측면에서 볼 때 여러 버전의 TypeScript(또는 그 어떠한 라이브러리)를 의존항으로 하는 것은 문제가 있다.이것은 새 버전의 컴파일러를 추가할 때 이전 버전의 결과를 어떤 방식으로 '저장' 해야 한다는 것을 의미하는가?

토론 #9

@devo13 브라우저 결과가 캐시되었습니까?

토론 #10

@isiahmeadows 네, 그렇습니다.그러나 브라우저 결과는 항상 수동으로 입력되고, Transpiler 결과는 자동으로 계산된다.그것은 취소할 수 있는 것이 아니라, 단지 더 많은 복잡성을 가져올 것이라고 말할 뿐이다.

토론 #11

비동기 함수와 객체 Rest & Spread를 지원하는 TypeScript 2.1이 출시되었습니다.
https://blogs.msdn.microsoft.com/typescript/2016/12/07/announcing-typescript-2-1/

토론 #12

TypeScript의 최신 버전 3개를 추적하는 것이 좋습니다.나는 충분하다고 생각한다.우리는 지금 1.8, 2.0, 2.1이 있다.브라우저도 마찬가지다. compat표에는 모든 가능한 브라우저 버전이 없다. (이 경우 테이블이 크다.)

토론 #13

이상적인 상황에서 그것을 모두 숨겨야 한다.

토론 #14

우선 최소 최신 버전 2.1이 있어야 한다.표 속의 현재의 낡은 것은 타자 스크립트에 좋지 않은 영향을 미칠 뿐이다.

토론 #15

이거 고정인가요?TypeScript 열에는 녹색esnext 기능이 표시됩니다.

토론 #16

확실한 것은 compat은 TS 2.8의 상세한 정보를 나타냈고 TS 2.8은 현재 버전(2.9)보다 한 버전 뒤떨어진 것으로 나타났다.

토론 #17

@fiznool TypeScript는 버전 2.3에 support for Generators를 추가했지만 데스크톱에 0/27되어 있습니다. 합리적입니까?

토론 #18

@trotyl 그들이 사용하고 있는 것 같다the default compiler options와each rebuild is using the latest TypeScript.--target es3 또는 --target es5(기본값으로 간주됨)를 사용하는 경우에는 --downlevelIteration를 사용하여 ES6+ 생성기를 ES5로 전송해야 합니다.IIRC에는 몇 가지 유사한 표지가 있지만 이것은 큰 표지이다. 교체기를 es5 호환 상태기로 전송하는 것은 크기와 속도가 터무니없기 때문이다.
또 하나의 경고 IIRC (최근 컴파일러 버전에서 복구될 수 있음) 는 구조 함수를 검사하지 않을 뿐만 아니라, 원 속성 자체도 완전히 지원되지 않을 뿐만 아니라 (ES5로 전송할 수 없음).new.target@isiahmeadows 운송업자 간의 측정은 공평해야 한다. 바베타는 발전기를 지원하는 결과로 여겨지기 때문에 TypeScript도 공평해야 하지 않겠는가?

토론 #19

로고가 받쳐주는 것에 대한 주석을 추가해야 한다.PR

토론 #20

@trotyl-Babel을 임의로 추가할 수 있으며, TypeScript에 비해 샘플 파일에 대한 문제가 더 적습니다. ((

토론 #21

/async 가 나타나기 전까지는 조수가 설탕을 최초로 제거하는 것을 원치 않습니다.)그것들은 철학적인 차이가 있기 때문에 왜 Babel은 의심할 여지없이 그것을 지지하고, TypeScript는 그것을 지원하지 않는가. TypeScript는 처음에는 await 수조를 제외한 어떤 것도 지원하지 않았다. 비록 나는 이것이 이미 바뀌었다고 생각하지만.for ... of

Babel supports it by default

Babel에는 플러그인과 사전 설정 개념이 있지만 TypeScript에는 없습니다.더 정확히 말하면, 그것은 정부에서 설치한 일부 플러그인에 의해 제공된 것이다.

has less of an issue with boilerplate than TypeScript does

코드:

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

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

결과는 바베타:

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;
    }
  }
}

결과는 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;

나는 TypeScript가 사용하지 않고 사용하는 것 --target es5 을 제외하고는 큰 차이가 없다고 말하고 싶다.

토론 #22

나는'묵인'을 가리키며, 네가 처음에 흔히 겪는 상황을 가리킨다.
바베타를 regenerator 또는 tslib 없이 사용하는 사람은 드물다
그들의 목표는 ES5 이상이다.공식 가이드북에서 사용하실 수 있어요.
우선, 이것은 이미 묵인하기에 충분하다.TypeScript 설정을 설정하지 않았습니다.
기본값

토론 #23

및 babel-preset-env만 권장합니다.
너에게 적합한 항목.둘 다 발전기를 제대로 사용하지 않았는데,
그래서 이것은 아직'기본값'이라고 할 수 없다.
도움이 된다면, 나는 기본 작업 흐름을 고려하고 있다.
2018년 6월 13일, 수요일, 05:01, 여특룡 babel-preset-es2015 은 다음과 같이 썼다.

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 https://github.com/kangax/compat-table/issues/919#issuecomment-396867065, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBCPYXsrfpsjWon4u7FVGGs7WLo3Eks5t8NTTgaJpZM4KEHfI .