ild-games / skein Goto Github PK

Initial implementation did full coverage of unit tests but no E2E tests

https://github.com/angular-redux/store

Instead of having the core application be an angular app served via Electron, we will have it be a traditional web angular application which will be spawned by Electron. Electron will interface with this locally running web server via Get/Post requests. The reasons for this is two-fold:

1. Separate out the core application into a web app which which can be accessed via Electron and then in the future the core Spool application could be moved into a remote web app if desired.
2. Angular is traditionally thought of as making web apps, supporting special build configurations to get it working with Electron adds difficulty when attempting to follow recommended build process by the Angular team.

Skein is a better name for a couple of different reasons:

• A skein of yarn is a type of ball of yarn, since this project aims to be an alternative to the Yarn Dialogue Language/Editor it would be more fitting.
• A skein is also a formation of flying geese/ducks, which fits the classic ild-games duck based naming convention.

Tricky places that need to be checked:

• Issues
• Commit History
• Code Climate
• Travis CI

Angular code coverage testing is done via ng test --code-coverage. This uses istanbul under the hood by angular-cli to run code coverage checks. However, by default this will only cover source files that are covered by unit tests. This turns the code coverage check into a not very helpful metric, as we are only getting "What percentage of code paths weren't hit that could have been hit based on your existing unit tests" instead of "What percentage of your codebase isn't unit tested".

Using redux for managing the application state, have undo/redo be done via a top level reducer so all changes can be tracked and have undo/redo actions easily done on them.

Formatting

• 4 spaces as tab
• TypeScript type colons hug the identifier, not the type
• Open curly brackets are on the same line
• Must always use curly brackets around if/while/for/etc...
• All private members (variables, functions, get/set) must begin with an underscore (_)
• Variables and functions are camelCase
• const variable names are SCREAMING_CASE
• Must pass all linter formatting checks

Writing Issues

• Describe what is the problem
• Provide a relevant sample code demonstrating the problem if necessary

Opening Pull Requests

• Unit test all new functionality
• E2E test when appropriate
• Follow PR description format as they are used as the squash commit for the PR

Example: karma.conf.js is the normal configuration file for karma testing setup, however we want a different experience in running ng test by a developer than when Travis CI runs it. Specifically, in this case, we want to turn off watches in Travis CI so it doesn't hang while running tests. This is accomplished by having a near identical configuration file that gets used by Travis instead of the normal karma.conf.js file. Code Climate doesn't like this and knocks down our maintainability score for it.

Originally, the plan was to create an electron based angular application, but now the decision is to move to a traditional web server application that is spawned via an electron application and then communicated with via Get/Post requests to local web server. This is explained more in #8 .

All commits should:

• have as associated PR
• have the consistent PR comment format
• reference the project as 'Skein' instead of 'Spool'

• Select which project to edit
• Create a new project
• View the last X accessed projects
• Unit test
• E2E test