Add `outDir` option to generate output in a folder

[samualtnorman]

hi me again,

I'd like the ability to specify an --out-dir option on the command line that'll be used when specifying multiple entry points currently when specifying multiple entry points you, get all the generated declaration files next to the source files, or need to create a config file and specify yourself the out file paths or write the code yourself to generate the out file paths in the config file

it would be nice if this was part of the tool

I had a go at implementing this 7b9ee2dc76bda54e6e3d5e4f7b8b620f17bde2f1 but I'm sure I've not implemented it in the correct place

plus there's some bike shedding that needs to happen on the behaviour of the option in my implementation I decided that the root of the project to be relative from was the directory of the tsconfig.json if one was specified, otherwise it's your current directory

I will once again have a go at implementing this myself once behaviour has been decided

thank you for reading this :D

[timocov]

Looks reasonable for me, but I have a few questions:

• as you correctly mentioned, what the structure of the output folder should be? should it reflect the one from the project structure? or just file names? or from the most common folder? something else? The more tricky and "unpredictable" the behaviour is, the more controversial this option would be IMO
• if it shouldn't reflect the project structure from the root (what is the root btw? rootDir? what if it is not specified? what if tsconfig is placed outside of the source files? not sure if the compiler provides API for that - ), then how to handle names collusion?

As for the implementation you have, I'd improve the error messages and add handling invalid set of options (you cannot use out-dir and our-file at the same time, and also you shouldn't be able to provide one option if another is expected and vice versa).

[ext]

I just ran into this myself and what I expected was to run dts-bundle-generator on two source files and get two files in the folder of my choice.

Essentially just compiling once and get output as following:

• src/entry-a.ts -> dist/entry-a.d.ts
• src/entry-b.ts -> dist/entry-b.d.ts

Currently I run dts-bundle-generator twice (one for each file) but compilation takes quite a while. I tried to run on both entrypoints at once but I couldn't figure out a way to put the resulting .d.ts files in another folder (I only get them to end up in the src folder). Running once instead of twice cuts the time in half.

[timocov]

@ext yeah the performance is a valid point and for that reasons a config file was introduced a long time ago - you can control everything you need there. The only question here is to provide an option to be able to use the tool without a config file at all, by providing CLI args.

I'd probably add 2 CLI args to solve this ticket:

• --outDir (should be provided only if multiple entries are provided) to specify the root folder where the output should be placed, and by default use the logic to place files by stripping the most common path of entries. E.g. we have 2 entries /path/project/src/index.ts and /path/project/src/folder/index.ts. so by proving outDir=./dist/ the tool will generate 2 files ./dist/index.d.ts and ./dist/folder/index.d.ts, because the most common path between entries is /path/project/src/
• --rootDir (should be provided only along with outDir) - allows to override "the most common path" for all entries. But this one won't allow you to provide a path for each entry point separately.

Alternatively, we could consider to introduce "a special format" for entry points (like path/to/entry.ts:path/to/output.d.ts), which will solve the issue and it will be able to provide your own names without a config file (or programmatic API).

@ext @samualtnorman what do you think?

[ext]

Sounds good to me.