Repository navigation
feat(browser): support latest configuration defaults - #5405
Merged
Merged
Conversation
Member
Author
|
the downside is if people copypasta this and we keep add breaking changes, it defeats the purpose of defaults: 'latest' |
Contributor
Coherence0 spec problems · 0 failing chokepoints · 2 spec gaps · 0 guard failures 44 components, 7 bullets (5 invariants, 2 requirements), 0 problems Chokepoints: none declared. Spec gaps: 2 entrances with outside or unknown trust and no traced control, and 10 more held by the adoption baseline
Close one with |
Contributor
Contributor
posthog-js Compliance ReportDate: 2026-10-27 07:59:53 UTC ✅ All Tests Passed!26/26 tests passed Capture Tests✅ 26/26 tests passed View Details
|
Contributor
|
Size Change: +11.3 kB (+0.05%) Total Size: 25.2 MB 📦 View Changed
ℹ️ View Unchanged
|
Contributor
Node SDK compliance v2Commit: a4ecb61 Capture v0 — acceptance✅ 28 passed / ❌ 3 non-passing / Drill-down: run artifacts → ❌ server_snapshot_payload_false — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_zero — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_null — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: Harness exit: 1; report validation exit: 1. Capture v1 — acceptance✅ 28 passed / ❌ 3 non-passing / Drill-down: run artifacts → ❌ server_snapshot_payload_false — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_zero — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_null — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: Harness exit: 1; report validation exit: 1. Capture v0 — migration✅ 55 passed / ❌ 1 non-passing / Drill-down: run artifacts → ❌ migration/yaml-parity-v1/remote-flags-v1.feature::Omitted GeoIP settings default to enabled in flag requests — failed_assertionFlags field differs Code: Failed step: migration/yaml-parity-v1/remote-flags-v1.feature:134 the first flags request field "geoip_disable" should equal JSON false Operation: Field: Expected: false Actual value: true Harness exit: 1; report validation exit: 1. Capture v1 — migration✅ 120 passed / ❌ 1 non-passing / Drill-down: run artifacts → ❌ migration/yaml-parity-v1/remote-flags-v1.feature::Omitted GeoIP settings default to enabled in flag requests — failed_assertionFlags field differs Code: Failed step: migration/yaml-parity-v1/remote-flags-v1.feature:134 the first flags request field "geoip_disable" should equal JSON false Operation: Field: Expected: false Actual value: true Harness exit: 1; report validation exit: 1. |
marandaneto
requested review from
JamesPatrickGill,
ablaszkiewicz and
hpouillot
October 23, 2026 18:15
rafaeelaudibert
removed their request for review
October 24, 2026 03:34
Member
Author
|
i thought about adding 'unset' keeps the legacy defaults: defaults: 'unset'which is the oposite of |
marandaneto
removed request for
a team,
JamesPatrickGill,
ablaszkiewicz and
hpouillot
October 24, 2026 08:54
dustinbyrne
approved these changes
Oct 26, 2026
dustinbyrne
left a comment
dustinbyrne
left a comment
Contributor
There was a problem hiding this comment.
as we discussed, this seems like a reasonable option, but not the default
…efaults # Conflicts: # packages/nextjs-config/tests/integration/fixtures/next16/package.json # packages/nextjs-config/tests/integration/fixtures/pnpm-lock.yaml
This was referenced Oct 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The installation snippet pins
defaultsto a date such as'2026-08-30'. Users who want new SDK defaults must keep updating that date. There is no typed option to follow the newest defaults automatically.Changes
Add
defaults: 'latest'toConfigDefaults. It enables all default changes available in the loaded SDK version and follows future changes when the SDK is upgraded. Explicit configuration options still take precedence. Existing date-pinned configurations and the default'unset'behavior stay unchanged.The existing string comparisons already support this behavior because
'latest'sorts after ISO dates. No runtime selection logic changes are needed. Document the upgrade trade-off and add tests for current defaults, explicit overrides, and the public configuration type. Regenerate the rolling browser API reference so the published documentation includes the new option.For
defaults: 'latest', events report the resolved defaults date in$config_defaults, currently'2026-08-30', rather than the alias. This includes replay snapshots.config.defaultsremains'latest', and explicit dates and'unset'keep their existing event values. The supported dates live in the shared, read-onlyCONFIG_DEFAULTS_DATESruntime list.ConfigDefaultsderives its date values from that list, and event metadata sorts a copy to find the newest date. Adding a supported date no longer requires updating a separate latest-date value.Validated 335 selected browser tests and all four shared-types tests, including compiler-output compatibility, plus browser and shared-types type checks, lint, formatting, and a clean autoreview. A regression test adds a future date in the middle of an unordered list and verifies that event metadata uses it without changing the shared list. That test failed with the hardcoded date and passes with sorting. Both normal-event and replay-snapshot metadata tests were verified to fail with
'latest'before the telemetry fix and pass with the concrete date afterward. The type regression test also failed before adding'latest'and passed afterward.pnpm generate-referencesandpnpm check:public-apipass.After merging the latest
main, the Next.js fixtures match upstream and are no longer part of this PR's diff.pnpm test:nextjs-integrationpasses with both Next.js 15 React variants and Next.js 16.4.2, including production builds and dev workers. All sevenpnpm test:dependency-cooldowntests pass. Autoreview of the full updated branch is clean.Checked the SDK setup spec. It does not define date-based defaults, and this change does not diverge from its setup contract.
Release info Sub-libraries affected
Libraries affected
Checklist
If releasing new changes
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Implemented with Pi using Git, GitHub CLI, Vitest, TypeScript, Oxlint, Oxfmt, and isolated autoreview. The user requested an opt-in
'latest'defaults value. The implementation keeps the existing comparison logic rather than adding a second way to select defaults. Human review is required.