Skip to content

Commit 28d690b

Browse files
sam3kmdjermanovic
andauthored
docs: Add 2025-02-20 meeting notes (#566)
* docs: Add 2025-02-20 meeting notes * Update notes/2025/2025-02-20.md --------- Co-authored-by: Milos Djermanovic <[email protected]>
1 parent e299998 commit 28d690b

File tree

1 file changed

+54
-0
lines changed

1 file changed

+54
-0
lines changed

notes/2025/2025-02-20.md

+54
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
# 2025-02-20 ESLint TSC Meeting Notes
2+
3+
## Transcript
4+
5+
[`2025-02-20-transcript.md`](2025-02-20-transcript.md)
6+
7+
## Attending
8+
9+
- Nicholas C. Zakas (@nzakas) - TSC
10+
- Francesco Trotta (@fasttime) - TSC
11+
- Milos Djermanovic (@mdjermanovic) - TSC
12+
13+
@nzakas moderated, and @sam3k took notes.
14+
15+
## Topics
16+
17+
### Statuses
18+
19+
* **@nzakas:** been working on the CSS plugin, the `defineConfig()` helper, and various publishing improvements in `eslint/rewrite`. Also added JSX support to eslint-scope
20+
* **@mdjermanovic:** mostly reviewing PRs
21+
* **@fasttime:** mostly reviewing PRs and worked on the fix for the retry utility
22+
23+
24+
### RFC Duty update:
25+
* This week - @fasttime
26+
* Feb 24 - @nzakas
27+
* Mar 3 - @mdjermanovic
28+
29+
### [Change Request: Make rules TypeScript syntax-aware](https://github.com/eslint/eslint/issues/19173)
30+
31+
**TSC Summary:** In this issue, we agreed to start making some core rules TypeScript syntax-aware.
32+
33+
**TSC Question:** Should we add something into the rule meta to reflect this? If so, what should it be? And should we take into account that rules may be aware of other languages and/or types as well?
34+
35+
**Resolution:** we've agreed to add `meta.language` and `meta.dialects`, starting with rules that are TypeScript-enabled. We can revisit discussions around how to use that data at a later time.
36+
37+
### CSSTree Future
38+
39+
**TSC Summary:** While CSSTree is an excellent parser, it appears to be maintained by just one person and the turnaround time on fixes is very long. Should we fork CSSTree and use that for @eslint/css by default? The intention is to continue to push on CSSTree to implement the changes we need by submitting PRs back upstream. Ideally, most of these changes would be transparent to rules and when they're not, hopefully we can get some feedback on proposed API changes.
40+
41+
**Resolution:** we've decided to create a fork of CSSTree (`@eslint/css-tree`).
42+
43+
**Action Items:** @nzakas will work on getting that set up some time in the next week.
44+
45+
46+
### Scheduled release for February 21st, 2025
47+
48+
**Action Items:**
49+
50+
- @fasttime will release:
51+
- `@eslint/core`
52+
- `@eslint/eslintrc`
53+
- `eslint`
54+

0 commit comments

Comments
 (0)