Here you find a quick introduction how to develop and contribute to Tapspace project.
The code is separated by three major aspects: model, layout, and interaction. The model consists of the items, like
SpaceImage, and does not depend on the layout or the interaction. The layout is capsuled into
SpaceView and defines how the model and its changes are rendered in the browser. Layout depends on the model but not on the interaction. The interaction is capsuled into
Touchable and defines how user actions on the layout affect the model. The architecture is loosely based on Jazz, libgdx.scene2d, and DOM.
Most of the example apps are targeted for touch screens. Therefore, when developing and testing an interactive app, it is necessary to serve it for touch screen devices in the same local area network. To make this easy, we have
examples/server.js, a static file server that serves the apps. The server displays a QR code of the URL to the apps when started. Read the QR code with your touch device and you are ready to go. Start the
$ npm start
Finished example apps load the
tapspace bundle from unpkg CDN. This way we avoid storing compiled files to the repository, although we still need to publish them to NPM. Bundles served by unpkg have URLs similar to
firstname.lastname@example.org/dist/tapspace.min.js. Although the version tag can be omitted, the most robust practice is to specify the version which for the example app has been designed.
Example apps can also be used for manual testing while developing tapspace core. In this case, however, the unpkg URL needs to be temporarily replaced with a local URL
../tapspace.min.js. The bundle at the local URL is served from
dist/ by the
examples/server.js. But first, build the bundle into
$ npm run build
To repeat the build every time you make a change, use
npm run build:watch instead. When this is the case, it is often necessary to have two terminals open. The first is running the examples server (
npm start) and the second is repeatedly building the bundle (
npm run build:watch).
Tests are run in a browser and built on tape.
Build a minified, standalone bundle at
dist/tapspace.min.js and source maps at
Lint source against standardJS style. To fix automatically fixable issues, use
npm run lint:fix.
Run the test suite once in a headless Electron browser and output results to console. In case of a failed test, the output is so poor for debugging that it is better to use
npm run test:browser:watch.
Run the test suite in a real browser every time a file changes. Real browsers usually have good debugging tools.
$ npm run test:browser:watch.
test/index.htmlwith your browser of choice.
webpack --watchunder the hood so any change to lib or test code rebuilds the suite.
webpack-livereload-pluginso expect automatic page refresh at each webpack rebuild.
First, in your local environment:
npm run gv.
npm run lintand
npm run test:headless.
Then, go to GitHub:
masterhead with the new version as the tag name.
By default, Travis CI is configured to publish to NPM after each successful build of the
master branch. Therefore you can celebrate your freshly published package! In case Travis CI becomes unavailable, you need to publish from your local environment:
git pull --all.
git checkout master.
npm run release. It will run the test to double-check everything, build the bundle, and then publish.
git checkout developmentto avoid accidentally committing to
masternext time you commit something.
See also a successful Git branching model.
Travis CI configuration is located at
.travis.yml. Travis CI detects changes in GitHub
master branch. For each change it runs
npm test, and finally attempts to publish to NPM.
$ npm install -g npm-check-updates $ ncu # to view available upgrades $ ncu -u # to upgrade