Rip out sinon & mocha into separate modules

[lelandrichardson]

to: @ljharb @goatslacker

This refactor addresses several issues regarding enzyme working in a variety of environments, and
the library just generally not making any assumptions about the environment that tests will be
run in.

For the most part, this amounts to:

• remove direct dependency on jsdom
• remove direct dependency on sinon
• remove assumed dependency on mocha

Additionally, this change moves the code that was removed into separate modules that are
defined in the packages folder. In this case we have added two modules: "enzyme-mocha" and
"enzyme-sinon".

This design will allow us to have one repo where all issues, code, and documentation
regarding enzyme are centralized, but modules are still separated at the NPM level. This
will allow us to make atomic releases across the modules more easily, as well as keep
all of the discussion in one place.

Left to do for this to be mergable is:

• Add a "guides" section in the docs explaining how to use enzyme in different environments
• Build a proper npm script to run an npm publish in the proper order for each module
• Add more meaningful tests for packages

Related Issues:

• Fixes Jasmine support #55
• Fixes Webpack build issues #47
• Fixes Remove direct dependency on Sinon #44

[kimjoar]

typo "sionon"

[ljharb]

This design will allow us to have one repo where all issues, code, and documentation
regarding enzyme are centralized, but modules are still separated at the NPM level.

I'm not sure I agree that we'll see this as valuable. Issues with mocha-enzyme don't belong on the main enzyme repo, because not all people looking at enzyme will care about mocha nor want to see them. Similarly, people looking at enzyme-mocha issues won't want to see enzyme-jasmine issues. "non-centralized documentation" isn't a problem one way or the other since things can just link to each others' docs.

This will allow us to make atomic releases across the modules more easily, as well as keep
all of the discussion in one place.

I'm not sure how cd-ing to different dirs and running npm publish is different whether those dirs are inside the main repo, or in separate repos. What discussions do you anticipate in a separate-repo world that won't belong in the main repo, or in any of the separate repos, and thus won't have an obvious place to be held?

[ljharb]

what happens when this is imported outside a test context, and then cached with the global describe set to undefined? I think perhaps this export may need to either take describe as an argument, or, actually be a function that takes describe and returns describeWithDOM?

[lelandrichardson]

we aren't caching describe anywhere? Every time describeWithDOM is called, it uses the describe that is in the global namespace.

[ljharb]

the function retains a lexical reference to the one that's in the global namespace at the moment the function is defined, it's not freshly looked up. do you mean this to be global.describe then?