Skip to content

Migrate eslint to v10#105

Merged
notaphplover merged 2 commits intomasterfrom
chore/eslint-migration
Mar 15, 2026
Merged

Migrate eslint to v10#105
notaphplover merged 2 commits intomasterfrom
chore/eslint-migration

Conversation

@notaphplover
Copy link
Member

@notaphplover notaphplover commented Mar 15, 2026

Changed

  • Migrate eslint to v10.

Summary by CodeRabbit

  • Chores

    • Upgraded ESLint to 10.0.3 across packages and added two linting dev-tools.
    • Expanded lint inputs to include ESLint config files.
  • Style / Linting

    • Applied stricter lint rules to enforce consistent type imports and require-extensions checks.
  • Tests

    • Adjusted tests to use dynamic import-based mocks for more robust module resolution.

@notaphplover notaphplover self-assigned this Mar 15, 2026
@changeset-bot
Copy link

changeset-bot bot commented Mar 15, 2026

⚠️ No Changeset found

Latest commit: cb64ecd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link

coderabbitai bot commented Mar 15, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 5fcc2cab-b04a-46a2-9120-92893a9bbadc

📥 Commits

Reviewing files that changed from the base of the PR and between 89bc2ce and cb64ecd.

📒 Files selected for processing (7)
  • packages/apollo-core/eslint.config.mjs
  • packages/apollo-express/eslint.config.mjs
  • packages/apollo-subscription-ws/eslint.config.mjs
  • packages/apollo-subscription-ws/src/apollo/modules/ApolloSubscriptionServerContainerModule.int.spec.ts
  • packages/apollo-subscription-ws/src/apollo/modules/ApolloSubscriptionServerContainerModule.spec.ts
  • packages/codegen/eslint.config.mjs
  • packages/codegen/src/io/actions/writeDefinitions.spec.ts
🚧 Files skipped from review as they are similar to previous changes (3)
  • packages/codegen/src/io/actions/writeDefinitions.spec.ts
  • packages/apollo-express/eslint.config.mjs
  • packages/apollo-subscription-ws/src/apollo/modules/ApolloSubscriptionServerContainerModule.spec.ts

📝 Walkthrough

Walkthrough

Standardizes TypeScript imports to type-only where possible, updates multiple package ESLint configs to enable consistent-type-imports and require-extensions rules (and bumps ESLint), converts many vitest.mock calls to dynamic import forms, adds explicit typing to a knip workspace config, and expands Turbo lint inputs.

Changes

