Restructure builds

[jbrantly]

• Add TypeScript as dev dependency
• Use npm scripts instead of node build. Update docs.
• Move build.js to separate folder to declutter root

Meant to resolve this comment

cc @blakeembrey

[blakeembrey]

LGTM 👍

Side note: Why is there two different build paths? Why not just move that into the scripts directly?

[jbrantly]

Why is there two different build paths?

Do you mean why is there this code?

if (semver.lt(typescript.version, '1.6.0-0')) {
    exec('tsc index.ts --module commonjs', cb)
}
else {
    exec('tsc index.ts --module commonjs --moduleResolution classic', cb)
}

It's because right now I have to use the classic module resolution, so I need to specify that. However, if I specify that for TS 1.5 I get an error back saying unknown option. Once we ditch support for TS 1.5 the build.js script can go away completely.

Why not just move that into the scripts directly?

Not sure I follow.

[blakeembrey]

You could use "build": "tsc index.ts --module commonjs --moduleResolution classic".

If I'm reading this correct (below), build would be running after the initial install with the correct devDependency version we support anyway. Then we install the TypeScript version we test with.

- npm install
- npm install $TYPESCRIPT

[blakeembrey]

Unrelated, but thoughts on code coverage? Also, this line could be just mocha --reporter spec test/run.js

[jbrantly]

I haven't really given much thought to code coverage, but 👍 if you want to implement it :D

[jbrantly]

build would be running after the initial install with the correct devDependency version we support

That's true, but we'd lose build support when actively developing for TS 1.5. Meaning...

npm install [email protected]
npm run build

would fail. But given that I haven't made any 1.5.3-specific changes in a while and I do want to eventually drop support for it, I would be OK with this. At the time that I implemented this 1.6.0-beta wasn't even released yet so keeping 1.5.3 support was more important.

[jbrantly]

One other issue with dropping build.js. In the travis build, npm test will actually rebuild the JS due to the "pretest" script. Should we just drop the pretest?

[blakeembrey]

Yeah, drop pretest. It's already built. The version we build against we can configure anytime, the version we run is definitely less configurable.

[jbrantly]

@blakeembrey I integrated your suggestions so I'm going to go ahead and merge. Thanks!