TKO 4.0 release

[brianmhunt]

@phillipc Any thoughts on gaps to a 4.0 release?

I just added the processes for deploying w/ OIDC w/provenence on NPM, which I think we need to test as beta 1.8, but do you think there are any other hard blockers to a proper 4.0 release?

[brianmhunt]

@knockout/extended @knockout/tko-writers Just pinging to note that TKO 4.0 is on deck and ready for release (subject to any major concerns).

[phillipc]

Hey @brianmhunt, I would like to see the "knip"-topic #234 included in the release. Typescript-Type-Definitions would we probably release as a separate package, and apart from the new features, TKO4 would also be compatible with the current knockout-defs.

[phillipc]

#229 is also ready to review, but I think no must have.

[brianmhunt]

@phillipc Just some preliminary feedback from claude, making me lean towards these being part of a subsequent release since 4.0 is stable and a last-minute introduction introduces significant risk. What do you think about Claude's assessment:

Risk Assessment for TKO 4 Release

PR #234 — Add knip linter and fix unused deps/exports

Risk: HIGH

• 54 files changed across 14 commits — very large surface area
• Touches public API surface: removes/internalizes exports, changes JsxObserver from default to named export — this is a breaking change for consumers
• Removes tslib from multiple packages and flips verbatimModuleSyntax on — build-level changes that could surface subtle issues
• Adds new centralized type interfaces in @tko/utils
• No new tests added for the export/dependency changes
• CI is failing (docstring coverage threshold)
• Still has unresolved review feedback (interface naming, scope concerns)

Biggest concern: Changing the public API surface (removed exports, default→named export conversion) in a late-stage release is exactly the kind of thing that breaks downstream consumers silently. This is the definition of high-risk for a release add.

---

PR #229 — Shadow DOM / DocumentFragment support for applyBindings

Risk: MEDIUM-HIGH

• 13 files, 217 additions — moderate size
• Core behavioral change to applyBindings (widens HTMLElement → Node)
• Touches sensitive subsystems: bind, utils/dom, foreach, template
• Has tests — good coverage across template, component, disposal, and DOM containment
• Two unresolved critical bugs flagged by CodeRabbit:
  1. compareDocumentPosition uses === instead of & for bitmask — correctness bug
  2. DocumentFragment disposal may miss nested descendants (getElementsByTagName unsupported on fragments)
• Leftover console.log in tests
• No human review yet

Biggest concern: The two critical bugs need to be fixed and verified before this is release-worthy. The core change (widening node types in applyBindings) could have subtle edge-case regressions in existing binding flows.

---

Recommendation

PR	Risk	Release-ready?
#234 (knip)	High	No — too many public API changes, no tests, CI failing
#229 (Shadow DOM)	Medium-High	Not yet — fixable, but needs the two critical bugs resolved + human review

If you want to ship TKO 4 soon, #234 is the riskier add — it's a sweeping refactor of exports and dependencies with no test coverage for the changes. I'd defer it to a post-release cleanup.

#229 is more viable if the two bitmask/disposal bugs get fixed and it gets a proper review pass. The new tests are a good sign, and the feature is well-scoped.

[phillipc]

Dear Claude, (i) consider the risk in the overall relationship to the changes already included (ii) The identified bugs have already been fixed (iii) The identified API changes are part of the TS porting and have not yet been released as stable. Cycles between mono-repo packages should also be removed sooner rather than later.

@brianmhunt You decide – without Claude – you are more experienced. Ultimately, we could just postpone release 4.1. That's fine with me.

[brianmhunt]

Claude's response:

Revised take:

PR #229 (Shadow DOM): With the critical bugs fixed, this drops to medium risk. It has good test coverage and is a well-scoped feature addition. More comfortable including this.

PR #234 (knip): The risk picture changes significantly when you consider: (a) these exports have never been in a stable release — there's no downstream compat contract to break, and (b) shipping a release with known circular dependencies between monorepo packages creates tech debt that only gets harder to unwind as people build on 4.0. Removing cycles before the first stable release is the cleanest path. That said, 54 files with no new tests is still a large blast radius — the risk is real, just differently shaped than I initially framed it.

Bottom line: Both are more defensible as late adds than my first pass suggested. The question is really whether you'd rather ship 4.0 lean and clean up in 4.1, or ship 4.0 complete and accept the integration risk now.

[brianmhunt]

Just going to give them a once over, and think about the right approach here. Appreciate the feedback @phillipc

[phillipc]

Thx, I can also adjust the pr branches to align with the main branch again.

Issue #235 might be interesting too. I wanted to compare this point with the knockout sources. Statistically speaking, the error is clear, but here I would probably agree with Claude before the version 4 release.

[brianmhunt]

I think these are all good things to look at after a release, so I'm going to proceed with release and then we can move forward.

[brianmhunt]

Closing this as PR 4.0 is out.