Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Add 2024-03-07 meeting notes #491

Merged
merged 3 commits into from
Mar 12, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
78 changes: 78 additions & 0 deletions notes/2024/2024-03-07.md
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
- Francesco Trotta (@fasttime) - TSC

@nzakas moderated, and @sam3k took notes.

## Topics

### Proposal: Add More Columns to Triage Board

**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.

**Action Items:** @nzakas will send and email to notify team and update the triage process docs

### Proposal: 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 some weeks to complete.

**Resolution:** 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 8th, 2024

**Action Items:** @mdjermanovic will release the following:

- `eslint`
- `@eslint/js`