This pull request teaches the @typescript-eslint/typescript-estree project-service integration to recognize virtual processor child paths (for example docs/example.md/0.ts or file.mdc/0_0.ts) and automatically treat them as eligible for the TypeScript default project, enabling typed linting for code blocks extracted by processors such as @eslint/markdown.

Motivation

Typed linting for code extracted by processors (Markdown/MDX/.mdc fenced TS blocks) previously failed with errors like:

<path>/file.mdc/0_0.ts was not found by the project service. Consider either including it in the tsconfig.json or including it in allowDefaultProject.

because the TypeScript project service only understood real filesystem paths, whereas ESLint processors only expose virtual child paths (e.g. file.mdc/0_0.ts) that do not exist on disk and cannot be added to tsconfig.json.

My original attempt to solve this in ESLint core and @eslint/markdown was to introduce a physicalFilename concept and to materialize temporary .ts files on disk (see eslint/eslint#20378, eslint/eslint#20375, and eslint/markdown#595). As discussed in the RFC, that pushed responsibility for creating and cleaning up temp files into every processor.

In the review discussion, @DMartens pointed out that:

I also do not think it should be the responsibility of the processor to create and delete files as that would require each processor to do it and it is error-prone (e.g. no cleanup when there is an error).
The main motivation for this change is that TypeScript types work which should be possible with the TypeScript Compiler API.

and suggested instead that the TypeScript integration itself (i.e. @typescript-eslint/parser / typescript-estree via the Compiler API / project service) should be made aware of virtual child paths.

This PR implements that suggestion in typescript-estree: virtual child paths nested under a real file on disk are detected and automatically allowed to use the default project, without requiring processors to materialize temp files or ESLint core to grow a physicalFilename API.

Type of Change

• [] 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• 🔧 Refactoring (no functional changes, no api changes)

Detailed Changes

• packages/typescript-estree/src/useProgramFromProjectService.ts:

  • Introduced a new helper isVirtualFilePath(filePathAbsolute: string): boolean that:
    • Immediately returns false if the exact filePathAbsolute exists on disk.
    • Otherwise walks up the path towards the filesystem root and checks ancestors with fs.statSync.
    • Treats the path as virtual if it finds a parent that is an actual file, which matches processor-style layouts such as:
      • <project>/docs/example.md/0.ts
      • <project>/rules/EXAMPLE.mdc/0_0.ts
    • Falls back to false on any unexpected error, preserving robustness.
  • Adjusted the project-service decision logic in useProgramFromProjectService:
    • Previously:
      • isDefaultProjectAllowed was derived solely from allowDefaultProject globs.
      • Virtual child paths like file.mdc/0_0.ts were not recognized and thus caused “not found by the project service” errors unless manually allow-listed.
    • Now:
      • isDefaultProjectAllowed is computed as:

        const isVirtualFile = isVirtualFilePath(filePathAbsolute);
        
        const isDefaultProjectAllowed =
          isVirtualFile ||
          filePathMatchedBy(filePathRelative, serviceAndSettings.allowDefaultProject);

      • This means:
        • Real files behave exactly as before and still rely on allowDefaultProject.
        • Virtual children under a real file are implicitly allowed to use the default project without additional configuration.
  • Left all existing semantics for:
    • Non-standard extensions (DEFAULT_EXTRA_FILE_EXTENSIONS / extraFileExtensions checks).
    • Default-project file count enforcement and error messages.
    • Reload behavior (reloadProjects) and singleRun handling.
  • The overall behavior change is narrowly scoped to virtual child paths that are:
    • Not present on disk, but
    • Have a real-file ancestor in the path.

• packages/typescript-estree/tests/lib/useProgramFromProgramService.test.ts:

  • Added a focused unit test:

    it('treats virtual child paths under an existing file as allowed by the default project', () => {
      const { service } = createMockProjectService();
      const program = { getSourceFile: vi.fn() };
    
      const virtualFilePath = `path/docs/example.md/0.ts`;
    
      mockGetProgram.mockReturnValueOnce(program);
      mockCreateProjectProgram.mockReturnValueOnce(program);
    
      // Simulate that the project service does not associate the virtual path with a specific tsconfig.
      service.openClientFile.mockReturnValueOnce({});
    
      const filePathAbsolute = path.normalize(`${currentDirectory}/${virtualFilePath}`);
      const parentMarkdownPath = path.normalize(
        `${currentDirectory}/path/docs/example.md`,
      );
    
      const existsSpy = vi.spyOn(fs, 'existsSync');
      const statSpy = vi.spyOn(fs, 'statSync');
    
      existsSpy.mockImplementation(p => {
        const normalized = path.normalize(String(p));
        if (normalized === filePathAbsolute) {
          // The virtual child itself does not exist on disk.
          return false;
        }
        return false;
      });
    
      statSpy.mockImplementation(p => {
        const normalized = path.normalize(String(p));
    
        if (normalized === parentMarkdownPath) {
          // Pretend the parent Markdown file exists on disk.
          return {
            isFile: () => true,
          } as unknown as fs.Stats;
        }
    
        // Simulate a missing path for all other ancestors.
        const error = new Error('ENOENT');
        // @ts-expect-error - augmenting error for realism; not important to the test
        error.code = 'ENOENT';
        throw error;
      });
    
      const actual = useProgramFromProjectService(
        createProjectServiceSettings({
          // No allowDefaultProject globs: virtual children should still be allowed.
          allowDefaultProject: [],
          service,
        }),
        {
          ...mockParseSettings,
          filePath: virtualFilePath,
        },
        true,
        new Set(),
      );
    
      expect(actual).toBe(program);
    
      existsSpy.mockRestore();
      statSpy.mockRestore();
    });

  • This test explicitly verifies the new behavior:

    • With no allowDefaultProject globs configured.
    • For a virtual child path path/docs/example.md/0.ts whose parent path/docs/example.md is treated as a real file.
    • The call to useProgramFromProjectService returns the program from the project service instead of throwing a “not found by the project service” error.

  • Existing tests around:

    • allowDefaultProject glob handling.
    • Non-standard extensions and extraFileExtensions.
    • Default-project matching limits.
    • setHostConfiguration behavior.
      remain unchanged and continue to validate the original behaviors.

Testing & Verification

• Unit Tests added/passed
  • New test in tests/lib/useProgramFromProjectService.test.ts for virtual child paths under an existing file.
  • Existing useProgramFromProjectService test suite continues to pass.
• Manual verification steps:
  • Integrate a processor such as @eslint/markdown that produces virtual child paths (file.md/0.ts, file.mdc/0_0.ts).
  • Configure @typescript-eslint/parser with parserOptions.projectService: true.
  • Run ESLint on a Markdown / MDX / .mdc file containing TypeScript code blocks.
  • Observe that:
    • Type-aware rules now run successfully on code blocks.
    • The project service no longer reports “was not found by the project service” for virtual child paths.
    • Diagnostics continue to report the virtual child filename (e.g. file.mdc/0_0.ts), preserving existing UX.

Breaking Changes (if any)

N/A

This change is designed to be backwards compatible:

• Only non-existent paths that are nested under an existing file are treated as virtual children and implicitly allowed to use the default project.
• Real files on disk and existing allowDefaultProject behavior are unchanged.
• Processors and configs that do not rely on virtual child paths (or do not use projectService) continue to behave as before.