feat: add depending .d.ts files as changed when watch is triggered

[KnisterPeter]

If a project depends on custom definition files, meaning not the ones in node_modules, then it should consider them changed when webpack triggers a watch-run.
Since webpack doesn't know about definition files, we use the one detected by the languageService which should be more accurate anyway.

Closes#697

[johnnyreilly]

Thanks @KnisterPeter - I'm pretty snowed right now but I will get back to you with a review once things ease off.

[KnisterPeter]

@johnnyreilly any update on this?

[johnnyreilly]

Hi @KnisterPeter,

Thanks for the PR - it hasn't been forgotten. I'm taking some time out over Christmas and I'm planning to take a look at it once #685 has been merged. Typically we have a much faster turnaround on PRs but on this occasion there is going to be a lag as 685 is so significant. Essentially I'm trying to avoid merge hell 😉

Please bear with me - I will get to this PR as soon as I can. Thanks again for contributing - I really appreciate it.

[KnisterPeter]

I've just resolved the conflicts. Before merging I'll test if the new watcher code is enough without my PR.

[KnisterPeter]

After testing with the current master, I have to say that my PR is still needed to rebuild when only declaration files change.
So it would be cool if you could review and merge my changes.

[johnnyreilly]

Cheers @KnisterPeter

[johnnyreilly]

You tested with experimentalWatchApi: true?

[KnisterPeter]

A sorry, I missed that. I'll test again 😄

[KnisterPeter]

@johnnyreilly Nope, even with that its still missing files (or at least not reporting errors).
To be more precise, webpack does not report errors if a definition file change but it rebuilds all dependencies.
This may be the errors in the current new watch impl.

[johnnyreilly]

👍

[johnnyreilly]

Hey @KnisterPeter,

It looks like the declarationWatch test is broken by this (which may make sense given the nature of the change). Can you advise on how you would expect this test case to behave post your change?

Test in question here: https://github.com/TypeStrong/ts-loader/tree/master/test/comparison-tests/declarationWatch

Explanation of our comparison test pack here: https://github.com/TypeStrong/ts-loader/blob/master/test/comparison-tests/README.md

Happy to help if there's confusion.

[KnisterPeter]

@johnnyreilly I could try to fix the test the next days.
From what I expect by my change is that if there are declarations part of the current program (as dependency) and there are changes in them, a build should be triggered.

This is for example helpful if you have a project with yarn workspaces, lerna or other cases (like in the example repo created by me).
If interfaces are changed this will only result in changed declaration files which should rebuild depending projects.

[johnnyreilly]

Ok - hopefully you should be able to just regenerate the output of the test. Assuming it looks sane then we're good from a functional perspective.

Question: do you know what sort of impact this change has on performance?

[KnisterPeter]

@johnnyreilly Thats a bit strange. When running locally with yarn comparison-tests all tests run successfully. Any idea what could go wrong on travis?

Oh, i see, its just the TSC 2.7-rc builds. But event stranger I did run them with 2.7-rc locally as well.

[KnisterPeter]

Regarding the performance it should have no or low impact. This change just add watchers for the included definition files.

[KnisterPeter]

@johnnyreilly Any idea?

[johnnyreilly]

Sorry about the delay in responding @KnisterPeter - I've been very occupied with webpack 4 work.

Could you delete the 2.7 expected output for the failing test and then regenerate it using --save-output please? I have a feeling it may be a "stale files" issue you're facing.

[KnisterPeter]

@johnnyreilly Done. Thumbs pressed 😃

[KnisterPeter]

@johnnyreilly All done. Thanks for your help.

[johnnyreilly]

No bother. Question: how keen are you for this to use this with webpack 3? I'm planning to release ts-loader 4 with webpack 4 support. It'd make my life easier if I included this with that. However if you're unlikely to be able to move to webpack 4 soon after release then let me know. It's probably still doable to ship another ts-loader on the v3 codebase

[KnisterPeter]

I would be very glad if it will be merged for webpack 3. I'm not sure how fast we could move on to webpack 4.

[johnnyreilly]

OK - I'll see what I can do.

[johnnyreilly]

Released as https://github.com/TypeStrong/ts-loader/releases/tag/v3.4.0 - thanks for your help!

[KnisterPeter]

Wow. Thank you 👍