Initial build includes inputted files but not resolved files

[jrieken]

Initial build includes inputted files but not resolved files

[rigdern]

@jrieken Are you willing to consider a PR to change gulp-tsb's behavior to match the TypeScript compiler's? If so, can you give me some advice on how to approach the change? I'm new to the gulp-tsb codebase.

[jrieken]

This is inconsistent with how the TypeScript compiler behaves (e.g. tsc --watch App.ts).

Yes, that is the design of gulp-tsb as it won't go and hunt for more files on disk. You must provide all files of your project upfront as no further resolution happens

[rigdern]

@jrieken In the case of my team's project, the files that the initial build didn't see were d.ts files inside of the node_modules folder. If all files must be given directly to gulp-tsb as input, then I see two solutions but neither is great:

1. We could use a wildcard like ./node_modules/**/*.dts. However, this would likely include some files we don't want which could have bad effects.
2. We could manually maintain a list of the individual d.ts files from node_modues that our app consumes. However, keeping this list up-to-date is an extra maintenance cost. We'll have to update it anytime we add or remove dependencies.

Those are the solutions I've thought of but both have downsides. Do you have a recommended solution for this scenario?

Can you describe the rationale for deviating from the TypeScript compiler's behavior?

For context, I ran into this issue when attempting to migrate my team's codebase from gulp-typescript to gulp-tsb. gulp-tsb was nearly a drop-in replacement for gulp-typescript except for this and a couple of other issues I've hit. In some cases, gulp-tsb improved incremental build times from 15 seconds to less than 1 second so I'm very excited about switching to it.

[jrieken]

Can you describe the rationale for deviating from the TypeScript compiler's behavior?

Purely programmatic as we have build gulp-tsb for VS Code a long time before TypeScript was looking for files in node_modules. Also, the VS Code source tree doesn't have this requirement. So, it's definitely biased towards our use-case...