Repository navigation
An option to enforce emitting order #12881
Description
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.
Activity
RyanCavanaugh commentedon Dec 13, 2016
The only thing you need to do to get this behavior is not have
/// <referencedirectives 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 usingimport(as in modules), there's no "order" per se.mhegazy commentedon Dec 13, 2016
Please note that we have a bug where the order of files listed in
includeis not honored at the moment. see #11461. this should be fixed in upcoming releases.rtpg commentedon Dec 14, 2016
This might be a case of the
includeissue, 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, andc.ts. I wanted the output to be in the sam order.b.tsused types froma.d.tswhich had a type fromc.ts, soc.tscame out first, despite the fact that the include order was something likeinclude: ['a.d.ts', 'b.ts', 'c.ts']. I have noreferencepaths in my code.Once I moved
c.ts's interface definitions fromc.tstoa.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 #11461mhegazy commentedon Dec 14, 2016
use
tsc --listFilesto see what order the compiler sees the input. you can see--traceResolutionto know what files "imported" your file.rtpg commentedon Dec 14, 2016
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
includeorder is fixed, that will probably solve the reasoning behind this issue as well.