Standards

[Inkdpixels]

We should have standards across all packages on which we agree.
For example coding guidelines, folder structure, the structure and style of the README.md, a code styleguide for JSCS/ESLint or the like, and we should agree on a test suite as well(At least for the moment).

Coding guidelines:
We should work that out together in a direct discussion I think. (Maybe next week?)

Folder structure:
Use the structure from NodeProto as a starting point? Any other suggestions/Feedback on that structure?

Structure of the README.md
Same as above?

JSCS/ESLint:
What tools do we want to use? Both? I think that should be the case. We should then map out our ruleset in a direct discussion(The same as the coding guidelines).

Test suite:
Karma, Jasmine, QUnit, Jest?

We should also create a separate repository with these guidelines and embed them as a submodule/npm package(?).

@grebaldi @akoenig

[grebaldi]

Coding guidelines:
agreed

Folder structure:
agreed

Structure of the README.md
agreed

JSCS/ESLint:
I'd like to propose some automated workflow alongside the written documentation for this. If we could integrate examples, linting rules and documentation into a single structure and then somehow aggregate the configuration for the tools from that, this would save us some essential maintenance work. Besides that we would have proper documentation in one place.

Test suite:
I would go for jasmine, but maybe we could shorten some things in terms of async. If we're going full DI, we should also look for some appropriate/fitting mocking framework -> I'm not up-to-date with what's out there or if jasmine maybe provides something already. But I also wouldn't be afraid of some "roll your own" solution here.

[Inkdpixels]

Regarding the test suite:
Should we use the de-facto standard which @akoenig today proposed?
(Consisting of Mocha, Chai and JSDom)

[grebaldi]

+1

[Inkdpixels]

Regarding the tooling I've created a new repository: https://github.com/reduct/shared-build

The folder/readme structure etc. should be handled in a separate repository.

[grebaldi]

For later, when we've got decorators introduced properly, I think we should add a @deprecated decorator for automatic console errors -> like the one in component