docs: 📖 add hooks documentation

[swashata]

Add documentation on how to use hooks on a compiler instance.

See #273

[piotr-oles]

Well done :)

[phryneas]

For me, who never has used one of these hooks before, the way you use yourPluginName is not 100% clear. Do I need to write an own plugin to use this? From the code it seems as if it can be used just from the file that instantiates webpack.

Could you add some more information on that part please?

[swashata]

Thanks for the review. Could you please give me some suggestions?

1. yourPluginName, I just borrowed from webpack docs. Perhaps writing someDescriptor makes more sense?
2. Perhaps I am missing something here, but I thought the only way to access the hooks is to call getCompilerHooks with the compiler passed in as argument. If this is not the case, could you please give me an example?

[johnnyreilly]

In case it helps, here's an example of hooking in:

https://github.com/johnnyreilly/fork-ts-checker-notifier-webpack-plugin/blob/cafba0be10b8151ebf4b45d189129b85357359bf/index.ts#L109

[phryneas]

Thanks for the review. Could you please give me some suggestions?

1. `yourPluginName`, I just borrowed from webpack docs. Perhaps writing `someDescriptor` makes more sense?

From looking at the code, they call it 'name' internally. I guess something like yourListenerName or yourSubscriptionName could be appropriate. Having "plugin" in there and adding an example where it is invoked outside of a plugin is a bit confusing I think.

2. Perhaps I am missing something here, but I thought the only way to access the hooks is to call `getCompilerHooks` with the compiler passed in as argument. If this is not the case, could you please give me an example?

No, I believe your example is 100% correct. I just wanted to display the confusion that the naming yourPluginName could invoke in the person reading the documentation. Obviously, it confused everyone 😆

[swashata]

Got your point 😅. I will make the changes tomorrow and update this PR

[swashata]

Ready for another round of review @phryneas, @johnnyreilly, @piotr-oles 😄

[phryneas]

looks good to me

[johnnyreilly]

Cool! Feel free to merge!

[johnnyreilly]

Awesome! Do we need to do a beta -> master PR now so these changes show up, when people are reading the docs?

[phryneas]

@johnnyreilly yup, see #275.

[piotr-oles]

🎉 This PR is included in version 1.3.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[piotr-oles]

🎉 This PR is included in version 1.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[allen-munsch]

@swashata

Do you happen to know off hand why something like this might not work:

let config = {...}
let compiler = webpack(config);
new ForkTsCheckerWebpackPlugin().apply(compiler);
const pluginHooks = ForkTsCheckerWebpackPlugin.getCompilerHooks(compiler);
pluginHooks.receive.tap('some-receive', (d, l) => {
    console.log(d);
    console.log(l);
});

pluginHooks.emit.tap('some-emit', (d, l) => {
    console.log(d);
    console.log(l);
});
module.exports = config;

Or know off hand how I can bubble up any tslint errors from the forked process?

Right now I'm looking at using this in the plugins sections of the webpack config:

    {
      apply: (compiler) => {
        compiler.hooks.done.tap('pm-on-emit', (stats) => {
          if (stats.compilation.errors.length) {
            stats.compilation.errors.forEach(err => console.error(err.message));
            process.exit(1)
          }
        });
      }
    }

[swashata]

@allen-munsch yes. You need to get plugin hooks from individual compiler instances, not the whole compiler. Do check the readme and multicompiler section

https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/master/README.md#accessing-hooks-on-webpack-multi-compiler-instance