Skip to content
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

Support TypeScript in configuration initializer. #11789

Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion cli Relates to ESLint's command-line interface enhancement This change enhances an existing feature of ESLint

Comments

@g-plane
Copy link
Member

g-plane commented May 30, 2019

The version of ESLint you are using.
master

The problem you want to solve.
When running eslint --init, an option for TypeScript can be provided. Ref: #11368

Your take on the correct solution to problem.
Add a question or option in Inquirer questions list.

Are you willing to submit a pull request to implement this change?
Yes.

@g-plane g-plane added enhancement This change enhances an existing feature of ESLint cli Relates to ESLint's command-line interface evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels May 30, 2019
@platinumazure
Copy link
Member

I'm not opposed if the team consensus is to add support to ESLint init specifically for Typescript. After all, we already explicitly ask about React. However, I'm worried about potentially having to field more requests to add support for Flow or other libraries/frameworks.

ESLint was built to get out of the business of legislating rules, and pluggability has been a core design principle in that area. But we haven't done the same with init.

So, what I would like us to at least consider is: How can we make ESLint init more pluggable? Is there a way we could let plugins extend our init somehow? If such a thing could be implemented, then I envision typescript-eslint could export a binary in their package which might be something like, typescript-eslint-init, and they could choose to ask all, some, or none of the core ESLint init questions and add questions related to the plugin or to the language/framework/library on which the plugin is based.

@not-an-aardvark
Copy link
Member

Personally, I think it might be difficult to have a "pluggable eslint --init" along those lines due to problems with discoverability. If a user is aware of what typescript-eslint is, then they might not need the custom eslint --init anyway because they can just follow the instructions in that project's readme. Since eslint --init is intended for new users as an alternative to reading config documentation, it doesn't seem ideal to require them to find plugins (they might not even know what a plugin is).

@g-plane
Copy link
Member Author

g-plane commented Jun 2, 2019

Personally, I think it might be difficult to have a "pluggable eslint --init" along those lines due to problems with discoverability. If a user is aware of what typescript-eslint is, then they might not need the custom eslint --init anyway because they can just follow the instructions in that project's readme. Since eslint --init is intended for new users as an alternative to reading config documentation, it doesn't seem ideal to require them to find plugins (they might not even know what a plugin is).

You're right. So, IMHO, I prefer scaffolds (something like Yeoman) for new projects and/or new users.

@platinumazure
Copy link
Member

I can certainly agree that discoverability is both (1) important, and (2) a problem with my proposal. I just don't want to get into the business of being gatekeepers for every single type of init scenario.

I'm okay with adding Typescript since its linting is actually a project some of us are trying to support. Just worried that some might see this as precedent. Maybe I'm overthinking it since I could have said the same thing about the React question and we don't get tons of requests to support other libraries in init.

@aladdin-add
Copy link
Member

aladdin-add commented Jun 7, 2019

I am somewhat divergent on the issue: same reasons as @platinumazure

we can:

  • a. supporting typescript, just like React/Vue have been supported.
  • b. pluggability. to reposition eslint --init, it can be used for any-level-users, not just for new ones. In this way, it can support more than React/Vue, e.g. Angular, node...(if so, we might want to move eslint-cli to another repo).

seems b. is more promising!

@eslint-deprecated eslint-deprecated bot added the auto closed The bot closed this issue label Jul 8, 2019
@eslint-deprecated
Copy link

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

@platinumazure
Copy link
Member

platinumazure commented Jul 8, 2019

I'm okay with adding Typescript for now. This should be a pretty simple change so I don't think an RFC is required here. I'll reopen this and add it to the TSC agenda.

I'm not going to add a TSC Summary/Question because I think the initial post does a good job explaining.

@platinumazure platinumazure reopened this Jul 8, 2019
@platinumazure platinumazure added tsc agenda This issue will be discussed by ESLint's TSC at the next meeting and removed auto closed The bot closed this issue labels Jul 8, 2019
@eslint-deprecated eslint-deprecated bot added the auto closed The bot closed this issue label Aug 8, 2019
@eslint-deprecated
Copy link

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

@ilyavolodin ilyavolodin removed the auto closed The bot closed this issue label Aug 15, 2019
@ilyavolodin ilyavolodin reopened this Aug 15, 2019
@kaicataldo kaicataldo added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion tsc agenda This issue will be discussed by ESLint's TSC at the next meeting labels Aug 17, 2019
@kaicataldo
Copy link
Member

The TSC resolved this week to include a built-in TypeScript config preset and look into allowing plugins to provide additional init presets in the future.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.