Support .eslintrc.ts
See original GitHub issueThe version of ESLint you are using. 6
The problem you want to solve.
Allowing typescript users to write strongly typed .eslintrc
configuration files that “just work” in the same manner as .eslintrc.js
.
Your take on the correct solution to problem.
use ts-node
to bootstrap .ts
files if it’s available.
This would be following in the footsteps of other libraries, including:
- webpack
- webpack-nano
- danger-js
- babel (considering)
While I’ve used ts-node
, I’ve never implemented this sort of feature before.
I know that webpack-nano
uses rechior
to achieve this feature.
That in turn uses interpret
, which is also what webpack
uses.
I would additionally propose this happens by default, w/o requiring a config value - eslint
would search for a .js
file first, followed by a .ts
file, since in TS land this usually represents a compiled TS file.
Are you willing to submit a pull request to implement this change?
Gladly, but would most likely require some guidance from others having never worked w/ eslint
core directly (including general github & ci processes).
Overall, I think that this feature makes sense to support given the work being done to merge tslint
into eslint
via @typescript-eslint.
Ultimately, I’d love to see a day where I can write a .eslintrc.ts
and have everything work as they would if I’d had a .js
as the extension.
I think it’s reasonable to require the installation of additional dependencies in the application being linted for this feature; as such if there’s a way to implement this feature as a separate package over at @typescript-eslint then I’m game for that 😄
Issue Analytics
- State:
- Created 4 years ago
- Reactions:4
- Comments:25 (23 by maintainers)
Top GitHub Comments
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.
TL; DR: Just a joke.
@G-Rath
I think you may want the GitHub languages status for your codebase to keep 100% TypeScript with blue bar. Like this, right?
I’m also a fan of doing this.