Skip to content

Auto fix compilerOptions Lib #32560

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
5 tasks done
RubenSandwich opened this issue Jul 25, 2019 · 2 comments
Open
5 tasks done

Auto fix compilerOptions Lib #32560

RubenSandwich opened this issue Jul 25, 2019 · 2 comments
Labels
Experience Enhancement Noncontroversial enhancements Suggestion An idea for TypeScript
Milestone

Comments

@RubenSandwich
Copy link

RubenSandwich commented Jul 25, 2019

Search Terms

compilerOptions Lib, autofix Lib, auto Lib generation, Auto compilerOptions

Suggestion

Suggest adding the appropriate library to compilerOptions.lib if you are using a feature that requires it.

Use Cases

  • Help the developer code by preventing them from having to look up which compilerOptions.lib setting they need to use a particual feature of the standard library. As it is difficult to remember which version of ES introduced which additions.
  • In the future this could be used to auto generate the compilerOptions.Lib the developer needs by the JS features they are using. Which would remove some configuration. 🎉

Examples

Object.entities(object).map(([key, value]) => {
  ...
});

📎💬 “Looks like your using Object.entities, would you like to add 'es2017.object' to your compilerOptions.lib?”


if (array.includes(testValue)) {
  ...
}

📎💬 “Looks like your using Array.include, would you like to add 'es2016.array.include' to your compilerOptions.lib?”

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.
@orta
Copy link
Contributor

orta commented Jul 25, 2019

A simpler PR for this would probably look a lot like #32281

It could be built in one of two ways:

  • There could be a known symbol map of most common mistakes like this, and what they would need to add to lib
  • A more comprehensive answer, but more complex, could be to look at the diagnostic for missing symbol and then search through all shipped lib.x.d.ts files to see if it's included and raise with the associated lib recommendation

@RyanCavanaugh RyanCavanaugh added Experience Enhancement Noncontroversial enhancements Suggestion An idea for TypeScript labels Jul 29, 2019
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jul 29, 2019
@RyanCavanaugh
Copy link
Member

This is nice but we should also make it clear to the user that this API is nominally not available in the version they say they are targeting, not just that TS wants them to say the magic words.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Experience Enhancement Noncontroversial enhancements Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants