prevent UnhandledPromiseRejectionWarning in node 6

[skratchdot]

Fixes #7654

This fixes the node 6 warning I was seeing (see issue #7654). I'm not sure if there's a way to clean up the readable stream in node 6.

What kind of change does this PR introduce?
Prevents calling a method that doesn't exist in node 6

Did you add tests for your changes?
No. I tested manually by running this code against my codebase in node 6 (before and after making the change)

Does this PR introduce a breaking change?
I hope not.

What needs to be documented once your changes are merged?
I don't think anything really needs to be documented. This just prevents a warning from showing up in node 6.

[jsf-clabot]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

[webpack-bot]

For maintainers only:

• This need to be documented (issue in webpack/webpack.js.org will be filed when merged)

[skratchdot]

Ugghh. Since the code change was so minimal, I just copy-n-pasted from my local node_modules into the github web editor. I knew I should've taken the extra time to clone the repo and run tests!

Anyways, I just fixed the style errors via npm run code-lint -- --fix and re-pushed. Should be good now.

[skratchdot]

When running tests locally, I see 2 failed tests:

● ConfigTestCases › plugins › profiling-plugin › profiling-plugin should compile
Timeout - Async callback was not invoked within the 10000ms timeout specified by jest.setTimeout.

● ConfigTestCases › source-map › source-map-with-profiling-plugin › source-map-with-profiling-plugin should compile
Timeout - Async callback was not invoked within the 10000ms timeout specified by jest.setTimeout.

But those also happen in master (so they don't appear to be related to this code change).

Just something to call out. Perhaps we can handle that in a separate PR/Issue.

[webpack-bot]

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

[sokra]

I wonder if destory is the correct way to end the stream. Isn't trace.push(null) the better way?

[sokra]

I tried this and it seem to work (also on node.js 6).

[skratchdot]

I'm not sure if destroy is the correct way to end the stream. It works for 8, but not for 6.

[sokra]

But those also happen in master (so they don't appear to be related to this code change).

Just something to call out. Perhaps we can handle that in a separate PR/Issue.

They don't happen for me on master...

[skratchdot]

@sokra - i am running the following:

git log -n 1
node -v
echo $CI
yarn test -- test/ConfigTestCases.test.js

and i see:

● ConfigTestCases › plugins › profiling-plugin › profiling-plugin should compile
Timeout - Async callback was not invoked within the 10000ms timeout specified by jest.setTimeout.

● ConfigTestCases › source-map › source-map-with-profiling-plugin › source-map-with-profiling-plugin should compile
Timeout - Async callback was not invoked within the 10000ms timeout specified by jest.setTimeout.

The test seems to depend on:
https://github.com/webpack/webpack/blob/master/test/configCases/plugins/profiling-plugin/test.filter.js#L2

So I think it works on the CI but not locally for me? It's also a timeout, so maybe my machine is slower than yours (although I'm running on a 2017 macbook w/ maxed out RAM :) )

[skratchdot]

To prove trace.destroy doesn't work on node 6, run the following (it's similar to the code that I saw the error for):

node -v
node -e "
const { Tracer } = require('chrome-trace-event');
const trace = new Tracer({ noStream: true });
trace.destroy();
"

node 6:

node 10: