Expose a function for constructing a new System based on a custom FS implementation

Suggestion

Currently TypeScript constructs a System and sets it on the sys property on the TypeScript module. Many parts of the Compiler APIs accept a custom implementation for System, which is useful for example for testing purposes when a virtual file system is being used.

But it is not easily mockable, as the System interface is quite extensive. Internally, TypeScript constructs this by invoking an anonymous internal function, like so:

ts.sys = (function () {
 // ...
})();

🔍 Search Terms

createSystem, Mock System, Virtual Filesystem

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I would like to propose exposing a function, createSystem, that takes an Partial of the following structure:

interface CreateSystemOptions {
    // An FS implementation
    fs: typeof import("fs");

    // These are the only two properties you use from the os module
    os: Pick<typeof import("os"), "platform"|"EOL">;
    
    // You default to using process.cwd() here, but the current working directory could in theory be something else
    cwd: string;
}

export function createSystem (options: Partial<CreateSystemOptions>): System {
    // ...
}

This function should also be used internally by TypeScript, and constructs a new System. This would allow for easier mocking.

📃 Motivating Example

Imagine building a Program programmatically that relies on an incremental CompilerHost. With the createSystem function, you would very easily be able to swap out the fs implementation and pass it a virtual file system based on the test(s) you're running:

import * as ts from "typescript";
import virtualFs from "memfs";
import realFs from "fs";

function createCompilerHost (fs: typeof import("fs") = realFs): ts.CompilerHost {
    return ts.createIncrementalCompilerHost({}, ts.createSystem({fs}));
}

const program = ts.createProgram({
    host: createCompilerHost(virtualFs),
    rootNames: ["/foo/bar/baz.ts"],
    options: {}
})

💻 Use Cases

Use cases:

• Testing
• Tooling around TypeScript's Compiler APIs
• Virtual file systems, such as is the case with some bundlers running in watch mode

Workarounds:

• Manually reimplementing most of the System interface, and manually maintaining it across TypeScript versions.

Start by locating the internal anonymous function that constructs ts.sys and reviewing how createIncrementalCompilerHost consumes a System. Define the public createSystem entry point around the proposed options and ensure TypeScript uses it internally. Done means callers can provide a virtual FS without manually reimplementing most of System.