Let's move on.
We got the outfall option here.
Now this option does not matter to us right now.
It won't work right now.
More interesting to us is outdoor and rooster the bigger your project gets the more you might want to
organize your files.
Typically you don't just want to have your files lie around here in your root level project folder.
Instead what you often will see in projects is that you have a source folder and you have a dust folder
next to next.
So the disk folder has the job of holding all the output so all the JavaScript files let's say and the
source folder might hold all our types good files so we can move to types good falls into the source
folder.
And if I Now delete the javascript folder we have the problem that if we compile everything these types
of files are compiled because typescript the compiler does look into some folders but the output sits
next to our input files and that's something we can control with the outer.
For example if we set outer we can tell the typescript compiler where the created files should be stored.
We could set this to dist.
Now if we do that Dan if you run TSC you will see that the JavaScript files indeed are not placed in
the source folder but into this folder.
Now we just have to adjust our index age to Mal file and their point at this app J.S. and disk analytics
chance or alternatively move the index age to Mal file into the disk folder but then our def server
wouldn't work correctly anymore right now.
So let's just adjust these imports.
And with that we got a working application still as you see but now with a cleaner product structure.
Now the good thing is if we had a sub folder here and analytics folder let's say and we had our types
could file in there then if we recompile and it does not matter if you do it with this command or in
the watch mode this folder structure you have in the source folder will also be replicated in the distiller
which is of course very convenient because that makes sure that you can import the files basically as
you would import them into source folder as well so that the structure you set up there is kept.
Now you can also set the root directory and set this specifically at the folder where your files are
stored in like in this example source to make sure that the types of compiler does not look in other
folders.
That's also something you could do with the include option down there.
Right.
But with root directory the type some compiler will not just look only at that source folder it also
makes sure that project structure you set up there is kept in this folder.
Now it did so by default before as you saw.
But keep in mind that before it would have included any types of files you're is outside of source.
So for example if you come at this out temporarily if we had a user folder here on the top level with
a user test file where we have a user name of Max let's say then if we compile this you will also see
that user folder in the dist folder and now the source folder is included as well because now we have
a typescript file on a higher level and therefore the types of compiler things that our whole project
again is the input and it replicates the folder structure it finds there in the disk folder.
Now that's of course not what we would want and that's where the route year option helps us.
Now if we set this to source even if we had our folders with types of files in there on the route level
they would not be included in the output and the source folder itself would not suddenly end up there.
So off you set both routes dir and outer to be really clear regarding where your input files live and
where you are output files would be generated in if we move on we can ignore composite we can have a
look at remove comments should be pretty clear if you set this then any comments you might have in your
types good files will be removed in the compiled JavaScript files so if I comment this in and I compiled
my code you'll see an apt Yes I have a comment in app J.S. it's not there so you can do that to make
your files smaller and therefore this might be a nice option You can also set no limits.
If you don't want to generate any JavaScript files.
Now this might sound strange because that's the idea of typescript but if you just want to check whether
your files are correct but you don't want to write all these output files to save some time for example
in a bigger project then you could set this to true to just have the types of compiler check your files
and report any potential errors without actually creating an output file.
Import helpers is not really important to us here.
We can ignore that down level iteration is an advanced option.
It is interesting when you compile your code to older versions of JavaScript and you work with for loops
then in some rare scenarios you could run into issues where the compilation doesn't work correctly.
This option if you turn it on gives you a more exact compilation which will work in these niche cases.
So therefore you might think you should always turn it on but it will also output more where both code.
So you should only turn this on if you have loops and you see that your generated code suddenly behaves
differently than it should.
Regarding those loops.