Suggestion

Goal: Have the language service be aware that you are writing TypeScript syntax which will not build in your project.

Assumption: The "typescript" dependency stays locked for users for longer than the version of TypeScript in the language service. In cases like VS Code, a user's TSServer version is nearly always the most recent release, but their building version of TypeScript gets put in a lockfile and requires manual updates.

Result: When we see new TS syntax like: ?. or [min: number, max: number] raise diagnostics if the discovered version of TypeScript (or babel etc? ) would support that syntax.

🔍 Search Terms

new syntax errors backwards compatability

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

• TypeScript infers the build version of TypeScript in a project
• We keep a list of syntax nodes + fields which are added in a new release
• During checking, if any of those nodes are found, we check that the build version of TypeScript is compatible with the syntax

📃 Motivating Example

1. Someone else uses a .d.ts feature which your version build of TypeScript does not support
2. Your editor gives you auto-complete or fixits for features like ?. but your build version of TypeScript does not support it

Short Comings:

The biggest shortcoming is that I'm not 100% we can be certain about the version of a project's TypeScript. If "typescript" the dependency is around that doesn't mean that it's the tool being used to eventually convert the code. This could maybe be solved by having a map of @babel/plugin-transform-typescript@1.2.3 = TS 3.2.1 or be a configuration option,