TKO (“Technical Knockout”)
TKO houses the monorepo of Knockout.
To install use one of the usual package managers e.g.
yarn add tko
npm install tko
- Stable: https://unpkg.com/tko/dist/tko[.es6][.min].js
- Latest (development only): https://rawgit.com/knockout/tko/master/packages/tko/dist/tko[.es6][.min].js
Using the Monorepo
||Clone the repository.|
||Ensure yarn is globally available|
||Install local node packages and link tko modules|
||Run all tests. See below.|
||Run all tests and watch for changes. See below.|
||Build tko[.module][.es6][.min].js files, where
||Bump versions and publish to npm registry|
package.json => scripts for more commands that can be executed with
In each individual
packages/*/ directory, you can also run (presuming
karma are installed globally):
||Test the local package, where COMMAND is e.g.
||Build the package into the local
yarn test and
yarn test and
yarn watch commands can be used in the root directory, where it will run across all tests, or alternatively in any
packages/*/ directory to run tests
specific to that package.
Optional arguments to
yarn test include:
--sauce— use Sauce Labs to test a variety of platforms; requires an account at Sauce Labs and
SAUCE_ACCESS_KEYto be set in the environment.
--noStartConnect— Do not start a new Sauce Connect proxy instance for every test; requires that Sauce Connect be already running.
Note that running
rollup will create a
visual.html file that shows the proportional size of imports into each package.
TKO aims to become a base for future versions of Knockout. The objectives include:
- Modularization into ES6 and separate projects, with compilation using an ES6 compiler like Rollup. This solves several problems with Knockout, including:
- Some folks want to roll-their-own with e.g. removing components
- Compilation is now with Closure compiler, which is actually transliterating – meaning the debug and minified versions have different code paths (mostly in the form of things exposed in debug being missing in the minified version)
- The compilation of Knockout is just concatenation, leading to difficulties with maintainance, severance, and replacement
- Documentation inline in the source code. This aims to make it easier to document, by making documentation adjacent to the code about-which it speaks. Also, we aim to have examples in the documentation.
- A more comprehensive home page. The hope is to have something fun and fancy, and we have a rough prototype.
- Better setup for plugins. The problems with Knockout include:
- There's no central, searchable repository for knockout
- What should be simple plugins (e.g. binding handlers or providers) are complex, including:
- Built-ins have first-class access to quite a bit of good Knockout code, but plugins generally have second-class access and often have to duplicate Knockout internals
- Quality plugins have lots of boilerplate for compilation, release, documentation, and testing
There's an issue for that.
MIT license - http://www.opensource.org/licenses/mit-license.php.