build: remove deprecated baseUrl from tsconfig.json

[robert-md-or]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

The root tsconfig.json sets baseUrl: ".", which TypeScript has
deprecated starting in 6.0 as part of the same cleanup tracked in
#5163. baseUrl will
stop functioning entirely in TypeScript 7.0.

What is the new behavior?

Removed baseUrl from tsconfig.json, using the official
@andrewbranch/ts5to6 migration tool (built by a TypeScript team
member specifically for this and the related rootDir migration):

npx @andrewbranch/ts5to6 --fixBaseUrl .

The tool analyzed all 45 tsconfig files in the workspace and confirmed
baseUrl was only ever used as an implicit prefix for the paths
entries in the root config — not as a fallback module resolution root
— so removing it is a no-op change in behavior (✓ No projects rely on baseUrl for module resolution). Only the root tsconfig.json set
baseUrl directly; the other 37 potentially-affected projects
inherited it via extends without redefining it themselves, so no
other files needed changes.

Also ran the tool's rootDir check as part of the same cleanup
category:

npx @andrewbranch/ts5to6 --fixRootDir .

This reported no changes needed — the rootDir values already
present match what TypeScript 5.9 would infer automatically, so
nothing to migrate there.

Verified with:

• pnpm nx run store:build — clean build
• pnpm nx run eslint-plugin:test — 78 test files, 554 tests, 0 type
  errors

This closes out the last remaining category from
#5163 that this
contributor is addressing (downlevelIteration and moduleResolution
were covered in separate PRs). The one open item from that issue,
modules/store/spec/ngc/tsconfig.ngc.json (an apparently-unused
target: "ES5" config), is left for maintainers to decide on.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Related to #5163.

[robert-md-or]

Verification Guide for Reviewers

Why use a third-party tool instead of a manual/scripted fix?

@andrewbranch/ts5to6 is built by Andrew Branch, a TypeScript team member, specifically to automate the two most disruptive TS 6.0 migrations: baseUrl removal and rootDir inference. Given the risk the original issue itself flagged for this category (baseUrl touches path resolution across the whole workspace), using the team's own migration tool seemed safer than hand-rolling a script, since it already encodes the exact semantics TypeScript itself uses to decide whether a baseUrl removal is safe.

What the tool actually checked, and why the change is safe:

baseUrl has two possible roles in a tsconfig: (1) a prefix for paths entries, and (2) a fallback lookup root for bare module imports that don't match any paths entry. Only the second role is a behavior change if removed — and the tool explicitly checks for it:

→ Analyzing module resolution dependencies...
✓ No projects rely on baseUrl for module resolution

Since no project relied on baseUrl for actual module resolution, removing it is a no-op — TypeScript's own migration guide confirms this is the standard, expected outcome for a workspace already using paths (which this repo does, in the root tsconfig.json).

Only the root tsconfig.json set baseUrl directly. The tool scanned all 45 tsconfig files in the workspace and found 37 that could potentially be affected (i.e., that extend from the root config), but none of them set their own baseUrl — they all inherit through extends — so nothing else needed to change.

rootDir:

Ran --fixRootDir as well, since it's part of the same TS 6.0 change (rootDir inference is removed starting 6.0). The tool reported 9 projects checked, 0 needing changes — the explicit rootDir values already in place match what TypeScript 5.9 computes automatically, so there was nothing to migrate here.

Verification performed:

Check	Result
pnpm nx run store:build	Clean build, no errors
pnpm nx run eslint-plugin:test	78 test files, 554 tests, 0 type errors
npx @andrewbranch/ts5to6 --fixBaseUrl .	Confirmed no reliance on baseUrl for resolution before applying
npx @andrewbranch/ts5to6 --fixRootDir .	Confirmed no rootDir drift, no changes applied

This is the third and final PR from the categories identified in #5163 that I'm addressing (downlevelIteration and moduleResolution were separate PRs). The one remaining item from that issue — modules/store/spec/ngc/tsconfig.ngc.json, which appears to be dead code with no Nx target referencing it — is intentionally left untouched pending maintainer input on whether to fix or remove it.

[robert-md-or]

The test-affected failure above (modules/signals — unprotected.spec.ts and with-state.ts, errors like Reflect.ownKeys called on non-object / Cannot set properties of undefined) doesn't appear related to this change.

I checked out main at the commit this PR is based on, with none of this PR's changes applied, and ran the full signals test suite locally:

pnpm nx run signals:test

Result: 118 test files, 890 tests, all passing, 0 type errors — including both testing/spec/unprotected.spec.ts and src/with-state.ts-related specs that failed in CI.

Since this PR only removes baseUrl from the root tsconfig.json (verified via @andrewbranch/ts5to6 to have no effect on module resolution — see the verification comment above), and the same signals tests pass cleanly against an unmodified main, this looks like it could be a test that's sensitive to the CI environment (e.g. the --parallel=3 execution in the workflow) rather than something introduced by this change. Happy to dig further if there's a reproduction step I'm missing, or if it's worth re-running the job.