This occurs when people ask TS to emit declarations and can be fixed by turning it off.

Though I don't know how to actually fix this from our side - how can you get TS to name the type?? Do we need to document that people must export it from the same place they export their rule creator?

Maybe we can make a standalone type for ... well, RuleCreator is the name of the function, but what it returns?

Edit: And/or... I don't like this but 😄 :

import { ESLintUtils } from "@typescript-eslint/utils";

export const createRule: ReturnType<typeof ESLintUtils.RuleCreator> =
	ESLintUtils.RuleCreator((name) => `.../${name}.md`);

Edit 2: ...and...

import { TSESLint } from "@typescript-eslint/utils";

import { myRule } from "./myRule.js";

export const rules: Record<string, TSESLint.RuleModule<string, unknown[]>> = {
	"my-rule": myRule,
};

Maybe we can make a standalone type for ... well, RuleCreator is the name of the function, but what it returns?

We already have it - it returns a RuleModule which can easily be named by end users.

The problem is that people aren't importing their local rule creator from our module - they're importing it from their local module. So TS can't name the RuleModule type.

What I was saying is that I assume that this could be fixed like this by users:

export const createRule = ...;
export {RuleModule} from '@typescript-eslint/utils/ts-eslint';

As that would export the type from the same module as the function and thus TS could mutate the export during the emit without side-effects.

The problem with your second edit is that you lose the options types.
It also doesn't fix the issue because TS still wants to generate types per file.

That fix would actually work if you added the import to every single rule file though!

I feel like I've been away from serious TS coding for too long that I can't wrap my head around this error 😅

@Josh-Cena this should help clarify why it happens

copy pasted for clarity

When you turn on declaration files, TS requires all types to be "fully resolvable" without changes to the code.
All of our lint rules export default createRule(...), which means they all implicitly reference the TSESLint.Rule type for the export.

TS wants to transpile each rule file to this .d.ts file:

import type { TSESLint } from '@typescript-eslint/utils'; 
declare const _default: TSESLint.RuleModule<TMessageIds, TOptions, TSESLint.RuleListener>; 
export default _default; 

Because we don't import TSESLint in most files, it means that TS would have to insert a new import during the declaration emit to make this work.
However TS wants to avoid adding new imports to the file because a new module could have type side-effects (like global augmentation) which could cause weird type side-effects in the decl file that wouldn't exist in source TS file.

So TS errors on most of our rules with the following error:

The inferred type of 'default' cannot be named without a reference to 
'../../../../node_modules/@typescript-eslint/utils/src/ts-eslint/Rule'. 
This is likely not portable. A type annotation is necessary. ts(2742)

The fix is to make the source code add the required import - then TS can add the required name to that import and everything will work fine.

Hence a possible solution is to do something like document that the rule creator file should be this:

import { ESLintUtils } from "@typescript-eslint/utils/eslint-utils";

export const createRule = ESLintUtils.RuleCreator((name) => `.../${name}.md`);
export {RuleModule} from '@typescript-eslint/utils/ts-eslint';

So that when people call createRule, TS can just add the RuleModule import from their local module, rather than from the not imported ts-eslint module.
Maybe... IDK if it would actually work.

This PR should fix it without actions on the userland: #7690 - Thanks to the existing discussions 😆

If there's still documentation for steps folks should do in their code (e.g. taking on a full dependency on @typescript-eslint/utils), we can always re-open this issue or just take it on as part of #5444.

Edit: as in, if you feel this issue isn't resolved, please file a new one with your reproduction case. We'd be happy to take a look!

I have faced this issue for several weeks. My workaround is enabling "stripInternal": true in tsconfig.json and marking the exported rule @internal.

/**
 * @internal
 */
export const createRule = ESLintUtils.RuleCreator((name) => `.../${name}.md`);