Milos Djermanovic

> Or we could even make it a symbol property if we didn't want to make it obvious: > > ```js > const { ESLint, ESLintSymbol } = require("eslint"); >...

> I think the first option makes it easier to feature test the existence of the new property. Then, the first option. We could also make it readonly (e.g., by...

Looks like we have all the details defined now. @voxpelli would you like to submit a PR to implement this?

> * Should options be added for the frozen `one-var` as it normalizes the options only to the prior known `var/let/const` (in other words `using` and `await using` are just...

> * `require-await` + `no-await-in-loop`: Should the rule documentation explicitly mention `await using`? I think we should at least add examples with `await using`.

> * `no-undef-init`: does not need to be updated as it is a parse error for initializing to undefined in this case Initializing to `undefined` is valid, although probably a...

I'm not in favor of string references, for several reasons: 1. It wouldn't work for shareable configs, so users would eventually have a mix of objects/arrays (direct references to shareable...

Aside from string references, I'm in favor of the proposal. 1. Allow nested arrays. We disabled this feature because it makes applying a shareable/plugin config to only certain files more...

Can you provide an overview and clarify with a few examples what patterns would be considered invalid by this rule?

I agree with suggestions instead of autofixes, and the `preserve-caught-error` name sounds good to me. I'm only not sure what exactly this rule enforces, based on this example: > ```js...