This pull request teaches the@typescript-eslint/typescript-estree project-service integration to recognize virtual processor child paths (for exampledocs/example.md/0.ts orfile.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 understoodreal filesystem paths, whereas ESLint processors only exposevirtual child paths (e.g.file.mdc/0_0.ts) that do not exist on disk and cannot be added totsconfig.json.

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

Inthe 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 intypescript-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 aphysicalFilename 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 helperisVirtualFilePath(filePathAbsolute: string): boolean that:
    • Immediately returnsfalse if the exactfilePathAbsolute exists on disk.
    • Otherwise walks up the path towards the filesystem root and checks ancestors withfs.statSync.
    • Treats the path asvirtual 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 tofalse on any unexpected error, preserving robustness.
  • Adjusted the project-service decision logic inuseProgramFromProjectService:
    • Previously:
      • isDefaultProjectAllowed was derived solely fromallowDefaultProject globs.
      • Virtual child paths likefile.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:

        constisVirtualFile=isVirtualFilePath(filePathAbsolute);constisDefaultProjectAllowed=isVirtualFile||filePathMatchedBy(filePathRelative,serviceAndSettings.allowDefaultProject);

      • This means:
        • Real files behave exactly as before and still rely onallowDefaultProject.
        • 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) andsingleRun 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();constprogram={getSourceFile:vi.fn()};constvirtualFilePath=`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({});constfilePathAbsolute=path.normalize(`${currentDirectory}/${virtualFilePath}`);constparentMarkdownPath=path.normalize(`${currentDirectory}/path/docs/example.md`,);constexistsSpy=vi.spyOn(fs,'existsSync');conststatSpy=vi.spyOn(fs,'statSync');existsSpy.mockImplementation(p=>{constnormalized=path.normalize(String(p));if(normalized===filePathAbsolute){// The virtual child itself does not exist on disk.returnfalse;}returnfalse;});statSpy.mockImplementation(p=>{constnormalized=path.normalize(String(p));if(normalized===parentMarkdownPath){// Pretend the parent Markdown file exists on disk.return{isFile:()=>true,}asunknownasfs.Stats;}// Simulate a missing path for all other ancestors.consterror=newError('ENOENT');//@ts-expect-error - augmenting error for realism; not important to the testerror.code='ENOENT';throwerror;});constactual=useProgramFromProjectService(createProjectServiceSettings({// No allowDefaultProject globs: virtual children should still be allowed.allowDefaultProject:[],      service,}),{      ...mockParseSettings,filePath:virtualFilePath,},true,newSet(),);expect(actual).toBe(program);existsSpy.mockRestore();statSpy.mockRestore();});

  • This test explicitly verifies the new behavior:

    • WithnoallowDefaultProject globs configured.
    • For a virtual child pathpath/docs/example.md/0.ts whose parentpath/docs/example.md is treated as a real file.
    • The call touseProgramFromProjectService returns theprogram from the project service instead of throwing a “not found by the project service” error.

  • Existing tests around:

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

Testing & Verification

• Unit Tests added/passed
  • New test intests/lib/useProgramFromProjectService.test.ts for virtual child paths under an existing file.
  • ExistinguseProgramFromProjectService 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 withparserOptions.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 thevirtual 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 arenested under an existing file are treated as virtual children and implicitly allowed to use the default project.
• Real files on disk and existingallowDefaultProject behavior are unchanged.
• Processors and configs that do not rely on virtual child paths (or do not useprojectService) continue to behave as before.