[TODO]: explicit-module-boundary-types

[Tobbe]

Add explicit-module-boundary-types to the eslint rules the framework itself uses

[lisa-assistant]

Implementation Plan

The request is to add @typescript-eslint/explicit-module-boundary-types to the ESLint rules used by the framework itself.

What the rule does

Requires that all exported functions and class methods have explicit return types. This catches cases where the inferred return type silently changes (e.g., you add a code path that returns null and the type widens unexpectedly).

Where to add it

packages/eslint-config/shared.js — in the existing TypeScript override block (around line 155):

{
  files: ['*.ts', '*.tsx'],
  parser: '@typescript-eslint/parser',
  extends: ['plugin:@typescript-eslint/recommended', 'prettier'],
  rules: {
    // existing rules...
    '@typescript-eslint/explicit-module-boundary-types': 'warn', // start as warn, then promote to error
  },
},

Starting at 'warn' rather than 'error' is pragmatic — there will be a large number of existing violations across the codebase and you'd want to fix them incrementally before enforcing hard failures.

Rollout approach

1. Add the rule as 'warn' in shared.js.
2. Run yarn lint across the packages to count violations.
3. Fix the violations package-by-package (or use a codemod: @typescript-eslint includes an auto-fix for this rule).
4. Once clean, promote to 'error'.

Gotchas

• The rule only applies to exported symbols, so internal helpers are unaffected.
• Arrow functions assigned to export const are covered.
• If the count of violations is very high, it may be worth scoping the rule to specific packages first (e.g., packages/router, packages/graphql-server) rather than enabling it globally.
• The @typescript-eslint/recommended preset does not include this rule by default, so it won't be a duplicate.
• Check packages/eslint-config/index.js to see if there's a project-facing config separate from the framework config that should also get the rule eventually.

[lisa-assistant]

Self-fix confidence: 7/10
Adding the rule itself is trivial. The bulk of the work is fixing the resulting violations across the codebase — the count could be large and some return types may need thought (generics, conditional types). High confidence on the mechanical part, moderate on getting every type annotation right without introducing regressions.