Cohort / File(s) Summary
Root / tooling
package.json, turbo.json
Added devDeps @eslint/js and @inversifyjs/eslint-plugin-require-extensions; expanded turbo lint inputs to include eslint.config.{cjs,mjs,js,json}.
knip config
knip.ts
Added explicit WorkspaceProjectConfig type annotation to defaultWorkspaceProjectConfig; switched an import to type-only for KnipConfig and added WorkspaceProjectConfig as a type import.
ESLint configs
packages/*/eslint.config.mjs (packages/apollo-core/eslint.config.mjs, packages/apollo-express/eslint.config.mjs, packages/codegen/eslint.config.mjs, packages/apollo-subscription-ws/eslint.config.mjs)
Replaced plain buildDefaultConfig() spreads with calls that pass rule overrides and register @inversifyjs/eslint-plugin-require-extensions; enabled @typescript-eslint/consistent-type-imports and require-extensions rules.
ESLint versions
packages/*/package.json (packages/apollo-core/package.json, packages/apollo-express/package.json, packages/apollo-fastify/package.json, packages/apollo-subscription-ws/package.json, packages/codegen/package.json)
Bumped eslint devDependency from 9.39.4 to 10.0.3 across multiple packages.
Type-only imports — runtime → type
packages/apollo-core/src/.../ApolloServerController.ts, packages/apollo-core/src/.../inversifyApolloProviderServiceIdentifier.ts, packages/apollo-core/src/.../ApolloServerContainerModule.ts, packages/apollo-core/src/.../ApolloServerContainerModule.spec.ts, packages/apollo-express/src/.../buildApolloServerExpressController.ts, packages/apollo-express/src/.../ApolloExpressServerContainerModule.ts, packages/apollo-subscription-ws/src/.../ApolloSubscriptionServerContainerModule.int.spec.ts, packages/codegen/src/.../generateTsModels.ts, packages/codegen/src/io/.../writeDefinitions.ts
Converted several value imports to type-only imports (BaseContext, ServiceIdentifier, ApolloServer, Newable, various option/config types and plugin types). No runtime behavior changes.
Test mock updates (dynamic imports)
packages/apollo-express/src/.../ApolloExpressServerContainerModule.spec.ts, packages/apollo-fastify/src/.../ApolloFastifyServerContainerModule.spec.ts, packages/apollo-subscription-ws/src/.../ApolloSubscriptionServerContainerModule.spec.ts, packages/codegen/src/io/.../writeDefinitions.spec.ts, packages/codegen/src/io/calculations/parseGraphqlFile.spec.ts, packages/codegen/src/io/calculations/readSchemas.spec.ts
Replaced static-string vitest.mock('...') calls with dynamic vitest.mock(import('...')) forms (and minor test typing adjustments).
Minor test typing tweaks
packages/apollo-core/src/.../*.spec.ts, packages/apollo-subscription-ws/src/.../*.spec.ts, packages/codegen/src/.../*.spec.ts
Changed some test imports to type imports (e.g., Mock, Mocked) and adjusted casts for mocked modules.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

Poem

🐰 I nibbled types, then hopped away,

Swapped runtime imports for lighter clay,
ESLint rules sharpened my trail,
Dynamic mocks bounce without fail,
Hooray for tidy hops today! 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title 'Migrate eslint to v10' directly and clearly summarizes the main objective of the changeset, which is upgrading ESLint across multiple package configurations.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch chore/eslint-migration
📝 Coding Plan
  • Generate coding plan for human review comments

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
turbo.json (1)

15-15: Re-include tsx in lint.inputs to avoid cache misses.

lint now ignores src/**/*.tsx changes while other tasks still track them. That can skip lint reruns for TSX edits.

