Initial TypeScript implementation

[junderw]

In order to add static typing while working on BitcoinJS-lib and automatically generate the type files for use in other TypeScript libraries, I have re-written the library using TypeScript.

A few caveats:

1. Pull requests should modify the ts files, compile, and commit all ts, js, and d.ts files.
2. Before reviewing the JS, a reviewer should build locally and see if a diff occurs.
3. To try and prevent diffs from occurring, setting typescript to a specific version, and only bumping up the version with a re-build and review of the newly compiled JS files (in case of any diff)

ToDos before merging:

1. Thorough review of the TS and JS.
2. Discuss which dependencies we should try and move to TS (at least with definitions, but if this TS methodology above is fine, we could mimic it with other dependencies, ie bip32)
3. Update the dependencies to reflect versions with TS in them. (Currently I have a dependency pointing to the bip32 TS pull request branch)

Any and all feedback is appreciated, and I will try to keep things up to date with master functionality as things change.

I currently have the ES6 PRs and the WitnessBlock checking PRs merged into this branch.

Working on this gave me a new found appreciation for TypeScript.

Any comments are appreciated.

Edit: At this point, diffs kind of lose meaning... so a review would probably consist of:

1. checkout branch
2. npm install
3. npm test (this will perform a build in the process)
4. check to make sure the build didn't cause a diff. (it should be deterministic iirc)
5. check all the files. in src, ts_src, and types
6. check git diff master -- test/ and see that it's only the new block stuff and a few things to accommodate the new TypeScript structure.

[d-yokoi]

ts_src folder name change...

how about src and dist? this is a more popular naming convention.

[junderw]

how about src and dist? this is a more popular naming convention.

dist implies that the files are only for "distribution" and are not "source" (src) files.

Since we are committing JS to git, JS files should always be checked and verified along side TS files.

dist is more common, but that is because most TS projects do not commit (or even look at) the JS code.

This project is not like that... so a new naming convention is needed.......... but I don't like ts_src... haha

[youssefgh]

JS files generated with a specific typescript version + configs should be practically the same, maybe same spaces/tabs/EOL diffs but that shouldn't alter the behavior of the Lib whether a developer use the JS files or the TS ones
I believe that including JS files instead of only generating them when needed would make the review process a bit harder than usual without real added benefits
I couldn't find a reason to include JS in the above comments but maybe am missing some points here
Thank you for the big effort you're putting in this amazing Lib

[junderw]

without real added benefits

Verifiability.

The JS files are committed because people should be given the option to not trust TypeScript/Microsoft if they wish.

TypeScript is only here for two reasons:

1. Makes developing the library more secure, adding static type analysis to the runtime type analysis given by typeforce.
2. Auto-generates type definitions.

An application has the luxury of deciding whether it wants to trust MS.

However, this library is used by people who may want to just verify the JS and not use TS at all. Having git diffs helps that verification.

[d-yokoi]

It's common to commit only .ts files but publish only .js files, which is achieved by using .gitignore and .npmignore together.

By doing so, users don't necessarily trust TypeScript/Microsoft.

[youssefgh]

Now i see the point of keeping the JS files
That make sense for Libs that deal with Bitcoin

[junderw]

@d-yokoi That is true, but keeping JS files on git makes it easier for anyone forking us to verify their changes to the ts files are all that is added to the js files. (via git diff)

Plus, that would mean everytime I publish I need to manually verify the whole JS folder.

[d-yokoi]

I understand your thoughts.

Then, why don't we leave .gitignore as it is and exclude .ts files and some config files used only for development from the published package?

Making the size of the package smaller helps users.

[d-yokoi]

I have finally noticed .ts files and other config files are not to be published from the beginning.

So, please ignore my comment above. Everything looks good to me now :)