TSC meeting 14-March-2019

[eslint-deprecated]

Time

UTC Thu 14-Mar-2019 20:00:

• Los Angeles: Thu 14-Mar-2019 13:00
• Chicago: Thu 14-Mar-2019 15:00
• New York: Thu 14-Mar-2019 16:00
• Madrid: Thu 14-Mar-2019 21:00
• Moscow: Thu 14-Mar-2019 23:00
• Tokyo: Fri 15-Mar-2019 05:00
• Sydney: Fri 15-Mar-2019 07: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
• 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.

[aladdin-add]

Not sure if it's the right place, but I love to add an item: JSCS Compatibility - https://github.com/eslint/eslint/projects/1

TSC Question: "How are we doing on JSCS compatibility? Is it still something we want to finish?"

[nzakas]

Just a heads up that I'm not going to make it this week (somehow scheduled a dentist appointment for thursday).

As a reminder, we agreed to finalize the list of tasks for v6.0.0 in this meeting. Here are my thoughts on the remaining tasks to review:

1. 👎 Update: Config File Improvements rfcs#13 - given that this is an alternative to Config File Simplification rfcs#9, I don't think we should consider it for v6.0.0. We should come to a decision about the future direction of configuration as a whole. This is too big of a decision to rush to get into v6.0.0.
2. 👍 New: Load plugins relative to the configs that reference them rfcs#14 - makes sense to include along with New: Simplify the resolution of third-party plugins/configs/parsers rfcs#7.
3. 👎 Update: Enable ES2017 parsing and globals by default rfcs#16 - I don't see enough of a benefit vs. the potential negative impact to existing users. I feel like we can continue discussing whether this makes sense as a whole and revisit later, as this doesn't seem to meet a pressing issue.
4. 👍 Validate against invalid rule schema defaults in RuleTester eslint#11473 - more helpful error messages are always in style.

[mysticatea]

👎 eslint/rfcs#13 - given that this is an alternative to eslint/rfcs#9, I don't think we should consider it for v6.0.0. We should come to a decision about the future direction of configuration as a whole. This is too big of a decision to rush to get into v6.0.0.

Because the core of eslint/rfcs#13 doesn't a breaking change (it's just internal changes and bug fixes), I don't think we have to stick to the timeframe of v6.0.0. I believe that we can do that in a minor version.

If I assume eslint/rfcs#14 was accepted for 6.0.0, only one breaking change in eslint/rfcs#13 is Additional Linting Targets in additional enhancement parts. (though, as a maintainer of eslint-plugin-node (.mjs), eslint-plugin-vue (.vue), and @typescript-eslint (.ts/.tsx), I'm happy if the enhancement is in 6.0.0)

[not-an-aardvark]

Reminder: Last weekend was the start of daylight savings time in the US. Be sure to check the local meeting times at the top of this issue to make sure you have the right time.

[mysticatea]

Oh, thank you for pointing out.

[mysticatea]

I removed an additional enhancement proposal "Plugin Resolution Change" from eslint/rfcs#13, so eslint/rfcs#13 now doesn't change the plugin resolution way.

The important pain that "Plugin Resolution Change" tried to solve is solved by Plugin Renaming proposal without any breaking change.

Because Plugin Renaming is a minor change, I hope to add this enhancement into 5.x to help shareable configs to solve peerDependencies pain and to support widely ESLint version support.

[nzakas]

@mysticatea I think that eslint/rfcs#7 and eslint/rfcs#14 are the only changes we should make before coming to a final decision about whether we want to adopt eslint/rfcs#9. We can only ask the community to change how they do configuration once, so I'd prefer not to introduce a bunch of small changes until we know what the bigger changes will be. This could be very confusing and frustrating for everyone. I feel that the changes even in the "Plugin Renaming" proposal are too dramatic to get into v6.0.0.

If you'd like to just do some refactoring of the config logic, I'm in favor of that. I just don't think we should be changing anything else about how configs work until we come to a decision on eslint/rfcs#9.

And given that a lot of eslint/rfcs#13 is just enhancements, we could just as easily hold off and do them after v6.0.0.

There's no rush here, let's take our time and make the correct decision because there's only so much tolerance the community has for change like this.

[not-an-aardvark]

Along the lines of not rushing into things, I've decided to withdraw eslint/rfcs#14 from consideration for v6.0.0. Recent discussions on that RFC have called into question whether loading all plugins relative to their importing configs is the right approach, because it might require overly-restrictive constraints on configs in order to handle dependency updates robustly. My current thinking is that something like "plugin renaming" (which looks something like eslint/rfcs#14 (comment)) might be a better long-term solution instead.

[nzakas]

Thanks for the update, I think that makes sense.

…

On Wed, Mar 13, 2019 at 1:18 PM Teddy Katz ***@***.***> wrote: Along the lines of not rushing into things, I've decided to withdraw eslint/rfcs#14 <eslint/rfcs#14> from consideration for v6.0.0. Recent discussions on that RFC have called into question whether loading all plugins relative to their importing configs is the right approach, because it might require overly-restrictive constraints on configs in order to handle dependency updates robustly. My current thinking is that something like "plugin renaming" (which looks something like eslint/rfcs#14 (comment) <eslint/rfcs#14 (comment)>) might be a better long-term solution instead — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACWkrhL8C2GEuW3GJmDqWwhLFddZ-Hkks5vWVz-gaJpZM4bYK50> .

--

______________________________ Nicholas C. Zakas @SlickNet Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm> Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy>

[not-an-aardvark]

On an unrelated note, I will be late to this meeting. I should hopefully be able to join by 4:15-4:20 or so, but feel free to start without me if there are enough people.

[nzakas]

Since it seems people will be missing or late, can we do a quick check to see who *will* be attending tomorrow so there aren't any surprises? Reminder: I won't be attending.

…

On Wed, Mar 13, 2019 at 1:22 PM Teddy Katz ***@***.***> wrote: On an unrelated note, I will be late to this meeting. I should hopefully be able to join by 4:15-4:20 or so, but feel free to start without me if there are enough people. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACWkq2UMEaCrpazttsbRg5V-CLb1NGYks5vWV4ZgaJpZM4bYK50> .

--

______________________________ Nicholas C. Zakas @SlickNet Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm> Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy>

[ilyavolodin]

I should be able to attend. Although, please keep in mind that my schedule is completely unpredictable and might change at the moments notice.

[btmills]

I’ll be there

[platinumazure]

I'll be there.