Skip to content

Commit

Permalink
docs: Add 2023-03-23 meeting notes (#419)
Browse files Browse the repository at this point in the history
* docs: Add 2023-03-23 meeting notes

* Update notes/2023/2023-03-23.md

Co-authored-by: Nicholas C. Zakas <nicholas@humanwhocodes.com>

---------

Co-authored-by: Nicholas C. Zakas <nicholas@humanwhocodes.com>
  • Loading branch information
sam3k and nzakas committed Mar 30, 2023
1 parent 68d7437 commit 549817e
Showing 1 changed file with 95 additions and 0 deletions.
95 changes: 95 additions & 0 deletions notes/2023/2023-03-23.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
# 2023-03-23 ESLint TSC Meeting Notes

## Transcript

[`2023-03-23-transcript.md`](2023-03-23-transcript.md)
## Attending

* Nicholas C. Zakas (@nzakas) - TSC
* Milos Djermanovic (@mdjermanovic) - TSC

@nzakas moderated, and @sam3k took notes.

## Topics

### [feat: no-restricted-imports option added allowImportNames #16196](https://github.com/eslint/eslint/pull/16196)

**Summary:** The PR aims to add an option to the `no-restricted-imports` rule that could possibly conflict with a solution for the accepted issue. This PR keeps getting stale warnings and it looks like it's ready for review. However, we should consider finishing the design in issue [#15261](https://github.com/eslint/eslint/issues/15261) before moving forward with this change.

**Resolution:** We've decided to hold off on merging the PR and update the issue with a summary.

**Action Item:**
* @mdjermanovic will summarize the current state of the issue as a comment

### [Change Request: add ability to shard eslint #16726](https://github.com/eslint/eslint/issues/16726)

**Summary:** Request to add a `--shard` to the CLI that will limit which files are linted. This would allow others to more easily implement parallel linting. Jest and Vitest have a similar flag.

**Resolution:** We've decided to accept a RFC for `--shard` so we can determine whether or not to move forward.

### [Rule Change: [no-loop-func] don’t warn when control flow will always leave the loop #16954](https://github.com/eslint/eslint/issues/16954)

**Summary:** Propose changing `no-loop-func` to exempt a particular pattern.

> @nzakas:
>
> We've always said that we want rules to cover the 90% case, and I think this definitely falls within the 10% case.
>
**Resolution:** We are not going to accept this proposal as the complexity cost is too high.

### [New Rule: disallow assigning class static field #16921](https://github.com/eslint/eslint/issues/16921)

**Summary:** Implement a new rule to prefer static fields.

> @mdjermanovic
>
> In my opinion, this pattern is what the class static fields are designed for
>
> I think the proposal makes sense. However, I'm not sure how much would the rule be able to detect what should be converted to static fields, it would have to do an extensive analysis of the code that comes after the class definition.
>
> And class static fields don't fall under our policies of features added in the last 12 months, so I'll be more in favor of not accepting the proposal.
**Resolution:** We've decided to not accept this proposal

### [Rule Change: [no-loop-func] add an option to ignore IIFEs #16902](https://github.com/eslint/eslint/issues/16902)

**Summary** This seeks to change the behavior of `no-loop-func` to not warn on IIFEs. It seems you and fasttime both are in favor, and I don't have an objection.

**Q&A**

**It seems like the open question is about whether or not to add an option?**
A: Given the purpose of this rule, I don't think an option is necessary

**Do we want to keep reporting on IIFEs inside of async and generator functions?**
Yes, we should keep reporting on that, as it's a code that isn't immediately executed

**Resolution:** we have agreed to:
1. Accept the proposal
2. Not add an option and instead make this change a default behavior
3. Continue warning in the async/generator case.

### [Implement Flat Config #13481](https://github.com/eslint/eslint/issues/13481)

**Summary** We have completed phase 2 for flat config development and the next phase is to do compatibility testing. For that, I envision working with each plugin to get their own repo converted to flat config to see what breaks.

**Action Items:**
* @mdjermanovic will work on the compatability testing / converting the following plugins to use flat config:
* `eslint-plugin-n`
* `eslint-plugin-import`
* `eslint-plugin-react`
* `eslint-config-airbnb`
* @nzakas will convert the rest

### Release

**Summary:** The following packages will be going out in this release:
* `eslint-visitor-keys`
* `espree`
* `@eslint/eslintrc`
* `@eslint/js`
* `eslint`

**Action Items:**
* @mdjermanovic will do this release
* @mdjermanovic will try doing a test release with release-please on either `@eslint/create-config` or `espree` to increase adoption of release-please
* @mdjermanovic will manually post the release update on Mastodon

0 comments on commit 549817e

Please sign in to comment.