TSC meeting 21-November-2019

[eslint-deprecated]

Time

UTC Thu 21-Nov-2019 21:00:

• Los Angeles: Thu 21-Nov-2019 13:00
• Chicago: Thu 21-Nov-2019 15:00
• New York: Thu 21-Nov-2019 16:00
• Madrid: Thu 21-Nov-2019 22:00
• Moscow: Fri 22-Nov-2019 00:00
• Tokyo: Fri 22-Nov-2019 06:00
• Sydney: Fri 22-Nov-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
• Gyandeep Singh (@gyandeeps) - 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.

[platinumazure]

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

[kaicataldo]

I unfortunately will not be able to attend today’s meeting, and would like my vote to be counted as supporting consensus. I also am available to run the next release, whenever the team decides that should be.

[mysticatea]

Closing as this meeting has finished. There is not the meeting note because we only reviewed some long-living pull requests.