The current status

[tetsuharuohzeki]

By #246 (review), I hear from @nodaguti that the core web application for "abema" does not use this config set now.

So I propose to add some notes to readme that core products is not using this now.

I also thought about to rename this repository, but I think strongly that renaming is not a nice way because we don't have any way to know how many projects are using this.

Perhaps, for the future, someone from internals retry to open-sourcing a ruleset at that time. Then we can reuse this repository with breaking change.

[tetsuharuohzeki]

I organized the current status, and I pinned this issue.

The current status

1. By some reasons (e.g. a core maintainer left the company), core product lines have reduced the dependency for this ruleset or have switched to others (e.g. eslint:recommended).
2. As a volunteer, some maintainers would continues to maintain this until their passion has been burned out.
3. We don't have a plan to rename this repository because:
   • We don't have any way to know how many projects are using this.
   • It causes some confusion definitely that to rename a url of open source repository.

---

I'll add some non normative comments for them.

[tetsuharuohzeki]

Non-normative comments as core maintainer

This does not means the end of this project. But I should write some postmortem.

For some reasons (e.g. a core maintainer left the company), core product lines have reduced the dependency for this ruleset or have switched to others (e.g. eslint:recommended).

I support this decision. I also think eslint:recommended is nice choice because it's less opinionated. If I have a fault, it's that I failed to find a new maintainers to integrate this project continuously.

This project aims to provide more solid (reduce a careless mistake) configurations than eslint:recommended. I aimed following things by this rule:

1. Detect all possible trivial errors
2. Guide a better implementation and debugging
3. Guide hassle-free code review
   • On code review, we focus better design, better naming, and better implementation.
   • If a code has been passed by ESLint with this rule once, we can assume that code would have a sufficient quality to check-in to a tree if there are not any design, naming, or implementation problem.
4. Focus on semantics, not stylistic issues
   • Stylistic Issues are business of a code formatter. It is not work for today's human programmer.
5. Control update cycle.
   • It's too hassle to manage a combination of non builtin rule sets. Its hassle prevents us to use a latest toolchain.

IMO, I think this project achieved these things and I believe this project still have more advantage than eslint:recommended.

But almost parts of them are reviewable things by human and maintenance burden for this project is not a lower. I don't have opinions about switching to eslint:recommend.

For @typescript-eslint/recommended, I doubt it's more better than this project for above targets. But I don't know for the future. Some year time spans might makes @typescript-eslint/recommended more comfortable and more solid.

[tetsuharuohzeki]

I proposed to archive this project #598

[tetsuharuohzeki]

I proposed to archive this project #598

We concluded to archive this project.