Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add 2019-03-14 meeting notes (closes #122)
- Loading branch information
Showing
1 changed file
with
120 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,120 @@ | ||
| # 2019-March-14 ESLint TSC Meeting Notes | ||
|
|
||
| ## Transcript | ||
|
|
||
| https://gitter.im/eslint/tsc-meetings/archives/2019/03/14 | ||
|
|
||
| ## Attending | ||
|
|
||
| * Kevin Partington (@platinumazure) - TSC | ||
| * Ilya Volodin (@ilyavolodin) - TSC | ||
| * Toru Nagashima (@mysticatea) - TSC | ||
| * Brandon Mills (@btmills) - TSC | ||
|
|
||
| Maybe: * Teddy Katz (@not-an-aardvark) - TSC | ||
|
|
||
| Additionally, the following individuals are not in attendance but support consensus: | ||
|
|
||
| * Gyandeep Singh (@gyandeeps) - TSC | ||
| * Kai Cataldo (@kaicataldo) - TSC | ||
|
|
||
| ## Topics | ||
|
|
||
| ### [Decide how to manage support for minor versions of Node](https://github.com/eslint/eslint/issues/11022) | ||
|
|
||
| **TSC Summary:** This proposal is that we decide which versions of Node to support by choosing the lowest point release of first version of Node supporting the features ESLint wants to use. The end result is that we will need to do a bit of research to determine which features we'll want to use whenever a major release happens. (We should also document this policy so we can refer back to it easily.) | ||
|
|
||
| **TSC Question:** Shall we accept this proposal? | ||
|
|
||
| * The original proposal was made by @nzakas. | ||
| * :+1: from @platinumazure, @ilyavolodin, @btmills, @mysticatea. | ||
|
|
||
| **Resolution**: We will choose Node version support based on the lowest point release supporting our desired features. | ||
|
|
||
| ### [Docs: Add working groups to maintainer guide](https://github.com/eslint/eslint/pull/11400) | ||
|
|
||
| **TSC Summary:** This is the proposal for the formation of working groups, a loose way to organize and keep track of who is working on what on the project. WGs can be created by sending an email to the team mailing list to ask for interested team members, and then creating a GitHub team to signal who those members are. | ||
|
|
||
| **TSC Action:** Shall we accept this proposal? | ||
|
|
||
| * This is consistent with and documents our existing practices. | ||
| * No objections from @platinumazure, @ilyavolodin, @not-an-aardvark, @btmills, or @mysticatea. | ||
|
|
||
| **Resolution**: We will accept the proposal. | ||
|
|
||
| ### [v6.0.0 Feature Finalization](https://github.com/eslint/eslint/projects/5) | ||
|
|
||
| #### [comma-dangle enable functions: "never" by default](https://github.com/eslint/eslint/issues/11502) | ||
|
|
||
| * The `functions: "never"` option prevents dangling commas in functions definitions and calls. This syntax is only valid in ES2017+. | ||
| : :+1: from @ilyavolodin, @platinumazure, @mysticatea | ||
| * :+1: from @btmills and @not-an-aardvark as long as we don't assume parsing ES2017 by default. | ||
|
|
||
| **Resolution**: Accept the issue and add it to the v6.0.0 milestone. | ||
|
|
||
| #### [no-confusing-arrow enable allowParens: true by default](https://github.com/eslint/eslint/issues/11503) | ||
|
|
||
| * This change would enable the `allowParens` option in `no-confusing-arrow` by default. | ||
| * :+1: from @ilyavolodin, :platinumazure, @mysticatea, @btmills, @not-an-aardvark | ||
|
|
||
| **Resolution**: Accept the issue and add it to the v6.0.0 milestone. | ||
|
|
||
| #### [Validate against invalid rule schema defaults in RuleTester](https://github.com/eslint/eslint/issues/11473) | ||
|
|
||
| * This change would enable the new `strictDefault` option in `ajv` to prevent rule authors from using the `default` keyword in places where it's ignored. | ||
| * :+1: from @not-an-aardvark, @mysticatea, @platinumazure, @ilyavolodin, @btmills. | ||
| * Additionally, @nzakas left a :+1: on the issue. | ||
|
|
||
| **Resolution**: Accept the issue and add it to the v6.0.0 milestone. | ||
|
|
||
| #### [Update: Enable ES2017 parsing and globals by default](https://github.com/eslint/rfcs/pull/16) | ||
|
|
||
| * There are four open questions in this proposal. Should we evaluate them separately? | ||
| * @nzakas already [left thoughts](https://github.com/eslint/rfcs/pull/16#issuecomment-471626372) on all four in the discussion. @ilyavolodin and @platinumazure concur with @nzakas. | ||
| * @platinumazure and @not-an-aardvark suggest tabling this proposal for v7. | ||
| * Of the four changes, the only one that might reach consensus for v6 seems to be creating a new `es2017` environment. However, we'd need to decide whether it should include `ecmaVersion` like `es6` or just `globals`. Additionally, it could be added as a semver-minor change later. | ||
| * :+1: to tabling until v7 from @platinumazure, @not-an-aardvark, @ilyavolodin, @btmills, @mysticatea | ||
|
|
||
| **Resolution**: Table this proposal for discussion leading up to v7. | ||
|
|
||
| #### [Update: Config File Improvements](https://github.com/eslint/rfcs/pull/13) | ||
|
|
||
| * eslint/rfcs#13 (this proposal) and eslint/rfcs#9 are alternative RFCs for the future direction of config files. | ||
| * @nzakas was [against](https://github.com/eslint/tsc-meetings/issues/122#issuecomment-471619967) this RFC until a common direction can be established after v6. | ||
| * Currently, `overrides` in a shareable config is calculated in such a way that it overwrites user settings in `.eslintrc.*`. One component of this RFC would fix this behavior so that `.eslintrc.*` changes are not overwritten. | ||
| * @platinumazure is :+1: to fixing `extends`/`overrides` in v6 but not the other semver-major enhancements. | ||
| * @platinumazure believes fixing `extends`/`overrides` would be semver-minor, but @not-an-aardvark believes it would be semver-major. @ilyavolodin clarifies that it would be semver-major because some users would be required to modify existing configurations. | ||
| * :+1: to including the bugfix as a breaking change in v6 from @platinumazure, @not-an-aardvark, and @ilyavolodin, and @btmills. | ||
| * Currently, glob-based `overrides` do not support `extend`ing shareable configs. This RFC would add support for that as a semver-minor enhancement. | ||
| * @btmills is in favor of fixing `extends`/`overrides` in v6 and leaving the rest of this proposal until we decide on a direction for config. @platinumazure clarifies whether that includes the enhancement or just the bugfix. @not-an-aardvark mentions that we already accepted the enhancement on [an existing issue](https://github.com/eslint/eslint/issues/8813), and it's a semver-minor change, so we do not need to approve it separately here. | ||
|
|
||
| **Resolution**: We will accept a semver-major bugfix to prevent `overrides` in shareable configs from overwriting `.eslintrc.*` configs as a breaking change in v6. | ||
|
|
||
| ### [Validate `ecmaVersion` and `sourceType` in Espree](https://github.com/eslint/espree/issues/384) | ||
|
|
||
| * This would throw an error in Espree if `ecmaVersion` is not a number or `sourceType` is not one of the allowed values. | ||
| * :+1: from @ilyavolodin, @mysticatea, @platinumazure, @btmills, @not-an-aardvark. | ||
|
|
||
| **Resolution**: We will accept such a change. | ||
|
|
||
| ### [JSCS compatibility status](https://github.com/eslint/tsc-meetings/issues/122#issuecomment-471517662) | ||
|
|
||
| **TSC Question**: How are we doing on JSCS compatibility? Is it still something we want to finish? | ||
|
|
||
| * @platinumazure feels we should try to support every case that JSCS did outside of library-specific cases for e.g. jQuery. | ||
| * @ilyavolodin feels we are done because it's been a number of years and we don't hear feedback about missing rules anymore | ||
| * @btmills points out that the `jscs` npm package sees about 1.36% as many weekly downloads as `eslint`, which could indicate that we've done enough. | ||
| * @not-an-aardvark wonders whether people are still migration and suggests saying we're mostly compatible, calling the project done, and evaluating new feature requests as we usually do. | ||
| * @platinumazure could live with @not-an-aardvark's proposal, and @btmills is also fine with it. | ||
| * @platinumazure points out that https://github.com/eslint/eslint/pull/9581, a JSCS-related PR, has been open for over a year. Should we finish it? @ilyavolodin feels the remaining differences are edge cases, and @not-an-aardvark doesn't see much demand. | ||
| * @platinumazure proposes to say we've done most of the work but will continue to consider future proposals. :+1: from @ilyavolodin, @not-an-aardvark, @mysticatea, and @btmills. | ||
|
|
||
| **Resolution**: We can close the JSCS project and call it done, and we will consider future proposals as normal requests. | ||
|
|
||
| ### [Scheduled release for March 15th, 2019](https://github.com/eslint/eslint/issues/11477) | ||
|
|
||
| * Do we need to define a 6.0.0 release timeline? | ||
| * There's plenty of issues accepted and ready to implement, so we can spend time getting those done before starting releases. | ||
| * At the very least, the March 15th release will still be part of the 5.x release stream, so we can decide at the meeting in two weeks when we want to start v6 alphas. | ||
|
|
||
| **Resolution**: @not-an-aardvark and @btmills will do a semver-minor 5.x release. |