Allow usage by tsserver 2.2.1 #7

[Istar-Eldritch]

Issue #7 This PR modifies the index.ts so it complains both with the PluginModuleFactory and PluginModule interfaces. This allows for the tsserver 2.2.1 to load the plugin and keeps retro compatibility with previous loaders of this library.

This PR also modifies the project structure in a way that can be interpreted as opinionated. This are the modifications:

• Added test folder.
• Added intermediary folder for compilation .build (gitignored)
• Removed lib folder from git. (gitignored)

The reason for the changes is that the tests also need to be compiled and would pollute the release files.

Also, I believe this release files / artifacts shouldn't be part of the source code. These should be generated right before release. This avoids conflicts in merges etc on files no developer really cares about. The release of this files should be done probably using an npm module.

I also modified the package.json file:

• Moved non strong dependencies to peerDependencies.
• Added missing and test dependencies (tape / types)
• Added test script (runs the test with npm test)
• Added build script (builds the artifacts / lib folder with npm run build)

[angelozerr]

@Istar-Eldritch thanks for your PR. For the removed compiled js files, I have tried to follow the same idea than TypeScript which have a lib folder and which contains compiled js files. So why could not do that?

Why do you use tape (I didn't know) and not mocha, chai like TypeScript?

[angelozerr]

For compiled js files, it seems angular language service doesn't host js files https://github.com/angular/angular/tree/master/packages/language-service

I'm OK with that. It's just the .build folder which seems strange (I have never seen that). I think we should activate test too with travis.

[Istar-Eldritch]

I'm glad you found other repos that do not keep the deployment files. Having the compiled files in the repo sounds to me like committing the java artifacts or classes. It doesn't really add value and it may in fact create problems with merges and conflicts, appart from deviating the attention during CR from the changes that really matter in the project.

Regarding the reasons behind I started with tape and not mocha, this blog post summarizes it quite well.

• Too much configuration: Choose an assertion library, chose a reporting library, chose a task runner (Grunt, Gulp, etc…) Then figure out how to translate the documentation examples to the reporting library / task runner you chose. All of this is too much cognitive load. Vs: Choose Tape. Done.
• Globals: Mocha, Jasmine, and several other alternatives pollute the global environment with functions like describe, it, etc… Some assertion libraries extend built-in prototypes. Aside from removing the self-documenting nature of simple module exports, those decisions could potentially conflict with the code you’re trying to test. Vs: Tape’s simple module export.
• Shared State: Functions like beforeEach and afterEach actively encourage you to do something you definitely should not do: Share state between tests. Vs. Tape: No such functions for global state sharing. Instead, call setup and teardown routines from individual tests, and contain all state to local test variables.

At @repositive we switched from mocha to tape 6 months ago for all our backend services, and we won't look back. The reason we switched was the shared state of the tests, at that moment I was doing some crazy test with streams, and the simplicity of the structured vs stateful tests helped a lot.

As I told you, I'm used to do stuff with mocha, so if you see benefits on using it I can change the PR.

[angelozerr]

Thanks a lot @Istar-Eldritch for your great claraification. I'm not a big expert with JS tests framworks, so I trust you.

I think next step is to execute test with travis.