Repository: TypeScript
Issue: [ Feature Request ] - FileSystem<T> 
Labels: Suggestion,Awaiting More Feedback

## Suggestion

FileSystem<T> type

Works with alot of simplicity
- If it hits a folder adds it into the 'object' type and its children as traversable keys
- If it hits a file thats a module it adds whatever its typeof import("..") type would be.
- Recursive

Similar behavior to import(".....") type.
Usage:  FileSystem<"../static">

`FileSystem<"./api">` on this folder structure would produce the following object type which also shows how it would handle index.ts


```
- api 
     -users
         - by-id.ts
         - all.ts
         - index.ts
     -posts
        - all.ts
```
```ts
type Result = {
    users: {
        by-id: typeof import("./api/users/by-id");
        all: typeof import("./api/users/all");
    } & typeof import("./api/users"),
    posts: {
        all: typeof import("./api/posts/all");
    }
}
```





## Use Cases and Examples

**1:**  Every use case where previously people had alot of types or classes floating around and then had a single place where they imported all those types/classes into a union just to support typescript can now just use a folder to store those things in conjunction with `FileSystem`
```ts
// people using ORM's can avoid having a 'single' source where all their classes are imported in favor of just using a folder.
await database.user(123);

// folder strcuture
// tables
       user.ts     {default: class UsersTable {  getUsers() { return [] }}}  // contains following module

type ORM = {
    [K in keyof FileSystem<"../tables">]: FileSystem<"../tables">][K]["default"]
}

declare const database: ORM ;
database.users.getUsers();
```


**2:** Really strong support for image paths, and removing files in refactors that are referenced by string path.
```ts
 // (note: requires augmentation of JSX types);
<img src={"/static/dolphin.png"}/> // error dolphin.png isn't loaded in the file system.
```

**3:**  Support for string based routing in applications and protection against routing refactors at a type-level.
```ts
 // (note: requires augmentation of JSX types);
<a href={"/home/name"}/>

// currently people do something like this just to have 'route refactorability' which bloats bundle size.
const Routes = {
     Home: {
         name: "/home/name"
     }
} as const

// can now do this..
- screens
      - home
              - name.ts // React page
```

**4:**  Statically typed readFileSync for people using it to access their file system
```ts
const readFileSystem = (path: keyof FileSystem<".">): string=> fs.readFileSync(path);
```


**5:**  Statically typed API handling
```ts
(pseudo code)
// before
const response = await api<typeof import("/api/user")>("/api/user")
// after
const response = await api.user(1);
// implementation
const api = new Proxy<FileSystem<"../../../api">>(...);
```

+ Many more use cases (File system based redux, file system based statically typed ExpressJS etc)

**Precedence:** When people look at the implementation in the standard library they will notice FileSystem doesn't have a implementation in the same way you can "peek definition" for types like `Exclude` and `Omit`, however there already is precedence for type-level helpers that work as a 'compiler flag' (I.E `ThisType<T>`);

Also utilizes a lot of things that already exist like typeof import("..") functionality.


Previous issue:
https://github.com/microsoft/TypeScript/issues/41550


Further important notes:

- People are going to want to type things with the 'flattened' keys of a FileSytem<T> in various formats which will easily be possible to use it in conjunction with existing mapped types and new string literal types.
- People are going to want to use FileSystem to represent things that are FileSystem'Like which again is easily possible with mapped/string literal
- People are going to want to use FileSystem to represent transformations that could happen at build time which is again possible with mapped/string literal types.



## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).