21-Dec-2017 ESLint TSC Meeting Notes

Transcript

Currently .js is the only default extension. Request is to include .mjs by default.
Would make sense to simultaneously set script type to module in parserOptions for .mjs files.
And if we have module code, then we'd also want to enable ES6 by default for those files.
@ilyavolodin prefers to focus instead on revamping processors and extensions in config.
This is a breaking change since it could result in more errors, so it would have to wait for the next major release.
General mood is that we will want to do this in the future.
@kaicataldo proposes to re-evaluate when we start preparing the next major release. 👍 from @btmills, @not-an-aardvark, @ilyavolodin, @mysticatea, @platinumazure.

Resolution: We will re-evaluate this issue when we get ready for the next major release.

TSC Summary: This PR adds a null-check to a rule that would prevent it from crashing when it encounters code with optional catch bindings, a stage 3 proposal. There is some uncertainty about our policy on accepting changes like this. Officially, we only support stage 4 features, but in the past we've accepted patches to avoid crashes with syntax extensions like Flow, TypeScript, etc.
TSC Questions:
What is our policy for accepting patches related to custom syntax in rules?
- Should it make a difference if the patch is very simple?
- Should it make a difference if the custom syntax is a stage 3 feature and/or a very popular syntax extension?
Should we support optional catch bindings in general?
We've turned down stage 3 features in the past because they aren't yet stage 4.
A lot of aversion to the churn we could face if stage 3 features change before reaching stage 4.
Some non-stage-4 features are supported, e.g. JSX, JSDoc, type annotations, and object rest/spread. Of those, only the last is an ECMAScript feature, and it was decided before the TSC process. We have not accepted other PRs for stage-3 (or less) features.
Tabling for now and filing an issue for further discussion.

Resolution: Create an issue to discuss the policy and come back to it next meeting.

TSC Summary:
[eslint-cli] is the package which provides CLI command eslint which finds local-installed ESLint and runs it. I would like to transfer [eslint-cli] to eslint organization.
I think that [eslint-cli] improves eslint/eslint#6732 (comment) with updating "Getting started" page. This transferring would make peace of mind to users as the tool is supported by the eslint team.
I don't worry about copyrights because all commits of eslint-cli are mine and all dependencies are MIT license.
TSC Question: Do we accept this proposal?
This was discussed in a previous meeting, after which @ilyavolodin created a discussion about it.
@not-an-aardvark proposed making the discussion public. 👍 from @ilyavolodin, @platinumazure, @kaicataldo, @btmills, @mysticatea.
In the discussion, @platinumazure suggested asking users (probably via Twitter poll) what their use cases are and whether we need to support global installation.
Global installation is an npm feature, so if we deprecated global installation, that would mean we always look for a local installation when run globally.
We would be unlikely to ever remove CLI functionality from the eslint npm package for historical reasons.
Out of time. Moving this discussion to a public issue.

Resolution: @not-an-aardvark and @ilyavolodin will do the release on 2017-12-23.