-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
78 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,78 @@ | ||
# 2024-03-07 ESLint TSC Meeting Notes | ||
|
||
## Transcript | ||
|
||
[`2024-03-07-transcript.md`](2024-03-07-transcript.md) | ||
|
||
## Attending | ||
|
||
- Nicholas C. Zakas (@nzakas) - TSC | ||
- Milos Djermanovic (@mdjermanovic) - TSC | ||
- (@fasttime) - TSC | ||
|
||
@nzakas moderated, and @sam3k took notes. | ||
|
||
## Topics | ||
|
||
### Add More Columns to Triage Board Proposal | ||
|
||
**Agenda Item:** I'd like to suggest we add a couple new columns to the Triage board to help deal with PRs. Right now, all open PRs end up in the "Implementing" column, even though they may not all be in the same state. I propose adding "Additional Review Needed" for PRs where there is one approval but that person would like another review before merging, and "Merge Candidate" for PRs we believe are ready for merge but just want a double-check. We could then review these two columns before each release to check which ones might be ready. | ||
|
||
**Resolution:** we've agreed to add those two columns to the Triage board. I'll take the action item of doing that, documenting the change, and sending out the email to the team. | ||
|
||
**Action Items:** | ||
|
||
- @nzakas will send and email to notify team and update the triage process docs | ||
|
||
### Modify PR Approval Process | ||
|
||
**Agenda Item:** we have the repo set up so that PR approvals are not removed when new commits are pushed, which is confusing. Sometimes I've approved a PR and then there are several more commits that I haven't seen, but our settings make it seem like I've approved. GitHub has a setting that removes approvals when new commits are pushed. Shall we enable it? | ||
|
||
**Resolution:** we've agreed to dismiss stale pull requests reviews on all repos, and that we won't require re-review of previous approvers so long as our usual pull request merge requirements are met. | ||
|
||
**Action Items:** @mdjermanovic will implement this change | ||
|
||
### [feat!: move AST traversal into SourceCode](https://github.com/eslint/eslint/pull/18167) | ||
|
||
**TSC Summary:** As part of this work, we are moving the AST traversal from Linter into SourceCode. For normal AST traversal, this works exactly the same way; for code path analysis, there is actually a difference. With the traversal in Linter, the code paths are incomplete during the traversal and are only completed upon complete traversal of the AST. That means CodePathSegment fields like nextSegments and prevSegments would be empty when onCodePathSegment is called with Linter traversal, whereas they would be filled with SourceCode traversal. Rules relying on the Linter-based traversal of incomplete code path data might not work correctly when all data is present. | ||
|
||
In our codebase we have three rules that broke: no-useless-returns, no-this-before-super, and super-constructor. | ||
|
||
**TSC Question:** This would be another breaking change for v9.0.0. Are we okay with that? | ||
|
||
**Resolution:** we've agreed to include this PR in v9. | ||
|
||
**Action Items:** @nzakas will keep working on it to get to completion | ||
|
||
### [v9.0.0](https://github.com/orgs/eslint/projects/4/views/2) | ||
|
||
#### [Bug: Incorrect code path analysis for return in try blocks with catch clause](https://github.com/eslint/eslint/issues/17579) | ||
|
||
**Status:** @fasttime has just done some analysis so far. He could try to change the code path analysis as suggested [here](https://github.com/eslint/eslint/issues/17579#issuecomment-1969338176) if we are okay with that solution. This could take me some weeks to complete. We will follow up on the issue in a couple of weeks and move to v10 if we are not quite ready. | ||
|
||
#### [Change Request: Flat Config does not support FileEnumerator](https://github.com/eslint/eslint/issues/18087) | ||
|
||
**Status:** there doesn't seem to be a lot of urgency from Jordan to get this resolved, so I don't see any reason to hold up a potential release candidate for it. | ||
|
||
**Resolution:** removing from v9 board | ||
|
||
#### [feat: Add support for TS config files](https://github.com/eslint/eslint/pull/18134) | ||
|
||
**Resolution:** removing from v9 and requesting an RFC. | ||
|
||
#### [feat: support the new flat config](https://github.com/eslint/create-config/issues/51) | ||
|
||
**Status:** almost done | ||
|
||
**Action Items:** need one more reviewer | ||
|
||
#### [Switch Playground to flat config](https://github.com/eslint/eslint.org/issues/507) | ||
|
||
**Status:** almost done | ||
|
||
### Scheduled release for March 10th, 2024 | ||
|
||
**Action Items:** @mdjermanovic will release the following: | ||
|
||
- `eslint` | ||
- `@eslint/js` |