ES3 is a poor default for typescript

[mikemaccana]

Search Terms

defaults, ecmascript

Suggestion

The latest available typescript typescript@3.7.2 produces a bunch of unnecessary errors by targeting a very old version of JavaScript:

Error TS1056: Accessors are only available when targeting ECMAScript 5 and higher.

Typescript should update the default language version to something more reasonable.

Use Cases

A user install typescript. They compile a project using tsc which will fail in most cases. The users discovers that TypeScript targets a 21 year old version of JavaScript by default. They update their compiler options to support and 11 year old version of JavaScript at minimum.

Examples

tsc somefile.ts working without errors.

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[MartinJohns]

Please respect the issue template for feature requests.

---

You're expected to either provide a project configuration or specify the compiler options. Changing the default options is an unnecessary breaking change.

[mikemaccana]

Amended to use issue template as requested.

I'm aware of the compiler options. The issue is that the default compiler options are poor, as they require unnecessary work in most cases.

Updating the default target from a 21 year old to an 11 year old JavaScript version (or newer) is indeed a breaking change but quite reasonable for the reasons stated above. If you believe this is unnecessary you should specify why.

[mikemaccana]

Quick survey. Let's see how it goes:

https://twitter.com/mikemaccana/status/1217064488450609152?s=20

[mikemaccana]

@MartinJohns thanks for the thumbs down. Do you disagree that collecting data is a good approach here? What would you prefer?

[MartinJohns]

I disagree with the approach. In principle I personally absolutely agree on updating some of the default options (especially strict), but the breaking change is simply not worth it for something that's trivially done in a better way.

Also using Twitter as a way to gauge opinions is really a bad approach, as it often leads to an echo chamber. Additionally it requires users to sign up to yet another platform, while GitHub has already a suitable way to voice opinions (thumbs up/down).

There's also this comment that agrees with what I mentioned: #9642 (comment)

• What should the default commandline be?
• • Whatever it is now (no breaking changes)

---

But lastly I'm just a user voicing his opinion. You'll have to wait for the TypeScript team to respond (tho likely they'll say the same).

[mikemaccana]

something that's trivially done in a better way.

What is the better way?

Another quote from the link you posted is:

An unstated goal is that it should be reasonably easy to take an existing codebase written in JavaScript and get to a TypeScript codebase that compiles without error.

Which this bug addresses.

[nappy]

tsc --init generates target: "es5", so maybe if no config is loaded, tsc should print a warning, suggesting to generate a config. That would not cause any breaking changes.

[RyanCavanaugh]

A few points

• Inconvenience or annoyance doesn't clearly outweigh someone else's runtime behavior getting broken during a compiler update. The asymmetry of impact here is very large.
• The set of users who would get hurt worst by this aren't the ones who are reading the issue tracker
• We really, really think everyone should be using a tsconfig.json at this point, and tsc --init does default to ES5
• I don't think this will never change, but we'd probably do an all-at-once update to all of the default commandline options at some point (moduleResolution, strictFunctionTypes, strictNullChecks, and a few others come to mind as things that should have different defaults "in the future"). Maybe once every 10 years would be a reasonable cadence for that (TypeScript 5.0?)
• Twitter polls about what people are choosing to currently target is not what's under consideration here. A poll from the original position would be "Do you want to have your program break during some future compiler update so that someone else feels less inconvenienced about the no-config-file behavior of TypeScript?" which I think would have very different results.

[mikemaccana]

@RyanCavanaugh I don't think anyone wants their compiler to break, and I don't think asking that would produce very useful results.

How about

would you accept the next major update to Typescript defaulting to ES(5, 6 whatever) instead of ES3? This is a breaking change if you use ES3.

[mikemaccana]

Just a note that I'm unsubscribing from this bug as I'm tired of the sarcasm and trolling.

[AnyhowStep]

Every update is a major update with TypeScript ;D
semver doesn't work so well here

[sathish099]

The same issue i found. I currently working on nuxt js so i ** @disable** the TypeScript Vue Plugin (Volar) in vscode try this. May be it works.