allow listing source files in a strict order

[zpdDG4gta8XKpMCd]

this is what F# does, each file has its place within the list of files, the place tells the compiler what it should look at first and defines the relationship between dependencies and dependent files

use cases:

1. having a strict hierarchy of files eliminates a chance of mutual dependencies between modules (good for overall design)

2. ease of localizing places that broke, by looking at the list you can see the ones at the top that cause problems for those in the bottom and start fixing from the top (rather than looking at the list of 500+ errors and not knowing where to start)

[zpdDG4gta8XKpMCd]

configuring

as far as configuring, the existing "files" section should be reused with a supporting flag in "compilerOptions", something like "strictFileOrder": true

the order of files in the "files" section should be treated literally (without groupping to subfolders or giving subfolders any priority), for example:

"files": [
   "a/d.ts",
   "e.ts",
   "a/b.ts",
   "c.ts"
]

should be evaluated as listed:

"a/d.ts",
"e.ts",
"a/b.ts,
"c.ts".

it's up to the user to arrange/group files in this list based on whatever reasoning

displaying in code editors

upon evaluating the order of the files in the configuration the code editor should make an attempt to display files grouped by subfolders for continuous sequences of files coming from the same subfolder:

"a.ts"
"b/c.ts"
"b/d.ts"
"e.ts"
"b/f.ts"

should be displayed as:

- a.ts
- b 
   - c.ts
   - d.ts
- e.ts
- b
   - f.ts

[zpdDG4gta8XKpMCd]

semantics

the only one adjustment needs to be made to the logic of the compiler before evaluating the code in unrestricted manner:

• check the imports of each given source file against the file list: all imports must be coming before the name of the evaluated file
• the ambient modules or dependencies coming from @types should be bypassed
• the code that doesn't use imports should be bypassed

[zpdDG4gta8XKpMCd]

order of diagnostics

diagnostics messages should come in the following order:

• errors related to ambient/@types files
• errors related to the source code ordered according to the "files" section

[zpdDG4gta8XKpMCd]

autoimports

autoimport needs to be aware of the files order and warn or prevent the users from importing from files listed after the edited file

[kitsonk]

1. having a strict hierarchy of files eliminates a chance of mutual dependencies between modules (good for overall design)

This, sadly, is by design and needs to be supported by TypeScript as it is a runtime reality. (see: #21780).

The difference between F# and TypeScript is that F# has control of the execution order of code, TypeScript does not. When dealing with modules and imports, the execution order is defined in the standard. Unclear situations of execution order make it impossible to implement some syntax ahead of the standard being confirmed (see: #25988).

So if you are dealing with modular code, the resolution and execution order are already defined. When you are dealing with the global or ambient context, I don't see how having an explicit ordering would actually help anything, especially because in a lot of cases, not the full context is listed in files. In fact I suspect most projects these days use glob pattern or a single index file the bootstraps the whole project, plus you have all the @types that will get auto resolved, etc. Because TypeScript doesn't have control of the execution at runtime, the "who caused a ambient/global conflict" is totally relative and I don't see how explicit evaluation order of files would alleviate that.

There is something to be said about co-dependent diagnostics though, and how when there are ambient/global conflicts the compiler isn't overly helpful at the moment, it just sort of 🤷‍♂️ s.

[zpdDG4gta8XKpMCd]

all i am suggesting is a special compilation mode that has nothing to do with standards or runtime:

• by defining which typescript source files depend on which in a linear fashion
• and by checking that these imports are done according to the said order at the compile time

i am well aware that most developers tsconfig.json looks like this {}, it's their choice, just like it doesn't stop other people from listing everything in "files", why not?

the proposed idea is not going to mess with the standard or solve inherent problems of javascript, all it does is: feeds files to typescript checker in a certain order, and confirms that imports don't violate this order, that's about it

[RyanCavanaugh]

Not really seeing a need for this in the largely module-based world we now live in