Add Prettier and improve ESLint

[Jack-Barry]

What's the problem this PR addresses?

Recently, we shifted this repo over to TypeScript.

• Many of the syntax rules from the original ESLint configuration are irrelevant now
• A lot of the code base was a little difficult to read as a human (for example some of the huge one-liners extending up to 120 characters wide)

How did you fix it?

• Threw in Prettier and updated the ESLint rules to be more TypeScript friendly
• Caught a few little syntax errors here and there and fixed them
• Added the formatting script into the posttest script so that it will be triggered prior to linting when tests are run (just in case someone isn't using auto format on save)

Nothing about the library's core functionality changed, but most files were updated by Prettier to do things like remove semi-colons and clean up formatting

Bonus

I'm pretty sure a lot of the Babel stuff can be ripped out now too, just haven't done so yet since I'm not sure which parts are for building vs. test vs. used by the package itself.

[larixer]

@Jack-Barry Looks good, but please don't try to remove Babel, since it is much faster than TypeScript compiler and is useful in various scenarios, for example to run mochapack directly from source code when you yarn link it to your project.

[Jack-Barry]

@larixer Yeah, I figured it was in there for some reason - is it being used by mochapack internally somewhere or is it just to build? In the latter case, should I switch the build script back to using babel since that was changed in #50 ? Could always just use tsc to emit declarations only. I'm just not sure where to have that run, it's a pretty easy step to forget but don't want to have it run on every build if it's going to cause a bottleneck in cases like you described.

[larixer]

@Jack-Barry Mochapack currently requires you to run compilation in production mode prior to using it in 'yarn link'-mode or prior to running integration tests on it. Most projects out there uses this way. But there is a better way, actually have two modes of working with source code:

1. Production mode, used for publishing package to npm and used for running build on CI
2. Development mode, in which, source code is transpiled on the fly and doesn't require from you running compilation step after each change (think of @babel/register). This mode is useful when you check changes to mochapack when it linked to some of your projects via npm link, or when you run some of your tests during development. Later these tests will be run on CI in production mode, anyway.
   Right now we support production-mode only, but Babel is useful for supporting development-mode for providing developers more convenient environment for changing mochapack and immediately see their changes, without manual compilation step.

I really appreciate that you have already make many enhancements to make contributors lives easier. The one I'm talking above is just one of them that is to be done. So don't remove Babel completely please, it will be needed.

As for the production build, it is fine to run just tsc without Babel, no need to change that.

[Jack-Barry]

@larixer Got it 👍🏻 Thanks for the explanation, that's good stuff to know!