silverwind

How would the rule detect whether something is an iterator? Does it do that via type information to detect the presence of a `.next` method?

That detects this one specific use case of `.toArray()`, but I think `Array.from(iterable)` is a more well-known alternative, It's what I'd use to turn anything iterable into an array, not...

Regarding the `jiti`/`unstable_native_nodejs_ts_config` situation see https://github.com/eslint/eslint/issues/19985#issuecomment-3554175889 for a proposal on how to make it optional.

Workaround: ```ts declare module 'eslint-plugin-github' { import type {Eslint} from 'eslint'; const plugin: Eslint.Plugin; export = plugin; }

As requested in https://github.com/go-gitea/gitea/issues/24681, it should also be possible to just comment on multiple lines via shift-click selection, even without an suggestion.

> ` ``` suggestion` I see no need for this. Language can just be determined from the currently edited file for syntax highlighting purpose.

> A similar issue happens when using this library (https://floating-ui.com/docs/usefloating): This is a false-positive as per https://github.com/floating-ui/floating-ui/discussions/3405.

I'm suprprised that [`@type`](https://www.typescriptlang.org/docs/handbook/intro-to-js-ts.html#providing-type-hints-in-js-via-jsdoc) does not work out of the box with this eslint plugin, as it's a core typescript feature. I had to uninstall the plugin because of this.

Do we really need to split the "not planned" state? I think it's unnecessary and by having these sub-states, migrations from GitHub will become more inaccurate too.

@delvh I see no disagreement in your comment. So GitHub has: - open - close (completed) - close (not planned) With https://github.com/go-gitea/gitea/pull/25362 we would have: - open - close (resolved)...