♻️ Proposed fix
-      "inputs": ["src/**/*.{cts,mts,ts}", "eslint.config.{cjs,mjs,js,json}"]
+      "inputs": ["src/**/*.{cts,mts,ts,tsx}", "eslint.config.{cjs,mjs,js,json}"]
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@turbo.json` at line 15, The lint task's "inputs" array in turbo.json
currently omits .tsx files causing lint cache misses; update the "inputs" value
used for lint (the "inputs" array entry that currently lists
"src/**/*.{cts,mts,ts}" and "eslint.config.{cjs,mjs,js,json}") to also include
"src/**/*.{tsx,cts,mts,ts}" so TSX changes are tracked and lint reruns when .tsx
files change.
packages/codegen/eslint.config.mjs (1)

3-23: Consider extracting this ESLint overlay once.

This rules/plugin block is now identical in packages/apollo-core/eslint.config.mjs, packages/apollo-express/eslint.config.mjs, and this file. Pulling it into a small shared helper would keep the next ESLint/plugin tweak single-sourced.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/codegen/eslint.config.mjs` around lines 3 - 23, The ESLint
rules/plugins block duplicated across packages should be extracted into a shared
helper: create a small exported function (e.g., createRequireExtensionsOverlay)
that returns the object passed to buildDefaultConfig (including the rules
'@typescript-eslint/consistent-type-imports' config and
'require-extensions/require-extensions' and 'require-extensions/require-index')
and the plugins map that includes plugin (the imported
'@inversifyjs/eslint-plugin-require-extensions'); replace the inline block in
packages/codegen/eslint.config.mjs (and the identical blocks in
packages/apollo-core/eslint.config.mjs and
packages/apollo-express/eslint.config.mjs) with a call to
buildDefaultConfig(...createRequireExtensionsOverlay()) or similar, export the
helper from a shared location used by these package configs so future changes
are single-sourced.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/codegen/src/io/actions/writeDefinitions.spec.ts`:
- Around line 3-8: Replace the dynamic import overloads with the
string-specifier overloads and return a mock shaped like the real module: change
vitest.mock(import('node:fs/promises')) to vitest.mock('node:fs/promises') and
change vitest.mock(import('prettier'), () => ({ default: { format: vitest.fn() }
})) to vitest.mock('prettier', () => ({ format: vitest.fn() })), so the mocked
exports match Prettier’s named-export interface and bypass the strict factory
type-checking.

---

Nitpick comments:
In `@packages/codegen/eslint.config.mjs`:
- Around line 3-23: The ESLint rules/plugins block duplicated across packages
should be extracted into a shared helper: create a small exported function
(e.g., createRequireExtensionsOverlay) that returns the object passed to
buildDefaultConfig (including the rules
'@typescript-eslint/consistent-type-imports' config and
'require-extensions/require-extensions' and 'require-extensions/require-index')
and the plugins map that includes plugin (the imported
'@inversifyjs/eslint-plugin-require-extensions'); replace the inline block in
packages/codegen/eslint.config.mjs (and the identical blocks in
packages/apollo-core/eslint.config.mjs and
packages/apollo-express/eslint.config.mjs) with a call to
buildDefaultConfig(...createRequireExtensionsOverlay()) or similar, export the
helper from a shared location used by these package configs so future changes
are single-sourced.

In `@turbo.json`:
- Line 15: The lint task's "inputs" array in turbo.json currently omits .tsx
files causing lint cache misses; update the "inputs" value used for lint (the
"inputs" array entry that currently lists "src/**/*.{cts,mts,ts}" and
"eslint.config.{cjs,mjs,js,json}") to also include "src/**/*.{tsx,cts,mts,ts}"
so TSX changes are tracked and lint reruns when .tsx files change.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7157032e-5849-411d-a146-269e791687a1

📥 Commits

Reviewing files that changed from the base of the PR and between 2546129 and 89bc2ce.

📒 Files selected for processing (25)
  • knip.ts
  • package.json
  • packages/apollo-core/eslint.config.mjs
  • packages/apollo-core/package.json
  • packages/apollo-core/src/apollo/controllers/ApolloServerController.ts
  • packages/apollo-core/src/apollo/models/inversifyApolloProviderServiceIdentifier.ts
  • packages/apollo-core/src/apollo/modules/ApolloServerContainerModule.spec.ts
  • packages/apollo-core/src/apollo/modules/ApolloServerContainerModule.ts
  • packages/apollo-express/eslint.config.mjs
  • packages/apollo-express/package.json
  • packages/apollo-express/src/apollo/controllers/buildApolloServerExpressController.ts
  • packages/apollo-express/src/apollo/modules/ApolloExpressServerContainerModule.spec.ts
  • packages/apollo-express/src/apollo/modules/ApolloExpressServerContainerModule.ts
  • packages/apollo-fastify/package.json
  • packages/apollo-fastify/src/apollo/modules/ApolloFastifyServerContainerModule.spec.ts
  • packages/apollo-subscription-ws/package.json
  • packages/apollo-subscription-ws/src/apollo/modules/ApolloSubscriptionServerContainerModule.spec.ts
  • packages/codegen/eslint.config.mjs
  • packages/codegen/package.json
  • packages/codegen/src/graphql/actions/generateTsModels.ts
  • packages/codegen/src/io/actions/writeDefinitions.spec.ts
  • packages/codegen/src/io/actions/writeDefinitions.ts
  • packages/codegen/src/io/calculations/parseGraphqlFile.spec.ts
  • packages/codegen/src/io/calculations/readSchemas.spec.ts
  • turbo.json

Comment on lines 3 to 8
vitest.mock(import('node:fs/promises'));
vitest.mock(import('prettier'), () => ({
default: {
format: vitest.fn(),
},
}));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cat -n packages/codegen/src/io/actions/writeDefinitions.spec.ts | head -20

Repository: inversify/graphql

Length of output: 818


🏁 Script executed:

# Check for vitest config
find . -name 'vitest*.config.*' -o -name 'vite.config.*' | head -5

Repository: inversify/graphql

Length of output: 278


🏁 Script executed:

# Check package.json for vitest version
cat packages/codegen/package.json | grep -A2 -B2 'vitest'

Repository: inversify/graphql

Length of output: 560


🏁 Script executed:

# Look for any TypeScript errors or build output
find . -name 'tsconfig*.json' | head -3

Repository: inversify/graphql

Length of output: 182


🌐 Web query:

Vitest 4.1.0 mock API vitest.mock import Promise overload vs string specifier type checking

💡 Result:

In Vitest v4.x (incl. 4.1.0), vi.mock is intentionally typed with two overloads: one that takes a string specifier, and one that takes a dynamic import() promise. (main.vitest.dev)

vi.mock(path: string, factory?)
vi.mock<T>(module: Promise<T>, factory?)

(main.vitest.dev)

Why the Promise (import()) overload exists (type-checking)

Using the Promise overload is mainly a TypeScript trick to make TS actually resolve the module and therefore:

  • type-check the specifier (you’ll get a TS error if it can’t be resolved), and
  • infer T from the real module type via typeof import(...).

Example:

vi.mock(import('./my-module.js'), async (importOriginal) => {
  const mod = await importOriginal() // typed as the real module
  return { ...mod, foo: vi.fn() }
})

With the plain string overload:

vi.mock('./my-module.js', () => ({ foo: vi.fn() }))

TypeScript generally cannot validate that './my-module.js' is a real module just because it’s a string argument (it’s not an import), so you lose that “specifier exists” checking benefit.

Important nuance: runtime still mocks “by string”

Even when you use vi.mock(import(...)), Vitest notes that it still operates on a string internally, not a module object. (main.vitest.dev)

Common pitfall: TS path aliases

Vitest explicitly warns that if you use TypeScript paths aliases, the compiler may not resolve types the way you expect for mocking unless you use real relative paths in the import() form (e.g. import('./path/to/module.js') instead of import('@/module')). (main.vitest.dev)

Citations:


🏁 Script executed:

# Check Prettier's actual exports
cat packages/codegen/package.json | grep prettier

Repository: inversify/graphql

Length of output: 125


🏁 Script executed:

# Look for any build or CI configuration that might show type errors
cat packages/codegen/vitest.config.mjs

Repository: inversify/graphql

Length of output: 162


🌐 Web query:

Prettier 3.8 export structure default export format function TypeScript types

💡 Result:

In Prettier 3.8.x, the prettier package is published with conditional exports (Node ESM vs CJS) and bundled TypeScript types:

  • exports["."] maps to:
    • "default": "./index.mjs" (ESM entry)
    • "require": "./index.cjs" (CommonJS entry)
    • "types": "./index.d.ts" (TypeScript declarations) (app.unpkg.com)

Does Prettier have a default export?

No. The TypeScript declarations do not define a default export; the API is exposed via named exports (and you can also import * as prettier). (app.unpkg.com)

Correct TS import + format type (Prettier 3.8)

format is a named export and returns a Promise<string>:

import { format, type Options } from "prettier";

const out = await format("const x=1", { parser: "babel" } satisfies Options);

Type signature (from index.d.ts):

  • export function format(source: string, options?: Options): Promise<string>; (app.unpkg.com)

Citations:


🏁 Script executed:

# Check if there's a node_modules or type definitions available
find . -path '*/prettier/package.json' -o -path '*/prettier/*/index.d.ts' 2>/dev/null | head -5

Repository: inversify/graphql

Length of output: 131


🏁 Script executed:

# Look at how prettier is imported/used in the actual source code
grep -r "from 'prettier'" packages/codegen/src --include="*.ts" -A2 -B2

Repository: inversify/graphql

Length of output: 1948


🏁 Script executed:

cat -n packages/codegen/src/io/actions/writeDefinitions.ts | grep -A5 -B5 "prettier"

Repository: inversify/graphql

Length of output: 953


🏁 Script executed:

# Check TypeScript config for any special module resolution
cat packages/codegen/tsconfig.json

Repository: inversify/graphql

Length of output: 344


🏁 Script executed:

# Check if there's a shared TypeScript config with synthetic defaults
cat packages/codegen/tsconfig.json | jq '.compilerOptions | {esModuleInterop, allowSyntheticDefaultImports}' 2>/dev/null || grep -E 'esModuleInterop|allowSyntheticDefaultImports' packages/codegen/tsconfig.json

Repository: inversify/graphql

Length of output: 130


🏁 Script executed:

# Check the base config that's extended
find . -path "*foundation-typescript-config*" -name "tsconfig*.json" -type f | head -2 | xargs cat 2>/dev/null

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's check how the production code compiles - see if there are any type errors in the source
cat packages/codegen/src/io/actions/writeDefinitions.ts

Repository: inversify/graphql

Length of output: 1206


🏁 Script executed:

# Check the foundation TypeScript config repository or see if esModuleInterop is set elsewhere
find . -name "foundation-typescript-config" -type d 2>/dev/null | head -1

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's see if there's a build output or error log
find . -name "tsbuildinfo" -o -name ".tsbuildinfo" 2>/dev/null | head -3

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Check if the test actually fails by looking for CI logs or checking the actual Prettier type definitions
cat packages/codegen/node_modules/.pnpm/prettier*/node_modules/prettier/index.d.ts 2>/dev/null | head -30

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's find node_modules and check Prettier's type definitions
find . -type f -name "index.d.ts" -path "*/prettier/*" 2>/dev/null | head -1 | xargs cat | head -50

Repository: inversify/graphql

Length of output: 2001


🏁 Script executed:

# Alternative: check what's in the pnpm store
find . -type d -name "prettier" -path "*/node_modules/*" 2>/dev/null | head -1 | xargs -I {} cat {}/index.d.ts | head -50

Repository: inversify/graphql

Length of output: 2001


🏁 Script executed:

# More direct approach - look for the actual Prettier module
ls -la node_modules/.pnpm/ 2>/dev/null | grep prettier

Repository: inversify/graphql

Length of output: 460


🏁 Script executed:

# Get more of the Prettier type definitions to see the format export
find . -type f -name "index.d.ts" -path "*/prettier/*" 2>/dev/null | head -1 | xargs cat | grep -A10 "export.*function format"

Repository: inversify/graphql

Length of output: 933


🏁 Script executed:

# Try a different approach - search for "format" in Prettier's types
find . -type f -path "*/prettier/*" -name "*.d.ts" 2>/dev/null | head -3 | xargs grep -l "format" | head -1 | xargs cat | tail -100

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's check if there's a default export declaration
find . -type f -path "*/prettier/*" -name "*.d.ts" 2>/dev/null | head -1 | xargs grep "export default\|export ="

Repository: inversify/graphql

Length of output: 45


🏁 Script executed:

# Check if there are any build/compile outputs showing TS errors
find . -name "*.tsbuildinfo" -o -name "dist" -o -name "lib" -type d 2>/dev/null | head -5

Repository: inversify/graphql

Length of output: 450


🏁 Script executed:

# Let's check the actual Prettier export more carefully - specifically looking for re-exports or default
find . -type f -path "*/prettier/*" -name "*.d.ts" 2>/dev/null | head -1 | xargs cat | tail -150

Repository: inversify/graphql

Length of output: 169


🏁 Script executed:

# Check if the repo has TypeScript strict mode configuration  
find . -name "tsconfig*.json" -type f -exec grep -l "strict.*true" {} \; 2>/dev/null | head -3

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's get the full extended TypeScript config to see the actual values
cat node_modules/.pnpm/@inversifyjs+foundation-typescript-config*/node_modules/@inversifyjs/foundation-typescript-config/tsconfig.base.esm.json 2>/dev/null | head -50

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Look at the actual Prettier package.json to understand its export structure
cat node_modules/.pnpm/prettier@3.8.1/node_modules/prettier/package.json | jq '.exports' 2>/dev/null || grep -A20 '"exports"' node_modules/.pnpm/prettier@3.8.1/node_modules/prettier/package.json

Repository: inversify/graphql

Length of output: 4168


🏁 Script executed:

# Check if esModuleInterop or allowSyntheticDefaultImports is set in the extended config
find . -path "*foundation-typescript-config*" -name "*.json" 2>/dev/null | xargs grep -l "esModuleInterop\|allowSyntheticDefaultImports" | head -1 | xargs cat | head -60

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Also check if the current file has any suppression comments or overrides
cat -n packages/codegen/src/io/actions/writeDefinitions.spec.ts | head -15

Repository: inversify/graphql

Length of output: 590


🏁 Script executed:

# Check if the foundation config actually sets esModuleInterop or allowSyntheticDefaultImports anywhere
find node_modules -path "*foundation-typescript-config*" -name "*.json" -type f 2>/dev/null | xargs cat 2>/dev/null | grep -E "esModuleInterop|allowSyntheticDefaultImports" | head -5

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's check Prettier's index.mjs to see if it has a default export at runtime
cat node_modules/.pnpm/prettier@3.8.1/node_modules/prettier/index.mjs 2>/dev/null | head -30

Repository: inversify/graphql

Length of output: 1561


🏁 Script executed:

# Check if the type definitions re-export a default anywhere
cat node_modules/.pnpm/prettier@3.8.1/node_modules/prettier/index.d.ts 2>/dev/null | tail -50

Repository: inversify/graphql

Length of output: 1190


🏁 Script executed:

# Let's try to understand why `import prettier from 'prettier'` works when there's no default export
# This likely indicates esModuleInterop is enabled somewhere
find . -name "*.config.*" -path "*foundation-typescript*" 2>/dev/null | head -5

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Check if there are any build outputs or error logs in the repo
find . -name "package-lock.json" -o -name "pnpm-lock.yaml" -o -name "yarn.lock" 2>/dev/null | head -1 | xargs grep -o "prettier@[^\"]*" | head -1

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's run a direct TypeScript type check on the test file to see if TS2769 appears
cd packages/codegen && npx tsc --noEmit src/io/actions/writeDefinitions.spec.ts 2>&1 | head -20

Repository: inversify/graphql

Length of output: 211


🏁 Script executed:

# Let's check if we can run the actual vitest test to see if it currently fails
cd packages/codegen && npm test -- --run src/io/actions/writeDefinitions.spec.ts 2>&1 | head -50

Repository: inversify/graphql

Length of output: 211


🏁 Script executed:

# Also let's examine if there's an ESLint or TypeScript config that shows strict settings
cat .eslintrc.json 2>/dev/null || find . -name ".eslintrc*" -o -name "eslint.config.*" 2>/dev/null | head -1 | xargs cat

Repository: inversify/graphql

Length of output: 644


🏁 Script executed:

# Check the actual root typescript config
cat tsconfig.json 2>/dev/null | head -50

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Let's check if there's a foundational config that might be setting esModuleInterop
find . -path "*/node_modules/@inversifyjs/foundation-typescript-config*" -name "*.json" 2>/dev/null | xargs cat 2>/dev/null | grep -A5 -B5 "esModuleInterop\|allowSyntheticDefaultImports" | head -30

Repository: inversify/graphql

Length of output: 43


🏁 Script executed:

# Check if there's a vitest config that might be doing type-checking
cat packages/codegen/vitest.config.mjs

Repository: inversify/graphql

Length of output: 162


🏁 Script executed:

# Let's also check how other test files handle prettier mocking if they exist
find packages/codegen -name "*.spec.ts" -type f -exec grep -l "prettier" {} \;

Repository: inversify/graphql

Length of output: 117


Use the string-specifier overload for these mocks.

The promise-based vitest.mock(import(...)) overload enforces TypeScript type-checking of the factory return against the real module shape. Prettier 3.8.1 exports only named exports (no default export), so the factory return { default: { format: vitest.fn() } } fails type validation. The string-specifier overload bypasses this check and allows the mock to load.

💡 Suggested change
-vitest.mock(import('node:fs/promises'));
-vitest.mock(import('prettier'), () => ({
+vitest.mock('node:fs/promises');
+vitest.mock('prettier', () => ({
   default: {
     format: vitest.fn(),
   },
 }));
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
vitest.mock(import('node:fs/promises'));
vitest.mock(import('prettier'), () => ({
default: {
format: vitest.fn(),
},
}));
vitest.mock('node:fs/promises');
vitest.mock('prettier', () => ({
default: {
format: vitest.fn(),
},
}));
🧰 Tools
🪛 GitHub Actions: build

[error] 4-4: TS2769: No overload matches this call.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/codegen/src/io/actions/writeDefinitions.spec.ts` around lines 3 - 8,
Replace the dynamic import overloads with the string-specifier overloads and
return a mock shaped like the real module: change
vitest.mock(import('node:fs/promises')) to vitest.mock('node:fs/promises') and
change vitest.mock(import('prettier'), () => ({ default: { format: vitest.fn() }
})) to vitest.mock('prettier', () => ({ format: vitest.fn() })), so the mocked
exports match Prettier’s named-export interface and bypass the strict factory
type-checking.

@notaphplover notaphplover merged commit d64a43e into master Mar 15, 2026
6 checks passed
@notaphplover notaphplover deleted the chore/eslint-migration branch March 15, 2026 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant