Knockout 3 to 4 Guide

Knockout 3.x to TKO

This guide is for teams that already have a Knockout 3.x codebase and want a practical path onto the TKO packages.

TKO keeps the familiar Knockout programming model, but changes the packaging, build structure, browser assumptions, and some binding-expression behavior.

Start with the right package

• @tko/build.knockout Recommended for most migrations. It is the compatibility-focused build and the closest match for a traditional Knockout application.
• @tko/build.reference Better for custom or modular setups where you want to compose providers and features more explicitly.

The biggest changes

Packaging changed

Classic Knockout shipped as a single distribution. TKO is published as scoped npm packages, with the main entry points being @tko/build.knockout and @tko/build.reference.

Browser expectations changed

TKO is aimed at more modern browsers than the original Knockout 3 line. If your app still depends on legacy IE-era behavior, keep that requirement front and center before migrating.

Binding expressions are stricter

The binding parser is designed to work without eval or new Function, which is a security and CSP improvement, but it also means some legacy inline expression patterns need to be revisited.

The most important migration rule is:

TSX

<!-- Avoid -->
<button ko-click={function () { count(count() + 1) }}>Add</button>

HTML

<!-- Avoid -->
<button data-bind="click: function () { count(count() + 1) }">Add</button>

TSX

<!-- Prefer -->
<button ko-click={() => count(count() + 1)}>Add</button>

HTML

<!-- Prefer -->
<button data-bind="click: () => count(count() + 1)">Add</button>

or move the logic onto the view model and bind to the named method:

TSX

<button ko-click={increment}>Add</button>

HTML

<button data-bind="click: increment">Add</button>

Security and CSP improve

TKO is designed for stricter Content Security Policies and avoids the older eval-style parsing approach. If your application needs stronger CSP compliance, this is one of the clearest migration benefits.

What is still familiar

• ko.observable, ko.observableArray, and ko.computed
• The standard binding model with data-bind
• Custom bindings and components
• The overall MVVM-style structure of a Knockout application

Migration checklist

1. Start with @tko/build.knockout unless you have a reason to compose a custom build.
2. Pin an exact package version instead of floating to the latest prerelease tag.
3. Search your templates for inline function (...) { ... } expressions in data-bind attributes and replace them.
4. Re-test browser support assumptions, especially if your app historically supported very old browsers.
5. Re-test custom bindings, component loaders, and any advanced parsing or provider integrations.
6. Migrate one page or feature slice at a time instead of swapping the whole runtime at once.

Feature comparison

Capability	Knockout 3.x	@tko/build.knockout	@tko/build.reference
Classic observables and bindings	Yes	Yes	Yes
Compatibility-focused migration target	Baseline	Yes	Partial
Modular build composition	Limited	Some	Yes
CSP-friendly binding parser	No	Yes	Yes
Legacy browser focus	Stronger	Reduced	Reduced

When not to migrate yet

• Your app still depends on IE6, IE7, or IE8.
• Your templates rely heavily on legacy inline binding expressions you cannot easily change.
• Your application depends on old plugins that assume Knockout 3 internals and have not been validated against TKO.

Where to look next

• Introduction for the current package story.
• Bindings, Observables, and Components for the APIs you will touch most during a migration.