search

cats-oss / eslint-config-abema

This project is presets of eslint configurations which we used in our some internal projects.
MIT License
4 stars 1 forks source link

The current status #247

Open tetsuharuohzeki opened 5 years ago

tetsuharuohzeki commented 5 years ago

By https://github.com/cats-oss/eslint-config-abema/pull/246#pullrequestreview-313294603, 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 commented 5 years ago

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 commented 5 years ago

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 commented 3 years ago

I proposed to archive this project #598

tetsuharuohzeki commented 2 years ago

I proposed to archive this project #598

We concluded to archive this project.