Use bounded typescript version?

[oliviertassinari]

The following change in my yarn.lock is breaking our typescript tests:

typescript@next:
-  version "3.2.0-dev.20181004"
-  resolved "https://registry.yarnpkg.com/typescript/-/typescript-3.2.0-dev.20181004.tgz#ac75518858a134a7a3345b23c67ce5c6333279f6"
-  integrity sha512-Z23RIddFV2Nnze2j4AT/NewQ9aeMOzxVYKUZwDormi/eKL/6v7SlHIelXpweVYIHy6gPpV1HMhFxBQ4+f8TrxA==
+  version "3.2.0-dev.20181117"
+  resolved "https://registry.yarnpkg.com/typescript/-/typescript-3.2.0-dev.20181117.tgz#58a8cab074668a0e33ced2bc3c537dc5531c6eee"
+  integrity sha512-SWiOhEQfhelK6Jb6g2fU2AHUnXhY10xeCVweMZCAlmTGKiDhq5inJfn3cHNPNcRd3xFLAsEdE2Wqdoz8iCy4OA==

Turn out, that change was allowed by this dependency typescript scope:
https://github.com/Microsoft/dtslint/blob/73a196741d5b6ca9af7f6ef68ef4ee3e801ac4b5/package.json#L31

Wouldn't it be better to have scoped version, not allowing any typescript version that might break in the future?

[eps1lon]

@Andy-MS This is again breaking our tests since typescript changed the enum values for SyntaxKind.

The issue here is that using dtslint essentially requires users to use typescript@next: tslint has a peerDependency on typescript so if one uses e.g. typescript@3.2 then tslint will parse the source with typescript@3.2. This results in nodes with different syntax kind enum values that are not recognized by typescript@next.

microsoft/TypeScript#25886 caused such an issue:
tslint will create an AST where an export default ... node will have a modifier with the kind 84 which is the ExportKeyword in typescript@3.2 but since typescript 3.3 added the BigIntLiteralKeyword to SyntaxKind in typescript@next ExportKey will have the value 85. This reports a false positive in the strict-export-declare-modifer-rule.