Previously, we discussed ESLint v7 schedule (note). In the schedule, we will start to merge the PRs of breaking changes after the release cycle of this weekend. However, we don't plan to make a release this weekend because we no longer make releases every two weeks.
Therefore, we should tweak the schedule.
My proposal is that we start to merge the PRs of breaking changes after the release cycle that will be started on 20 December 2019 finished. Then we will release the first alpha in January 2020.
When should we start to merge the PRs of breaking changes?
I'm basically :+1: to making a better CLIEngine-like interface, but I share Nicholas's concerns about AsyncIterator results being a large change for not a lot of demonstrated benefits.
I'm also a bit confused about whether this change is necessary given the parallel RFC for linting files in parallel-- maybe we should implement some sort of parallel linting but serialize the results. (Well, or maybe not. The point is, I'm not fully convinced about whether this RFC is necessary and whether it has enough benefit to justify the massive changes, even though they are no longer breaking.)
Promise<LintResult>and letting the caller aggregate the results
Quote from the discussion:
Because I'm not sure if the
bower_componentsdirectory in subdirectories is a common use-case or not, so I have left it as-is. I think that we have three directions for this.
- We keep it as-is.
- We change it to
- We remove
/bower_components/*in favor of the
ignorePatternsproperty of configs.
In fact, the 3. is consistent with our stance -- we don't add exceptions anymore because we don't want to have the allowlist/denylist of all tools in the world.
Should we stop ignoring bower_components by default in ESLint 7.x (or a later major release)?