Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
* Add 2019-12-05 meeting notes (closes #156) * Update notes/2019/2019-12-05.md Co-Authored-By: Toru Nagashima <public@mysticatea.dev>
- Loading branch information
1 parent
41ec302
commit 58a31b4
Showing
1 changed file
with
125 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,125 @@ | ||
| # 2019-December-05 ESLint TSC Meeting Notes | ||
|
|
||
| ## Transcript | ||
|
|
||
| https://gitter.im/eslint/tsc-meetings/archives/2019/12/05 | ||
|
|
||
| ## Attending | ||
|
|
||
| * Kevin Partington (@platinumazure) - TSC | ||
| * Brandon Mills (@btmills) - TSC | ||
| * Toru Nagashima (@mysticatea) - TSC | ||
| * Kai Cataldo (@kaicataldo) - TSC | ||
|
|
||
| Additionally, the following individuals are not in attendance but support consensus: | ||
|
|
||
| * Nicholas C. Zakas (@nzakas) - TSC | ||
|
|
||
| ## Topics | ||
|
|
||
| ### [New: Include node version in cache](https://github.com/eslint/eslint/pull/12582) | ||
|
|
||
| * **TSC Summary**: This PR proposes to include the Node version when hashing the cache key, ensuring that the cache is busted when consecutive linting runs are executed with different Node versions. | ||
| * **TSC Question**: Should we accept this? | ||
| * @platinumazure and @ilyavolodin already left a :+1: on the pull request. | ||
| * :+1: from @mysticatea, @kaicataldo, and @btmills. | ||
|
|
||
| **Resolution**: The proposal is accepted. | ||
|
|
||
| ### [Can adding warnings (without adding errors) ever be semver-minor?](https://github.com/eslint/tsc-meetings/issues/156#issuecomment-561960565) | ||
|
|
||
| #### TSC Summary | ||
|
|
||
| In [this comment](https://github.com/eslint/rfcs/pull/34#issuecomment-540832712), 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 | ||
|
|
||
| #### Discussion | ||
|
|
||
| * This is currently blocking [RFC #34](https://github.com/eslint/rfcs/pull/34). | ||
| * We currently conflate linting warnings, configuration warnings, and deprecation warnings, so we aren't able to treat them separately. | ||
| * @mysticatea references the [Node.js guide on deprecations](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#deprecations) and feels that runtime deprecations should not occur in minor versions. | ||
| * This proposal only needs a decision on configuration warnings, so we can ignore deprecation warnings for now. | ||
| * @kaicataldo is in favor of updating our semver policy to permit introducing warnings that provide information to the user in semver-minor releases. | ||
| * @mysticatea is fine adding warnings to improve UX in minor releases, but not adding warnings for what is current normal usage. | ||
| * @btmills is supportive of changing the semver policy to allow adding configuration warnings in semver-minor releases because minor pain to fix a configuration issue during an upgrade is better than allowing the tool to continue doing something different than intended. | ||
| * @kaicataldo and @btmills both express interest in a future change to separate configuration messages from lint messages. | ||
| * @platinumazure can open an issue with a proposal detailing which kinds of warnings can be added in semver-minor releases. | ||
| * :+1: to accepting this proposal pending a final design hashed out in @platinumazure's issue from @btmills, @kaicataldo, @platinumazure, and @mysticatea. | ||
|
|
||
| **Resolution**: The proposal is accepted in principle, and @platinumazure will open an issue with a detailed design. | ||
|
|
||
| ### [When to start merging ESLint v7 breaking changes](https://github.com/eslint/tsc-meetings/issues/156#issuecomment-561964344) | ||
|
|
||
| #### TSC Summary | ||
|
|
||
| Previously, we discussed ESLint v7 schedule ([note](https://github.com/eslint/tsc-meetings/blob/master/notes/2019/2019-10-10.md#eslint-v7-schedule)). 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? | ||
|
|
||
| * @kaicataldo notes that since there are a lot of holidays around this time, people might be less active than usual. | ||
| * :+1: from @kaicataldo, @btmills, and @platinumazure | ||
|
|
||
| **Resolution**: The proposal is accepted, and we will start merging breaking changes after concluding the release cycle that will start on 2019-12-20. | ||
|
|
||
| ### [New: `LinterShell` Class Replacing `CLIEngine`](https://github.com/eslint/tsc-meetings/issues/156#issuecomment-561964344) | ||
|
|
||
| * **TSC Summary:**: Previously, we discussed about eslint/rfcs#40 ([note](https://github.com/eslint/tsc-meetings/blob/master/notes/2019/2019-11-07.md#new-eslint-class-replacing-cliengine)). 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 shared others' concerns about using `AsyncIterator<LintResult>` as an interface to return lint results, but that has since been replaced by `Promise<LintResult>` in the updated RFC. | ||
| * In order to support ESM configuration files and plugins, we need to load them asynchronously. | ||
| * In order to support parallel linting, the lint result also needs to be asynchronous. | ||
| * @platinumazure is convinced of the general need for this. | ||
| * @btmills is more favorably inclined toward this version after earlier feedback has been addressed and would like to do a thorough pass with the goal of merging. | ||
| * @kaicataldo proposes reviewing the RFC outside the meeting. | ||
| * :+1: from @mysticatea, @btmills, and @platinumazure. | ||
|
|
||
| **Resolution**: We will review the RFC in its current state and give feedback there. | ||
|
|
||
| ### [Remove `bower_components` from default ignores](https://github.com/eslint/tsc-meetings/issues/156#issuecomment-562225657) | ||
|
|
||
| #### TSC Summary | ||
|
|
||
| Quote from the [discussion in RFC51](https://github.com/eslint/rfcs/pull/51#discussion_r352290111): | ||
|
|
||
| > 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. | ||
| > 1. We change it to `/**/bower_components/*`. | ||
| > 1. 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)? | ||
|
|
||
| * :+1: from @platinumazure, @kaicataldo, @btmills, and @mysticatea to removing in v7. | ||
|
|
||
| **Resolution**: We will remove `bower_components` from the default ignores in ESLint v7. @mysticatea will update the RFC. | ||
|
|
||
| ### [Scheduled release for December 6th, 2019](https://github.com/eslint/eslint/issues/12603) | ||
|
|
||
| * If we want to maintain the 4 week release cycle, we can close this and let the bot generate a new release issue. | ||
| * :+1: to closing from @platinumazure, @btmills, @kaicataldo, and @mysticatea. | ||
|
|
||
| **Resolution**: We will close this issue and pick up the next release cycle on December 20th. |