Skip to content

chore(deps): move the auth baseline to the released upstream, drop the 0.3.x compat shim - #23

Merged
y1o1 merged 1 commit into
developfrom
chore/bump-auth-to-released
Sep 6, 2026
Merged

y1o1 merged 1 commit into
developfrom
chore/bump-auth-to-released

Conversation

@y1o1

@y1o1 y1o1 commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Every workspace package now requires @o3co/auth.policy-verifier.{core,builtins,server} ^0.8.1 and @o3co/auth-provider-{core,oauth} ^0.12.0 — the versions published on 2026-09-06 — and the generators emit the same as exact pins (DEFAULT_DEP_VERSIONS: 0.8.1 / 0.12.0). Both generators move to 0.2.0 per create-app.md § 3.3. The lockfile no longer resolves 0.3.1 or 0.5.3 anywhere.

What the pin makes removable

With the released API as the floor, the dual paths that kept 0.3.x loadable are gone:

  • policy-verifier-dplaax-module/collectors/context.mts (subjectClaims / untrustedRequestFields, reaching readUntrustedRequestContext by reflection) is deleted. Collectors read context.subject and call readUntrustedRequestContext directly. Its 3-case test goes with it; the six collector/rule tests build CollectorContext in the current shape (subject, marked requestContext, required signal). 50 cases remain = the 53 on develop minus exactly the 3 in the deleted file (verified case by case).
  • The policy-verifier template and the integration test import builtinKeyResolversModule instead of probing the server namespace; the template reads config.logging.level directly. The integration test's it.skipIf(!Reflect.has(server, "JWT_MODE_MIGRATION_MESSAGE")) guard is dropped (the export exists at 0.8.1), so its two rows now run: 15 passed, up from 13.

The code had already crossed the intervening upstream BREAKING changes — o3co/auth's provin-compatibility job builds this workspace against those exact revisions — so this PR changes what is declared and removes the branch of each dual path that could otherwise drift.

@o3co/ts.hocon stays at 0.1.5: its 0.1 → 1.x move is a separate migration.

Verification

  • Workspace: 550 tests across 7 workspaces (did-dplaax 31, provider-did 216, create-policy-verifier 110, provider-dplaax-module 31, policy-verifier-dplaax-module 50, create-provider 97, integration 15 + 1 xfail + 1 skipped); typecheck, lint, build clean.
  • Generated instances, paired with this branch's modules (--dplaax-module-ref e0b41da): a single @o3co/* version installed in each (no 0.3.x / 0.5.x alongside), typecheck exit 0 for both, tests 18 / 26.
    • Pairing matters: generating against the previous develop ref installs the old module's 0.5.3 / 0.3.1 next to the app's 0.12.0 / 0.8.1 and fails typecheck on Module identity (Module[]readonly Module[] can only fail across two Module declarations). That is the failure smoke-workspace would show if the modules and the defaults ever disagree again.

After merge

o3co/auth bumps PROVIN_REV to the merge commit; provin-compatibility re-runs against the candidate auth tarballs. #21 (develop → main) picks this up as a branch PR.

🤖 Generated with Claude Code

…e 0.3.x compat shim

Every workspace package now requires @o3co/auth.policy-verifier.{core,
builtins,server} ^0.8.1 and @o3co/auth-provider-{core,oauth} ^0.12.0 — the
versions published on 2026-09-06 — and the generators emit the same as exact
pins in DEFAULT_DEP_VERSIONS (0.8.1 / 0.12.0). Both generators move to 0.2.0
per create-app.md § 3.3 (defaults refresh in lockstep with a MINOR bump).
The lockfile no longer resolves 0.3.1 or 0.5.3 anywhere.

With the pin at the released API, the dual paths that kept 0.3.x loadable
are gone:

- policy-verifier-dplaax-module/collectors/context.mts (subjectClaims /
  untrustedRequestFields, reaching readUntrustedRequestContext by
  reflection) is deleted; the collectors read context.subject and call
  readUntrustedRequestContext directly. Its three-case test goes with it;
  the six collector/rule tests build CollectorContext in the current shape
  (subject, marked requestContext, required signal). 50 cases remain: the
  53 on develop minus exactly the 3 in the deleted file.
- The policy-verifier template and the integration test import
  builtinKeyResolversModule instead of probing the server namespace for it,
  and the template reads config.logging.level directly. The integration
  test's `it.skipIf(!Reflect.has(server, "JWT_MODE_MIGRATION_MESSAGE"))`
  guard is dropped — the export exists at 0.8.1 — so its two rows now run
  (15 passed, up from 13).

The code had already crossed the intervening upstream BREAKING changes:
o3co/auth's provin-compatibility job builds this workspace against those
exact revisions. What changes here is that the released-0.3.x branch of
each dual path no longer exists to drift.

@o3co/ts.hocon stays at 0.1.5: its 0.1 → 1.x move is a separate migration.

Workspace gates: 550 tests across 7 workspaces, typecheck, lint, build.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@y1o1
y1o1 merged commit abb14d9 into develop Sep 6, 2026
3 checks passed
@y1o1
y1o1 deleted the chore/bump-auth-to-released branch September 6, 2026 15:09
y1o1 added a commit to o3co/auth that referenced this pull request Sep 6, 2026
provin-line/auth#23 moved every Provin package to ^0.8.1 / ^0.12.0 — the
same revisions this Makefile pins as VERIFIER_REV / PROVIDER_REV — and
removed the 0.3.x compat shim. provin-compatibility now builds a consumer
whose declared ranges agree with the candidate tarballs it is overridden
with; before this, the override was doing the agreeing for it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant