use empower-core for better assertion tracking and performance

[jamestalmage]

This switches us to the (much) lighter weight empower-core.

empower-core does not render the pretty assertion graphs in the forked processes. So we need to use empower-formatters in the main process to finalize the enhancement. The browserified build of empower-core is 90% smaller than empower. However, we won't see much of that benefit until we move Babel transpiling to the main process as well (since the power-assert transform has a largely overlapping dependency graph with empower).

The immediate benefit is that this provides a very easy way to track assertions and methods which will be beneficial to TAP support.

It currently relies on the initial changes made in twada/empower-core#2, but it will be trivial to update once that is merged and deployed. Currently it points to a dependency in the @jamestalmage namespace so as not to reintroduce a git dependency which seems to give some people problems.

[jamestalmage]

crap, meant to move that to the top of the file.

[vadimdemedes]

I like this idea 👍!

[vadimdemedes]

Oh wow, something incredible happened, AppVeyor passed, but Travis failed.

[jamestalmage]

Oh wow, something incredible happened, AppVeyor passed, but Travis failed.

My whole world view is shaken.

[jamestalmage]

Looks like it's because I used scoped packages, and our travis script doesn't upgrade us to NPM 3. Not sure what we should do here. Should we bump travis to use NPM 3? Then all our CI is using NPM 3, is that a problem?

[jamestalmage]

@vdemedes - I just updated this to use the empower-core API @twada and I agreed on. It is still going to fail on travis because I am using a scoped package. I think you are pretty safe to start exploring how to use this for your TAP integration though.

[jamestalmage]

@vdemedes FYI: Some documentation on the recent changes to empower-core.

@sindresorhus @vdemedes - How should I proceed w/ regard to npm 1 not supporting scoped builds?

1. Do we just want to add npm i -g npm@3 as the before_script? This would mask any errors that only surface with the NPM 2 directory structure.
2. Do we want to only upgrade to npm@2-latest on Node 0.10 and stick with the default elsewhere?
3. Just skip it and wait for @twada to ship those changes so we can bump versions? I'm sure @twada will get it done fast, but it would be nice to have a solution in place that allowed us to deploy hotfixes to npm in the future.

[twada]

@jamestalmage @vdemedes @sindresorhus I just released empower-core 0.2.0.

[sindresorhus]

👍 LGTM when the dependency is updated to ⬆️ and tests are passing.

@twada Does the changes look good to you?

[twada]

@sindresorhus Looks good to me when bumped to empower-core 0.2.0

[jamestalmage]

Dependency bumped 👍

[jamestalmage]

just rebased, but there weren't any conflicts. Not sure why GH was suggesting I "update branch"

[vadimdemedes]

@jamestalmage I think it was because of lgtm.co.

[sindresorhus]

Landed! :)

[vadimdemedes]

Great stuff @jamestalmage!