An option to enforce emitting order

[rtpg]

I know I can control the order of files via the ordering provided in my config (either in files or include). But since things like types can change ordering so that even if we have files:['a.ts', 'b.ts'], then the resulting output will have b.ts's compiled output first (see here)

Would it be possible to add a compiler flag so that we can enforce that a.ts doesn't pull in b.ts? To enforce the ordering provided in files or include? I tried looking into doing this myself but this project's quite big. Something like a compiler error when trying to pull in a file that is "after" the current file in the include order.

Ideally, being able to make it so that if I have:
include: [ "library/*", "core/*", "ui/*" ]

then files within library/* could depend on each other but not on things in core/* , and core/* could not depend on anything in ui/* (but could depend on things in core/* or lib/*). This would already help to solve many of my ordering-related headaches which mean I cannot use things like the import statement safely.

[RyanCavanaugh]

The only thing you need to do to get this behavior is not have /// <reference directives in your files. If you have a tsconfig listing your files, there's no reason to have those directives, so that should be a straightforward policy you could enforce with TSLint (or a simple commandline script).

I'm also a little confused on import - if you're using import (as in modules), there's no "order" per se.

[mhegazy]

Please note that we have a bug where the order of files listed in include is not honored at the moment. see #11461. this should be fixed in upcoming releases.

[rtpg]

This might be a case of the include issue, though my issue went away once I moved around some type definitions, so I feel like "something" is happening.

In my case I had a.d.ts, b.ts , and c.ts. I wanted the output to be in the sam order.

b.ts used types from a.d.ts which had a type from c.ts, so c.ts came out first, despite the fact that the include order was something like include: ['a.d.ts', 'b.ts', 'c.ts']. I have no reference paths in my code.

Once I moved c.ts's interface definitions from c.ts to a.d.ts, the code started coming out in the right order.

Unfortunately I am unable to get this to happen for me in a minimal example, making me think something else is also going on. But the reality is that the output order was not the same as the import order in include. This could be a duplicate of #11461

[mhegazy]

use tsc --listFiles to see what order the compiler sees the input. you can see --traceResolution to know what files "imported" your file.

[rtpg]

I do see the behaviour of #11461 with that command. I don't seem to be able to replicate my "fix" for the output, though. Might have been a hallucination on my part.

If the include order is fixed, that will probably solve the reasoning behind this issue as well.