TSC meeting 05-December-2019

[eslint-deprecated]

Time

UTC Thu 05-Dec-2019 21:00:

• Los Angeles: Thu 05-Dec-2019 13:00
• Chicago: Thu 05-Dec-2019 15:00
• New York: Thu 05-Dec-2019 16:00
• Madrid: Thu 05-Dec-2019 22:00
• Moscow: Fri 06-Dec-2019 00:00
• Tokyo: Fri 06-Dec-2019 06:00
• Sydney: Fri 06-Dec-2019 08:00

Location

https://gitter.im/eslint/tsc-meetings

Agenda

Extracted from:

• Issues and pull requests from the ESLint organization with the "tsc agenda" label
• Comments on this issue

Invited

• Nicholas C. Zakas (@nzakas) - TSC
• Kevin Partington (@platinumazure) - TSC
• Ilya Volodin (@ilyavolodin) - TSC
• Brandon Mills (@btmills) - TSC
• Toru Nagashima (@mysticatea) - TSC
• Kai Cataldo (@kaicataldo) - TSC
• Teddy Katz (@not-an-aardvark) - TSC

Public participation

Anyone is welcome to attend the meeting as observers. We ask that you refrain from interrupting the meeting once it begins and only participate if invited to do so.

[mysticatea]

An item from last meeting which we couldn't cover:

I want to add an agenda item: Can adding warnings (without adding errors) ever be semver-minor?

TSC Summary

In this comment, I noted that it is currently considered a breaking change to add warnings for any reason (including outside of lint rules), because of eslint --max-warnings=0.

Our semver policy currently states that causing build errors on any enhancement should always be treated as semver-major (and this is correct and sensible). When someone is using --max-warnings, any new warnings can cause a build error.

At the same time, warnings are currently our best way of reporting non-fatal errors from core (e.g., if there are minor issues with disable comments, deprecated rules, etc.). Errors and warnings are fundamentally different: Errors change the exit code of CLI processes and generally represent issues that users must resolve, but warnings do not change the exit code of CLI processes and generally represent minor issues that users could ignore. Warnings only become issues that users must resolve if they use --max-warnings in the CLI, and that is an opt-in decision.

TSC Question

Can we consider adding new warnings in semver-minor enhancements, as long as they are only warnings? As part of this, can we consider --max-warnings and any CLIEngine equivalent as the user bypassing our semver policy, similar to eslint:all?

If not, could we design a new way to communicate to users, in such a way that RFCs which add information for users could do so without semver risks? For example:

• New message severity that can never trigger nonzero exit code even with --max-warnings
• A new report section for informational messages unrelated to per-file linting

[mysticatea]

I'd like to add two agendas:

---

TSC Summary:

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.

TSC Question:

When should we start to merge the PRs of breaking changes?

---

TSC Summary:

Previously, we discussed about eslint/rfcs#40 (note). I emailed to @nzakas and he has inputted his insight. Then I updated eslint/rfcs#40.

I'd like to ask for reviewing again.

TSC Question:

Should we approve eslint/rfcs#40 or request more changes?

[platinumazure]

I'll bring up this question from eslint/rfcs#51 (discussion: eslint/rfcs#51 (comment)):

TSC Summary:

Quote from the discussion:

Good point.

Because I'm not sure if the bower_components directory 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.

1. We keep it as-is.
2. We change it to /**/bower_components/*.
3. We remove /bower_components/* in favor of the ignorePatterns property 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.

TSC Question:

Should we stop ignoring bower_components by default in ESLint 7.x (or a later major release)?