From 7020f978f69a5788b1f9da7b910a16267e27cfb1 Mon Sep 17 00:00:00 2001 From: Samuel Roldan Date: Tue, 28 Jan 2025 12:01:43 -0500 Subject: [PATCH] docs: Add 2025-01-23 meeting notes --- notes/2025/2025-01-23.md | 84 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 notes/2025/2025-01-23.md diff --git a/notes/2025/2025-01-23.md b/notes/2025/2025-01-23.md new file mode 100644 index 0000000..247f6a0 --- /dev/null +++ b/notes/2025/2025-01-23.md @@ -0,0 +1,84 @@ +# 2025-01-23 ESLint TSC Meeting Notes + +## Transcript + +[`2025-01-23-transcript.md`](2025-01-23-transcript.md) + +## Attending + +- Nicholas C. Zakas (@nzakas) - TSC +- Francesco Trotta (@fasttime) - TSC +- Milos Djermanovic (@mdjermanovic) - TSC + +@nzakas moderated, and @sam3k took notes. + +## Topics + +### Statuses + +* **@nzakas:** worked on getting the GitHub bot working again, the extends RFC, the year in review post, and the CSS plugin. +* **@mdjermanovic:** mostly reviewing PRs, then reviewing financial data, and prepared a PR for additional checks of rule examples. +* **@fasttime:** mostly busy triaging and reviewing stuff, did some work on language plugin types and extended the multithread linting RFC. Also worked on the browser tests + + +### RFC Duty update: +* Jan 20 - @mdjermanovic +* Jan 27 - @fasttime +* Feb 3 - @nzakas + +### [Bug: Error is thrown in `9.18.0` if `unstable_ts_config` flag is used](https://github.com/eslint/eslint/issues/19337) + +**TSC Summary:** This issue proposes that we change inactive flags to emit warnings instead of errors in these situations: + +* An unstable flag becomes inactive because the feature is now enabled by default. +* A stable flag becomes inactive because the feature is now enabled by default. +* A flag moves from unstable to stable. The unstable flag should work just like the stable flag except that it emits a warning. + +If an unstable flag is removed because the functionality is abandoned, then it throws an error. + +**TSC Questions:** + +1. Should we accept this proposal? +2. Should inactive flags ever be removed? + +**Resolution:** we've decided: + +* We will accept the proposal as described in the issue. +* Inactive flags will be removed each major release. +* Abandoned features that will not land in ESLint should be removed (functionality and flag) in the next minor release. + +**Action Items:** @mdjermanovic will describe these details on https://eslint.org/docs/latest/flags/ when the new functionality is implemented. + + +### [Change Request: Provide a better system than "extension" rules](https://github.com/eslint/eslint/issues/19173) + +**TSC Summary:** This issue proposes starting to make ESLint core rules TypeScript-aware in order to eliminate duplication with typescript-eslint. + +**TSC Question:** Do we want to accept this proposal? + +**Resolution:** we would like to accept this proposal but make it TypeScript syntax-aware, not type-aware. + +### Ajv & Old Node.js Deprecation Warnings + + We're on an old version that is still working, but we've been getting complaints about deprecation warnings on Node.js v22. The last time we tried to upgrade it broke existing rules. + +**Options:** +1. Do we want to create our own fork of Ajv so we can make any changes we want? +2. Do we want to try to upgrade it and see if the warning goes away? +3. Do we want to investigate switching to a different package? + +For some context, it's actually Node.js itself that's emitting this warning, not npm, so people are seeing it whenever they run ESLint on Node.js v22. + +**Resolution:** we've decided to fork it for now as it's easiest course of action. + +**Action Items:** @fasttime will fork Ajv + +### Scheduled release for January 24th, 2025 + +**Action Items:** + +- @mdjermanovic will release: + - `eslint` + - `@eslint/js` + - `@eslint/markdown` + - `@eslint/json`