I don't know if we can do this. In the past eslint's own API eagerly loaded all of the rules for each plugin because it would eagerly iterate the plugin's .rules property. iirc it called Object.entries(plugin.rules) which meant that any lazy loading implementation didn't do anything.

I filed this with eslint core a whole back and I don't know if they ever changed their implementation. If they have then we could finally rework things to lazily load rules.

Ooh yes lazy-loading rules would be wonderful. This is such a universally useful request I don't think it should be specific typescript-eslint - I think core and every plugin should be ideally do it.

Looking back through the filing history...

1. Support Lazy Loading Rules from 3rd Party Plugins eslint/eslint#14862: originally marked as blocked pending the new flat config system
2. eslint/eslint@06439a6 & eslint/eslint@7130a27 & eslint/eslint@32ac37a: marked as closing that issue with tests to confirm flat config rules are lazy loaded

I think this should be filed on ESLint core then. What do you all think?

Eslint core can't do anything here - the plugins all need to manually set it up with a proxy or something.

If someone was to build a reusable package that made it easy to export a lazy loaded rule map though...... Might be a good thing for us to build and publish as a package...?

Hmm, it would be nice if ESLint core provided its own definePlugin / defineRule. They already provide RuleTester, defineConfig, etc. - seems like a natural next step. I don't love that we in typescript-eslint are now taking on the responsibility of figuring out lazy-loading rules.

@eslint/plugin-kit exists but it's really more of a "languages" kit. Its exports are Directive, ConfigCommentParser, etc. - nothing around defining plugins. I separately tried searching plugin-kit and similar terms on ESLint's issue tracker. This was mentioned almost a decade ago in eslint/eslint#4301 (comment) but that's about it. Filed: eslint/rewrite#176

Back in typescript-eslint: this ties into #10383. We've been wanting to do this for a bit but haven't had the time. It's definitely something we'd love to tackle eventually... but will take a lot of time and dependency shuffling. In the meantime, I think having a standalone plugin-creator package would be a great first step and something we can keep extracted out on its own.

Proposal: let's wait until discussion in eslint/rewrite#176 settles? If ESLint core is up for creating a plugin utils package then I'd think we'd want to wait until their API settles before taking any action.

Marking as blocked pending resolution to eslint/rfcs#132. Whether & how ESLint provides a lazy-loading rules in its definePlugin will determine what we do here.