docs: Add 2025-01-23 meeting notes

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`