Support a 'declarationPath' option

[SetTrend]

When declaration files are supposed to be stored in a separate output folder, deeper in the hierarchy, references in external .d.ts files break because TSC currently doesn't support this.


I propose to provide an option for having declaration files stored in a separate folder, so TSC may amend the corresponding reference paths in the generated code files.

In particular, I'm proposing to replace the boolean declaration option with a declarationPath string option.


The path to be set here is suggested to be the relative path between the generated .js file and its corresponding .d.ts file. This would match the behaviour of gulp-sourcemaps:

TSC  --declarationPath "./headers/"    --target "ES5" --module "commonjs" --removeComments -noEmitOnError
     ------------------------------
     // relative to .js output folder

- `declarationPath: null` (default value) would not generate `.d.ts` files. - `declarationPath: "."` and `declarationPath: ""` would generate declaration files in the same folder as the generated `.js` files (standard case). - Any other value amends all references to `.d.ts` files pointing to (relative) locations within the project.

See SetTrend/TS18N demo failing project for reference ...

/cc #6465


Your thoughts?

[DanielRosenwasser]

After discussing with @mhegazy, we think that it would be more appropriate to copy your .d.ts files as part of a build tool. Part of this is that we don't know when a .d.ts file is supposed to be some ambient declarations that you use for part of your compilation, or something that you need to also expose.

Additionally, given that external definition files currently should not be bundled with packages, this might facilitate certain anti-patterns that we do not want to encourage.

[DanielRosenwasser]

Actually, reopening since there is a valid second scenario, in which a user wants to separate their output js from their declaration files.

[RyanCavanaugh]

Tracking at #6723 now